Why enterprise agentic AI stalls at the context layer: Part 1

<h2><b><span class="h6">Model capability is no longer the constraint that keeps enterprise agentic AI out of production; context readiness is.</span></b></h2>

<p>Most enterprise agentic AI deployments stall before reaching production. The pattern is consistent across our recent engagements in financial services, life sciences, energy, manufacturing and retail. The model performs in the pilot, and the orchestration works in the demo. But the program slows when the agent has to operate against the enterprise's actual data and metadata landscape, with its inconsistencies, gaps and undocumented assumptions intact.</p> <p>The conversation around enterprise agentic AI has moved on from where it was 18 months ago. Questions about model selection, prompt design and orchestration framework remain relevant, but in our work they no longer determine which deployments graduate from pilot to production. The binding constraint has moved down the stack into the data and context layers that feed agents at runtime.</p> <p>This shift relocates the work. When the binding constraint was model capability, the path forward ran through the agent layer: better frameworks, richer prompts, more sophisticated tool use. With model quality now adequate for most enterprise tasks, the work that decides whether a deployment crosses into production happens at the Enterprise Data layer (L1) and Engineered Context layer (L2) of the reference architecture, well below the agents plane where most executive attention is focused.</p> <p>This two-part series develops three propositions grounded in implementation experience across our client base. First, the readiness problem is best understood as a context problem rather than a data problem, and the distinction matters for how organizations resource it. Second, the readiness constraint becomes binding at a specific point on the autonomy spectrum, at the transition from supervised execution to bounded autonomy, and the criteria for crossing that gate are largely about the substrate rather than the model. Third, the closing work is now well-defined enough that organizations can plan against it, provided they shift from measuring maturity by pilot count to measuring it by production autonomy levels.</p> <p>Figure 1 shows the building blocks of an agentic AI activation, from infrastructure through user experience. Figure 2 maps the four-layer reference for data and context readiness.</p>

<p><span class="small">Figure 1. An agentic AI activation runs across eight bands, from infrastructure to user experience.</span></p>

<p><span class="small">Figure 2. The four-layer reference for data and context readiness.</span></p>

<h3><span class="h4">The four-layer reference reframes data readiness as context readiness</span></h3> <p>Agentic systems have a different relationship with the data layer than human users or business intelligence (BI) tools do. A dashboard fetches data; an agent reasons over context. Reasoning requires that disparate signals, including structured records, unstructured documents, real-time streams, historical patterns and behavioral memory, be assembled into a coherent runtime view the agent can interpret and act on. That assembly is the work of an engineered context layer, and most enterprises in our experience have not yet built one and only a very small number have begun doing so.</p> <p>Four capabilities are essential to that layer:</p> <ul> <li>Unified data access removes the agent's need to know where data lives, addressed through data fabric and access mesh patterns.&nbsp;</li> <li>Trusted context tells the agent what to believe, addressed through active metadata, lineage and freshness signals.&nbsp;</li> <li>Business meaning gives the agent semantic ground, addressed through semantic layers and ontologies.&nbsp;</li> <li>Relationship intelligence lets the agent reason across domains, addressed through knowledge graphs.</li> </ul> <p>Each capability is well understood individually. Integrating all four into a single coherent layer is where most enterprises carry material gaps. In a typical engagement, we find two of the four are reasonably mature and the other two are aspirational. The cohesion across all four is where engineering debt accumulates and where the agent program runs aground.</p> <p>A four-layer reference (shown in Figure 2) organizes the diagnostic conversations we have with chief data officers. L1, the enterprise data layer, comprises operational systems, unstructured stores, streams and lakehouses. L2, the engineered context layer, contains the federated context graph, ontology, semantic layer, agent memory and feedback systems. L3, the routing and access layer, handles intent classification, source planning, policy enforcement and unified access through MCP, REST, and function calling. L4 is the agents plane itself.</p> <p>Each layer fails in characteristic ways. L1 fails on freshness and completeness. L2 fails on semantic coverage and ontology depth. L3 fails on policy-enforcement consistency and latency. L4 fails on traceability and decision provenance. Diagnosis against the layer model has proved more productive than the common debate about which platform should own which capability, particularly where multiple platforms are already in place.</p> <p>Most existing data platforms were built to serve human discovery and BI consumption. They can be repurposed for agent runtime up to a point, but the engineered context layer is new construction. Organizations that treat it as platform reuse rather than greenfield build tend to underestimate the effort by roughly an order of magnitude.</p> <h3><span class="h4">The readiness gate sits between supervised and bounded autonomy</span></h3>

<p>Agents do not move from supervised to autonomous in a single step. Production deployments traverse a spectrum that has come to be described in five levels. At A0, the agent advises and the human decides. At A1, the agent drafts actions for the human to edit and submit. At A2, the agent acts with explicit gates the human must clear. At A3, the agent acts end-to-end within defined limits, with human review of exceptions and outcomes. At A4, the agent self-governs within a policy envelope.</p> <p>The first three levels are human-in-the-loop. The last two are human-on-the-loop. The structural break between A2 and A3 is where data readiness becomes the binding constraint, and the reason has more to do with the cost of error than with technical sophistication.</p> <p>Through A2, context gaps are absorbed by human judgment. If the agent retrieves the wrong record, a human catches it. If two systems disagree on a value, a human reconciles. The cost of imperfect context is rework rather than incident, and the data layer can be partially complete without halting the program.&nbsp;</p> <p>From A3 onward, however, the agent acts. Every context gap becomes a production issue with potential audit, customer or financial consequence.&nbsp;</p> <p>The criteria organizations apply to autonomy decisions, including confidence thresholds, error tolerance, RBAC and PII enforcement, decision reversibility, regulatory exposure and customer-facing risk, converge at this transition on a single requirement: the data and context feeding the agent must be clean, consistent, semantically enriched, governed and current. Lineage and provenance become first-class artifacts rather than after-the-fact derivations, and decision traces have to be queryable and explainable, not merely loggable.</p> <p>Model capability remains relevant at A3 and above, particularly in probabilistic decision domains where the agent has to handle ambiguity. But in our observation, variance in agent outcomes at fixed model capability is dominated by context quality rather than model quality. Organizations that focus their A3 readiness work on model upgrades or prompt sophistication tend to plateau short of their objectives.</p> <p>The reframing changes how agentic AI maturity should be measured. A portfolio of A0 and A1 agents, however numerous, does not establish that the substrate can support higher-autonomy use cases. Production autonomy level, the highest A-level reached in production for at least one deployed agent, is more diagnostic than pilot count or use case count, because it exposes substrate readiness directly. Most enterprises we work with are still anchored at A1; the move to A3 typically requires a six- to 18-month investment in the engineered context layer.</p> <h3><span class="h4">Five frictions account for most of the pilot-to-production gap</span></h3> <p>Across the engagements where pilots have failed to graduate, five frictions account for most of the gap. Here we list them in roughly the order they tend to surface during implementation</p> <h4><span class="h5"><span class="text-bold-italic">1.&nbsp;</span> &nbsp; Latency mismatch between data and agent loops</span></h4> <p>Agents make decisions on the order of seconds. Most enterprise-quality signals and metadata refresh on the order of minutes or hours. In a recent engagement with a North American electric utility, an agent making dispatch recommendations was operating against load data with average staleness of 11 minutes, and confidence scores derived from metadata refreshed nightly. Recommendations were technically correct given the inputs available at runtime and operationally wrong in roughly one in five cases. Remediation required restructuring the L1-to-L2 boundary to provide event-driven freshness signals; no work in the model or the prompt layer was involved.</p> <h4><span class="h5"><span class="text-bold-italic">2.</span>&nbsp; &nbsp; &nbsp;Semantic divergence across domains</span></h4> <p>The same business term frequently carries different meanings across business unit, region and system. A global insurance carrier we worked with had three distinct definitions of “policy effective date” in active use across underwriting, claims and finance—none formally reconciled. Agents synthesizing across these domains without a bridge ontology produced results that were internally consistent but factually wrong. The fix was an explicit cross-domain ontology, not a smarter retrieval strategy.</p> <h4><span class="h5"><span class="text-bold-italic">3.</span>&nbsp; &nbsp; Unstructured data isolated in vector stores</span></h4> <p>Most enterprises have moved their document corpora into vector stores and treated the migration as the unstructured data strategy. But embedding similarity is not semantic relevance. A contract clause returned by a vector search becomes operationally useful only when connected to the customer record, the entitlement schedule and the renewal history that give it context. Vector stores in isolation produce demo-quality answers; integrating unstructured assets into the federated context graph, with metadata and relationships to the structured domain, is what makes them production-grade.</p> <h4><span class="h5"><span class="text-bold-italic">4.</span>&nbsp; &nbsp; Cross-domain integration through legacy interfaces</span></h4> <p>Enterprise APIs were built for screen-driven applications, and their response shapes optimize for human consumption rather than agent ingestion. In a pharma deployment, an agent assembled its working context through 47 sequential API calls because no data product existed at the appropriate grain for its workflow. Latency was the visible symptom; the underlying issue was that the access layer had not been designed for agent consumption and the data products had not been built to match the agent's reasoning units.</p> <h4><span class="h5"><span class="text-bold-italic">5.</span>&nbsp; &nbsp; Tribal knowledge that has not been codified</span></h4> <p>The most consequential business knowledge in many enterprises lives in spreadsheets, email archives and the working memory of senior operators. It is unversioned and unqueryable—and it’s the first thing the agent needs when it hits an edge case. Codifying it requires SME time and rarely produces a clear deliverable until late in the program. Organizations that defer the work tend to discover, post-deployment, that their agents perform well on routine cases and fail predictably on the cases that justified the deployment in the first place.</p> <p>Two further frictions are worth naming briefly. Ground truth for agent evaluation rarely exists in the form needed, because most existing evaluation data was constructed for traditional machine learning model testing rather than agent decision quality. And governance for the context layer itself remains largely greenfield: most enterprises have data governance and model governance in place, but the context governance between them, determining what an agent is allowed to know, infer and act on, sits in an organizational gap owned by neither team.</p> <h3><span class="h4">What’s next</span></h3> <p>In Part 1, we’ve focused on diagnosing the problem: where agentic programs stall and why the engineered context layer is the binding constraint. In Part 2, we’ll turn from the diagnosis to the build. We’ll explore why sustainable semantics demand ontology-driven design rather than just prompt-driven engineering; how agents are improving the very substrate that other agents depend on; and the six-initiative agenda chief data officers can use to close the gap, ending with the single metric boards should be asking about.</p>