The context engineering maturity model

Our context engineering maturity model is built on four foundational capabilities: the core pillars of production-ready context. These pillars are the dimensions that every production context system must satisfy, not just features that teams can build in a sprint.

Pillar 1: context that is navigable by agents

An agent that can only retrieve chunks can answer questions where the answer is contained within a single retrievable document. An agent that can navigate a semantic layer can answer questions that require traversing relationships, resolving entities, and combining information across multiple data sources in a way that reflects the actual structure of the business domain.

The primary architectural mechanism that enables navigability is the semantic layer: a defined, agent-readable model of business entities, their attributes, and their relationships in natural language. Rather than exposing raw database schemas or underdocumented REST APIs, the semantic layer defines the domain in a form that an agent can reason about.

Navigation fails when:

• Retrieval architectures return text chunks without relationship information.
• Embedding-only systems surface semantically similar content but can’t traverse structured relationships.
• Agents must query multiple disconnected retrieval systems, with no unified access model.
• Text-to-SQL approaches give agents direct database access without a semantic layer, and create security, reliability, and accuracy risks.

Navigability is the difference between a bag of retrieved chunks and an agent-native context layer.

Pillar 2: context that is retrievable quickly

Speed in a context system is a design constraint that teams must engineer into the architecture from the beginning.

The retrieval challenge is multi-modal. A production context system must handle all of the following efficiently, often in combination, and often under simultaneous load from many concurrent agents:

• Semantic retrieval (embedding-based similarity search for unstructured content).
• Hybrid retrieval (combining semantic and keyword search for better precision across heterogeneous content).
• Metadata filtering (narrowing semantic results by structured attributes like date, owner, category, or access tier).
• Structured lookup (exact-match queries against entity records and relationship tables).
• File system retrieval (accessing documents, attachments, and file-based content).

A context stack that handles semantic retrieval efficiently but degrades under hybrid retrieval, or that handles structured lookup quickly but is slow on semantic search, is not a production-ready context stack.

Pillar 3: context that is always fresh

Enterprise context is not static. CRM records update continuously. Warehouse tables refresh. New files land in object storage. Transactions arrive. App state evolves in real time. A context engine that reflects the world as it was will produce agent behavior that is confidently, invisibly wrong in ways that scale with the consequentiality of the agent’s decisions.

The standard architectural approach in early-stage AI deployments is batch ETL: pull data on a schedule, transform it, and load it into a retrieval index. This approach is familiar, relatively easy to implement, and completely inadequate for production agents that take consequential actions.

The right solution is change-data capture (CDC) and event-driven synchronization. CDC tools—database-level mechanisms that detect and propagate changes to downstream systems as they occur—can reduce the staleness window to near-zero for high-priority data domains. This requires infrastructure that can process streaming data, detect meaningful changes, and propagate them to the context layer with low latency while preserving the freshness of other concurrent streams.

For agents that take actions—send emails, update records, trigger workflows, issue quotes, and escalate tickets—the downstream cost of a stale-context action is often much larger than the cost of the context failure itself. An agent that issues a quote based on pricing that changed the morning prior, for example, might create a contractual obligation or embarrassing moment.

Pillar 4: context that gets better with time

A context system that satisfies the first three pillars—navigable, fast, and fresh—is a strong retrieval system. A context system that also satisfies the fourth pillar is a learning system: one that becomes more personalized, more relevant, and more informed by prior interactions with every use.

The mechanism for compounding context is memory.

Memory is what allows an agent to remember not just the prior ticket, but the customer's stated preferences, unresolved frustrations, and interaction history. Memory is what allows a sales agent, for example, to accumulate deal history, objection patterns, and stakeholder preferences over time, making each subsequent engagement more precise.

Memory architecture choices have lasting consequences.

Not all memory should persist indefinitely. Some states are session-specific—relevant only to the current conversation and meaningless beyond it. Some states are user-specific—relevant to a particular user's preferences and history, but not to the broader system. Some states are account-specific—relevant to a customer account and all agents that interact with it. Some states are global—relevant to all agents across the organization, such as learned patterns for exception handling or edge cases that recur in a given domain.

A memory architecture that mixes these scopes will produce confusing and sometimes harmful behavior. Memory systems must support explicit scope boundaries, retention policies, and access controls.