This piece draws on “Entering the ontology era: the blueprint for enterprise AI agents”, an article by our co-founder Tarek Nseir for the Forbes Technology Council, published 20 August 2026.
Enterprise AI agents stall because they go into production before anyone has given them a model of the business to reason over. What closes that gap is a context layer, made of an ontology that defines what the organisation runs on, a knowledge graph that binds live data to those definitions, and reasoning frameworks that carry the rules behind real decisions. Without it an agent produces work that looks plausible and never earns operational trust, which is how most pilots quietly end. Tarek Nseir set out the case in Forbes, and this piece picks up the question that follows it. What do you build, and in what order?
The wrong order
Most enterprises approach this back to front, and Tarek is direct about the cost.
“Most enterprises are trying to solve this in the wrong order: buying and piloting agents first, and treating the underlying context as something to backfill later—yet that’s exactly why so many pilots stall.”
Agents can only reason over the information, processes and business logic they can actually see. In most large organisations that knowledge sits in different systems nobody has reconciled, so even a capable model produces work that misses how decisions really get made. It looks plausible and lands wrong, which is the fastest way to lose the people who were meant to use it. Tarek calls the cycle that follows pilotitis, throwing new ideas at the wall and wondering why nothing sticks.
The context layer, in plain terms
An ontology gives the organisation one machine-readable definition of the things it runs on, its customers, products, contracts, processes and decisions, and how all of those relate to each other. A knowledge graph then binds live data from across the estate to those definitions, so the model reflects the business as it is today rather than as it was documented three years ago. Reasoning frameworks apply the rules that govern decisions, which is what lets an agent reach a conclusion an experienced operator would recognise as sound.
In practice it works the way institutional knowledge works for someone who has been in the building a decade. When an agent picks up a task it consults the same shared model as every other agent and every human colleague, so its output reflects how information moves and how decisions get made in that specific organisation. Because the model spans systems instead of living inside one application, agents working in different parts of the business reason from the same understanding rather than contradicting each other.
A data platform stores and moves data. An ERP runs transactions. The context layer does neither. It sits above both and describes what any of it means, which is exactly why it has to span systems rather than sit inside one of them.
A market converging on the same answer
Palantir made this bet years before anyone was discussing agents, wagering that decisions only improve once scattered data, processes and rules are turned into one coherent model. Newer entrants are arriving at the same place from different starting points, Databricks with its Genie Ontology among them, built on that company’s heritage in data and analytics.
Microsoft CEO Satya Nadella has made a version of the same argument, that advantage will come from how well an organisation’s knowledge, workflows and decisions work together as a single system rather than from access to frontier models. Where Tarek pushes further is on who actually does the work.
“Intelligence becomes far more powerful when it operates within a connected system rather than in isolated applications or tasks, but the ‘loop’ doesn’t create itself. The onus is on firms and their partners to build it.”
Microsoft is coming at it from the enterprise platform layer, SAP through systems of record, AWS and Google from infrastructure, whilst OpenAI, Anthropic and other frontier providers keep pushing model capability. The starting points differ because the commercial positions do, but every route runs through the same problem of giving systems a shared understanding of the business they serve.
Sequencing the build so it survives the next platform shift
Nobody needs a finished ontology before the first agent goes live, and treating it as a precondition is its own kind of stall. The work starts in one domain where a decision genuinely matters and the data behind it is reachable, then extends outward as each use case pays for the next.
What separates a context layer that compounds from a data-cleaning exercise that decays is mostly ownership. It needs an owner and a roadmap, so it is maintained as a product rather than abandoned when the engagement closes. Agent use cases then get sequenced against the parts of the model that already exist, which is what makes early deployments land well and each subsequent one cheaper. Keep the definitions, relationships and business rules deliberately separate from any single vendor’s implementation of them.
A well-built context layer keeps its value across model generations and platform migrations, because what it encodes is how your business works, not how a particular tool happens to work this year. A fleet of point-solution agents almost never survives the same change. This is organisational change as much as technical work, and it asks something of governance, workflow design and how teams collaborate.
What to ask a partner before agents reach production
The quickest way to tell a context-first partner from an agent-first one is to ask where they would start on day one. A partner leading with a catalogue of agents to pilot is selling the wrong end of the problem. Listen instead for the questions about how your decisions get made, where the business logic lives and who owns the data underneath, because that partner is building towards something agents can use.
Then ask what survives if the frontier models change. The answer separates durable foundations from disposable tooling. And ask how success will be measured, because a partner confident in this approach ties its work to business outcomes rather than the number of pilots launched.
Tarek ends the Forbes piece on the stake.
“As the market matures, the winners won’t be the ones with the best models—they’ll be the ones that make information, decisions and action move together across the business, and ontologies are the only answer.”
This piece draws on “Entering the ontology era: the blueprint for enterprise AI agents”, an article by our co-founder and senior value partner Tarek Nseir for the Forbes Technology Council, published 20 August 2026. Read it in full on Forbes.
FAQs
What breaks first when you move AI agents from pilot to production at enterprise scale?
Trust, and usually before anything technical. A pilot tolerates output that is roughly right. Production does not, because the people relying on it can see when a recommendation misreads how decisions are actually made in their part of the business. The underlying cause is almost always missing context rather than model capability, which is why more capable models rarely rescue a stalled deployment.
What does an ‘Enterprise OS’ actually mean, and how is it different from a data platform or an ERP replacement?
An Enterprise OS is the operating layer that sits above your systems and describes what the business means, how work flows through it and which rules govern decisions. A data platform stores and moves data. An ERP runs transactions. Neither one holds that shared meaning, which is why adding more of either rarely fixes fragmentation. The operating layer is the thing that lets people, systems and agents work from one understanding of the same business.
What is an enterprise ontology, and do we need one before scaling AI across systems?
An enterprise ontology is a formal, machine-readable map of the concepts, entities and relationships a business runs on. It defines what terms mean, how business units interact and how data connects across different software systems. You do not need a complete one before your first agent, but you do need one for the domain that agent works in, otherwise it has nothing reliable to reason over. The work compounds across every use case that follows, which is why starting it late is more expensive than starting it small.
What is the realistic build sequence for an enterprise operating layer, data, ontology or workflow first?
In practice they interleave rather than queue. Start with a decision that matters and work backwards, defining the handful of entities and relationships that decision depends on, connecting the live data behind them, and encoding the rules that govern it. That gives you a working slice of ontology, data and workflow together, in one domain, which is far more useful than a complete data programme with no decisions attached to it.
Who can help design and implement an enterprise data ontology for AI?
Look for a partner that treats the ontology as a product with an owner and a roadmap rather than a one-off mapping exercise. It should be sequencing agent use cases against the parts of the model already built, and tying its fees and roadmap to measurable business outcomes rather than the number of pilots launched. Ask what survives a platform change, and be wary of anyone whose answer depends on a single vendor’s tooling.
