I’m seeing countless companies walk into the same trap when investing in agentic AI. They’re buying into the illusion that hooking up their data warehouse/lakes via MCP will give AI agents enough operational context to make the right decisions for the business.

That is (excuse my language) bullsh*t.

I’ve spent 30 years leading digital transformation teams at Merck, GE HealthCare, and Johnson Controls. I’ve lived through every major wave of enterprise tech; from early data warehousing and digital twins to RPA, BI tools, and process mining (the latter I scaled to a multi-million dollar engine, see my story here).

Every time, organizations made the same mistake — thinking that data access meant business understanding.

https://delivery-p141552-e1488202.adobeaemcloud.com/adobe/assets/urn:aaid:aem:f1fa00a0-1a95-4403-aac3-d22b5539842b/original/as/Raw_data.jpg

In this two-part series, I’ll explain why CIOs should embrace a process-centric context model to make AI reliable, explainable, governable, and scalable. I’ll also cover what characteristics your context model needs to have — and how to build one.

Disclaimer: After 30 years in enterprises, I now advise customers on their AI transformation at Celonis. While I don’t claim to be entirely objective (Celonis also has a context model), I’ve seen too many AI pilots fail — and helped enough customers scale — to have a strong opinion on why any AI transformation needs to be a process transformation at its core, and what a mature context model looks like.

Let’s start with the basics.

Why do enterprises need a context model?

The push for context models grew out of the limits of context engineering. Once LLMs evolved in mid-2025 to power multi-step workflows and larger context windows, it became clear that ‘good prompting’ alone wouldn’t be enough. Context engineering tried to solve this by looking at how to curate, organize, and feed information to an AI model’s prompt window (what information, at what time).

Andrej Karpathy (former AI lead at Tesla, cofounder of OpenAI) described it as

“the delicate art and science of filling the context window with just the right information for the next step.”

That ‘art’ came with a trade-off: Feed an agent too much (and static) context and it becomes brittle and slow. Feed it too little information, and it makes uninformed, inconsistent calls.

The biggest problem, though, is that context engineering isn’t scalable for Enterprise AI. If every new document, regulation, or decision requires you to update context definitions, no amount of RAG fetching, hardcoded JSON schemas, or custom system prompts can keep up.

A context model fixes this by hosting context in a real-time, continuously updated environment, letting AI systems and agents pull the exact information they need, right when they need it.

The market is saturated with context models. Here’s why most solutions fail.

Ever since Foundation Capital dropped its “Context Graph” thesis in December 2025 — calling it a $1 trillion opportunity — the market's been obsessed with AI context.

Heavyweights like ServiceNow, Databricks, and Salesforce are all racing to claim this new layer of the tech stack.

The label (context model/ context graph/ knowledge layer/ontology, etc.) varies, but the promise is identical: give AI models the context they need to make trustworthy decisions and deliver ROI that means something.

Also identical is their core challenge: they only see their own slice of the world.

When models like Anthropic’s Fable or OpenAI’s Astra query them, they get isolated, single-system semantics rather than a cross-system, process-centric view of your business. They lack the complete operational context to understand how work actually flows across your enterprise.

An isolated ERP table won't tell AI why a warehouse manager routinely overrides safety stock limits in Excel. Or why expediting an order for a VIP customer will breach SLAs for two other contracts with hefty penalty clauses. (I’ll dive into where I see Palantir’s Ontology — which can bridge multiple systems – fall short, in just a minute.)

What happens when agents have MCP access, but zero operational understanding (or process guardrails) has been well documented: agents either hallucinate, drift, or take destructive actions. To name just one recent example: a Claude-powered agent wiped a company’s entire production database and its backups.

Where should a context model sit in your tech stack?

Before we dive into how a context model needs to behave to be worth the investment, a quick note on architecture:

Big AI players like OpenAI and Anthropic will naturally try to force you to marry their models for life. But given that they play leap frog with each other every few months, you need to be able to choose the best model at any given time.

The same logic applies to the rest of your tech stack — your data lakes, agentic platforms, software tools. Decoupling your business logic from your IT stack lets you stay best-of-breed, without rebuilding your enterprise logic from scratch every time you switch tools and vendors.

That’s why your context model needs to sit between your data and your agent layer — translating raw enterprise data into actual business semantics AI can understand.

What do I mean by ‘business semantics’ — and why is it key for AI?

When I say a context model translates raw data into business semantics, I’m not talking about static data dictionaries or metadata tags. I mean giving AI your unique institutional knowledge to understand what an enterprise state means, what consequences an action will cause, and what is allowed.

A complete context model must encode five distinct dimensions of your unique business knowledge. Your:

• Objectives: overarching business goals, priorities, and target outcomes (e.g., protecting working capital vs. maintaining customer satisfaction).
• Operating model: value chains, business objects, financial context, and process models describing how work flows across systems.
• Business meaning: the semantic definition of any enterprise event. A raw timestamp in SAP doesn't explain what constitutes a late delivery, a blocked invoice, or a critical exception.
• Operational patterns: recurring dynamics and institutional benchmarks that define how operations normally perform (and when they’re drifting).
• Constraints and guardrails: rules, policies, thresholds, permissions, and regulations that govern what an AI agent is allowed to do.

What characteristics does a mature context model need?

(Spoiler: most context models on the market only check some of these boxes)

1. Process-centric: Without a holistic process view, your AI is essentially a loose cannon. Your context model needs to show how work gets done, by whom, in what order, and how it should be done (understanding your organizational goals and constraints) to achieve the best outcomes.
   
   Example: An AI agent might spot a raw material shortage and auto-order from the cheapest vendor to save money. In isolation, that solves the problem, sure.
   
   What it misses is that the vendor’s lead time has slipped to 3 weeks instead of 3 days because a port is blocked. And that one factory line runs out of stock in 5 days. So you have AI triggering a massive bottleneck in manufacturing and huge fulfillment delays; costing far more in penalties than it saved on parts.
2. Dynamic: A context model should evolve at the same speed your business evolves. Think of it as a continuously updated feedback loop. It ingests real-time signals from humans, backend systems, and AI agents — learning from emerging process patterns, adapting, and feeding this right back into your agents (more on that in part 2). That’s how you keep your AI grounded in operational reality.
3. System agnostic: Your context model needs to connect across your entire system landscape — from knowledge bases to CRMs, from data lakes to BI tools — to represent your business reality end-to-end. This is the only way for AI to understand downstream or upstream dependencies.

Example: In customer service, resolving a complex case may require coordination across CRM, billing, and logistics systems. A context model allows AI to understand the full situation and orchestrate actions across these systems rather than treating each in isolation.

1. Cross-time: A context model needs to track the real-time status of your operations. Crucially, it should include memory — the exact order and timeline of events and decisions that explains how and why a process reached its current state.
   
   Now, I might be biased (I said I work at Celonis). But in the best case, your context model also includes decision intelligence, prediction, and simulation capabilities. That means you don’t just know when operations break, but when they’re about to break – and exactly how to prevent that.

Example: take Inventory Management. Your ERP system’s built-in AI features might tell you that you should reorder a specific material based on a demand spike in a region. But, when powered by a mature context model, AI can go much further:

https://delivery-p141552-e1488202.adobeaemcloud.com/adobe/assets/urn:aaid:aem:2a98e5ea-361d-462c-9ef1-2e488ca13702/original/as/Chat_bot.jpg

Because it monitors the present (warehouse inventory), the past (historical shipping data), predicts what is likely to happen next (stockout), and simulates what-if scenarios (rail vs. air freight), your AI can recommend not just any action, but the best action to keep your stock levels balanced at all times.

1. Aware of constraints and external factors: meaning it needs to consider regulations, market conditions, external events (e.g. a central port being blocked) affecting the process.
   
   Example: in financial operations, for instance, AI querying a context model can adjust invoices or prioritize payments while respecting policies, approval thresholds, and compliance requirements.
2. Open: You can’t lock your business logic inside a single platform’s walled garden. A mature context model must be able to pull raw data from anywhere via APIs, feeding rich context to any AI agent or application via MCP. In short: ingest from everything, serve context to anything.
3. Built on institutional process knowledge: This is where the wheat separates from the chaff. A mature context model doesn’t just make sense of your internal data, it brings pre-built institutional knowledge about how real-world processes actually function.
   
   Example: take Warehouse Management. A mature context model understands the core objectives of the process, how operational decisions get made, and what intent sits behind human actions (e.g. why a warehouse manager routinely overrides safety stock limits).

This knowledge can’t just be derived from your organization alone.

It needs to be built over thousands of implementations across hundreds of companies in dozens of industries, allowing AI to recognize operational patterns and apply proven best-practices from day one.

That’s where I see even advanced context products, like Palantir’s Ontology, still lacking. Most just aren’t designed to embrace the full, sometimes messy reality of business processes, with all their nuances. So consultants and engineers have to spend 6 to 12 months reverse-engineering a tool that is meant to collect data only — not process dimensions like business rules, connections between upstream and downstream work, and operational patterns. Those are the small but powerful details that tell the real story of how a business works. And if your context model can’t capture them, then it can never serve its true purpose.

The bottom line: Enterprise AI needs more than raw data

Nothing I’ve described above is theoretical. It's how we approach Enterprise AI at Celonis. I always like to joke that we built the world’s largest process benchmark repository by accident; helping organizations map and optimize their operations for more than a decade. Here comes the sales pitch, you might think, but hear me out.

What I want you to take away from this post comes down to three things:

1. Context is key to grounding your agents in operational reality and delivering measurable ROI.
2. Architecturally, this context needs to be built as its own layer, sitting between your data and your agents — separating business logic from application silos so agents can see the big picture.
3. Raw data access is NOT business understanding. It needs to be absorbed, transformed, sequenced, interpreted, and enriched (with your business knowledge, process and decision intelligence) by a context layer. That’s how you tell AI what operational events actually mean, what actions are permitted, and what consequences those actions carry.

Want to dig deeper?

If you want to understand how organizations like Uniper, Fujitsu, Hitachi Energy, and Novo Nordisk are getting agents, humans, and systems to work together to deliver real business outcomes, I highly recommend our AI Transformation Playbook.