Bounded Context Spaces for AI Agents: Domain Isolation Explained

Without bounded context spaces, AI agents experience context contamination — retrieving irrelevant data, resolving terminology conflicts, and leaking context across security boundaries.

The DDD origin — and why it applies to AI

In 2003, Eric Evans introduced the bounded context pattern in Domain-Driven Design to solve a problem that every large software organization eventually faces: the same word meaning different things in different parts of the business.

“Customer” in Sales means a prospect or paying account. “Customer” in Support means a ticket submitter. “Customer” in Finance means a revenue-recognized entity. Build a monolithic system where all three share the same data model, and you spend most of your time managing definitional conflicts rather than delivering value. Evans’ solution was explicit domain isolation: a bounded context is the boundary within which a single, consistent domain model applies.

The same problem appears when AI agents operate across a large, multi-domain enterprise data estate. An agent retrieving context about “revenue” in a Finance workflow can pull from Marketing’s attribution model, Sales’ pipeline value, and Finance’s GAAP-recognized revenue simultaneously. It has no mechanism to know which definition is appropriate. Without domain isolation, the agent inherits every terminological ambiguity that the data estate has accumulated.

The table below maps how DDD’s bounded context concepts translate to AI agent architecture.

The translation is not an analogy — it is a direct application of the same principle to a different kind of system. The problems DDD solved in software architecture are the problems that bounded context spaces solve in AI agent architecture.

Why AI agents need domain isolation

Without bounded context spaces, three categories of failure emerge in AI agent deployments. Each is a consequence of the same root cause: an agent that can see everything retrieves everything — and then has to resolve conflicts without the contextual knowledge to do so correctly.

Context contamination

Context contamination occurs when an agent retrieves cross-domain data that is technically related to the query but not appropriate for the asking domain. A Sales agent asked about “customer churn” retrieves Support ticket definitions alongside the relevant Sales pipeline metrics. A Finance agent asked about headcount costs retrieves HR performance management data alongside the budget models.

The agent either attempts to synthesize across incompatible definitions — producing a blended answer that is wrong for any single domain — or picks the most statistically prominent result, which is unpredictably wrong depending on which domain has more data in the retrieval set.

Terminology conflicts

Multi-domain terminology conflicts are the most common cause of agent-delivered wrong answers in enterprise deployments. Consider three definitions of “revenue” in a typical enterprise:

• Finance: recognized revenue per GAAP accounting standards
• Sales: total pipeline value including unbooked deals
• Marketing: attributed revenue from marketing-influenced opportunities

Without domain isolation, an agent asked “what is our Q1 revenue” retrieves all three. It cannot determine which definition the asker intends. In a Finance context, this is not just an accuracy problem — it is a regulatory risk if the agent’s output is used in financial reporting.

Security and governance failures

Domain isolation is a governance requirement in regulated industries, not just a precision improvement. An HR agent should not be able to surface compensation data to a Finance agent. A customer-facing agent should not be able to retrieve internal product roadmap data. Customer PII should not bleed into Marketing context stores.

Without bounded context spaces enforcing these boundaries at the context layer, the only protection is the model’s understanding of what it should and should not share — which is not a reliable governance mechanism.

Anatomy of a bounded context space

A bounded context space is not a single technical component — it is a governance and infrastructure pattern with four required elements. All four must be present for domain isolation to work.

Domain boundary

An explicit definition of which assets, metrics, glossary terms, and processes belong to the domain. The domain boundary is the starting point — everything else is scoped to it.

Finance domain: revenue metrics, P&L tables, budget models, financial KPIs, GAAP definitions, audit-relevant lineage.

HR domain: headcount data, compensation models, performance ratings, hiring pipeline metrics, attrition calculations.

Marketing domain: campaign metrics, attribution models, lead data, MQL definitions, channel performance tables.

Shared assets — customer master data, product catalog, and shared operational metrics — require a separate governance pattern (see the section on shared context below).

Domain ownership

A named team or individual accountable for the domain’s context. The domain owner makes certification decisions for domain assets, maintains domain glossary terms, and approves cross-domain context requests.

Without domain ownership, the domain boundary exists on paper but decays in practice. Assets drift across domains. Glossary terms go unmaintained. Cross-domain requests get approved without review. Domain ownership is the human governance layer that keeps the technical isolation meaningful.

Domain vocabulary (bounded glossary)

Domain-specific term definitions that apply within the domain boundary and override global definitions within it. The Finance domain’s definition of “revenue” is authoritative for Finance agents — even if the global glossary has a blended definition.

The bounded glossary also defines the translation layer at domain boundaries. When a Marketing agent legitimately needs to reference Finance’s revenue number, the translation layer applies the Finance definition — not a Marketing interpretation of it.

Domain-scoped RBAC

Access control that maps agent identity and user identity to domain membership. An agent assigned to the Finance domain can only query Finance-tagged assets, Finance-scoped vector store content, and Finance terms in the business glossary. The RBAC is not permission-per-asset — it is permission-per-domain, inherited from the domain’s existing access policies.

The following diagram shows three bounded context spaces — Finance, HR, and Marketing — with agents operating inside domain boundaries and shared context governed at the intersection.

Each agent operates within its bounded context space. Domain boundaries enforce RBAC — an agent cannot retrieve context from another domain without explicit authorization and translation.

Context contamination — what goes wrong without bounded contexts

Context contamination is not a hypothetical risk — it is the default failure mode for any AI agent deployment that skips domain isolation. The contamination happens quietly: the agent returns an answer, the answer looks plausible, and no one realizes the definitions were blended until someone compares the output to a known-good source.

Four contamination scenarios appear repeatedly across enterprise deployments:

The revenue problem. A Finance agent is asked “what was our Q1 revenue?” Without bounded context, it retrieves Marketing’s attributed revenue, Sales’ pipeline value, and Finance’s GAAP-recognized revenue simultaneously. The answer it returns may blend these definitions or weight by retrieval rank. Either way, it is wrong for a Finance use case and potentially wrong for financial reporting.

The customer problem. A Support agent is asked “what is the customer’s current status?” It retrieves Marketing’s segmentation label (mid-market, high intent), Sales’ stage (negotiation), Finance’s payment status (60 days overdue), and Support’s own ticket resolution status (two open P1s). There is no single authoritative answer, and the agent has no mechanism to know which the asker needs.

The compliance problem. An HR agent processes a request that legitimately touches Finance headcount budgets. Without bounded context enforcement, it also retrieves compensation ranges and performance review data that Finance should not have access to. If the agent’s output surfaces that information — even indirectly — the organization has a compliance event.

The precision problem. Even in cases without strict correctness violations, cross-domain context adds noise. An agent operating over the entire enterprise data estate returns lower-precision answers than one operating over a focused, domain-relevant context set. The improvement from bounded context is measurable in both answer quality and context window efficiency.

How to implement bounded context spaces

Implementing bounded context spaces is a governance and infrastructure task, not a model-level configuration. The steps below follow the sequence teams have used successfully in enterprise deployments.

Step 1: Define domain boundaries

Run a domain boundary workshop with domain owners. The output should be explicit: which assets, metrics, glossary terms, and processes belong to each domain. Document ambiguous cases — assets that could belong to multiple domains — and assign them to their primary governing domain with secondary access via the translation layer.

The common mistake at this step is vagueness. “Finance data” is not a domain boundary. “All tables tagged to the Finance schema in the catalog, all certified financial KPIs, and all business glossary terms under the Finance category” is a domain boundary.

Step 2: Assign domain ownership

Each domain needs a named owner. The owner is accountable for: certifying domain assets as production-grade, maintaining domain glossary terms, approving cross-domain context requests, and defining the translation layer for shared assets.

Without named ownership, domain boundaries decay within months. The governance is only as strong as the human accountability behind it.

Step 3: Build domain-specific context stores

Apply domain tagging to catalog assets — every asset should belong to a primary domain. Scope vector store embeddings by domain — the Finance domain’s vector store should contain only Finance-relevant documents. Create domain-specific glossary sections with domain-authoritative definitions. Apply domain RBAC so that agents and users inherit domain access policies from their domain membership.

Step 4: Implement context routing

In the orchestration layer, add domain detection: identify the requesting domain from agent identity or query metadata. Route the query to the appropriate domain context store rather than querying all stores. For multi-domain workflows, implement explicit handoff: the agent switches domains with an explicit context boundary crossing.

Step 5: Build the context map

Document cross-domain data flows. Where Finance depends on HR headcount data, define: who owns the shared asset, what the translation layer converts, and what authorization is required for the cross-domain access. The context map is the governance document for domain boundaries — not just a diagram, but a maintained artifact that evolves with the data estate.

The two common pitfalls to avoid:

Domain boundaries too fine-grained: per-team or per-project domains add overhead without precision gain. Domain size should match organizational accountability — Finance, HR, Marketing, and Engineering are natural domain boundaries; individual analyst pods are not.

No translation layer for shared assets: without a translation layer, cross-domain queries fail instead of translating. The result is agents that can’t answer legitimate cross-domain questions, which erodes trust in the isolation itself.

Shared context — where boundaries need translation

Not all data fits cleanly into a single domain. Customer master data, product catalog, and shared operational metrics need a governance pattern at the boundary — an explicit definition of who owns the shared asset and how it translates across domains.

Four patterns from DDD apply directly:

Shared kernel. A small set of shared context that all domains agree on, governed centrally. The customer ID schema, for example, is a shared kernel — every domain uses the same identifier, and its definition is maintained by a central Customer Data domain. Agents across all domains can reference it without translation.

Customer/supplier. One domain produces context that another consumes. Finance produces the official revenue number that Marketing references in its attribution model. The supplier (Finance) maintains the definition; the consumer (Marketing) references it without redefining it.

Published language. A well-documented shared schema for cross-domain data exchange. Where Finance needs to share P&L summaries with Executive reporting, the published language defines exactly which fields are shared, what they mean, and how freshness is maintained.

Anti-corruption layer. A translation service at domain boundaries that converts context from a “foreign” domain into the local domain’s language. When an HR agent needs to reference Finance compensation budget data, the anti-corruption layer translates Finance’s representation into HR’s terminology before the HR agent sees it.

These patterns are not theoretical infrastructure — they are the governance decisions that determine whether bounded context spaces remain meaningful over time. Teams that define boundaries but not translation layers discover that agents fail at the boundaries rather than isolating correctly within them. The enterprise context layer implementation guide walks through how these patterns apply to production data agent systems.

How Atlan implements bounded context spaces

Atlan’s data domains are the native implementation of bounded context spaces. The product capabilities that enterprises use for data governance — domain boundaries, domain RBAC, domain-scoped business glossary — are the same capabilities that support bounded context spaces for AI agents.

Data domains. Atlan’s data domain feature provides explicit domain boundaries with asset membership. Assets are tagged to their primary domain, and the catalog can filter views, search, and lineage by domain.

Domain RBAC. Access control in Atlan is configurable at the domain level. Agents operating within a domain inherit domain access policies — they see domain-tagged assets and domain-scoped glossary terms. Cross-domain access requires explicit configuration and is auditable.

Domain-scoped glossary. Atlan’s business glossary supports domain scoping. “Revenue” in the Finance domain resolves to Finance’s certified definition when a Finance agent queries via MCP. The domain-specific definition takes precedence over any global definition within that domain context.

Domain asset views. Catalog views in Atlan can be scoped to a domain — agents querying through the MCP server see only the domain-relevant portion of the asset catalog. This is context routing implemented at the catalog level, not as custom orchestration code.

MCP server. The Atlan MCP server exposes domain-governed context as agent-callable tools. An agent that is assigned to the Finance domain and calls the Atlan MCP server retrieves Finance-certified assets, Finance-approved glossary terms, and Finance-relevant lineage. The bounded context is enforced at the protocol layer, not just at the catalog query layer.

Context map. Atlan’s lineage graph shows cross-domain data flows — which tables from one domain feed into tables in another. This is the infrastructure for identifying where domain boundaries need translation layers and where shared kernel assets exist.

For teams implementing context engineering for AI agents, the how to implement enterprise context layer guide covers how Atlan’s domain capabilities connect to the broader context layer architecture.

Real stories from real customers: Domain isolation at scale

"AI initiatives require more context than ever. Atlan's metadata lakehouse is configurable, intuitive, and able to scale to hundreds of millions of assets. As we're doing this, we're making life easier for data scientists and speeding up innovation."

— Andrew Reiskind, Chief Data Officer, Mastercard

Watch Now →

At Mastercard’s scale — hundreds of millions of assets — the value of domain isolation is not optional. When a data scientist in one business unit runs an AI agent against the catalog, the context they retrieve needs to be relevant to their domain and governed to Mastercard’s data standards. Configuring and scoping that context across a multi-domain, multi-region data estate is precisely what bounded context spaces, implemented through domain-aware catalog infrastructure, make possible.

"Context is the differentiator. Atlan gave our teams the shared vocabulary and lineage to move from reactive data management to proactive AI enablement across CME Group."

— Kiran Panja, Managing Director, Data & Analytics, CME Group

Watch Now →

CME Group’s framing — “shared vocabulary” as the foundation of AI enablement — is the bounded context pattern in practice. Before agents can retrieve domain-appropriate context reliably, the vocabulary within each domain needs to be consistent and maintained. The business glossary, scoped to each domain, is what makes “shared vocabulary” operational across a financial market infrastructure environment where domain-specific terminology has legal and regulatory significance.

Domain isolation is not a constraint on AI — it’s what makes AI trustworthy

The instinct when building AI agent systems is to give agents access to as much context as possible. More context means better answers. More data means fewer blind spots. The experience of teams that have shipped production AI in regulated enterprise environments reveals the opposite pattern.

Agents with access to everything retrieve everything — and then resolve conflicts, blend definitions, and surface information across boundaries they shouldn’t cross. The result is high confidence in wrong answers. That is worse than uncertainty.

Bounded context spaces are not a restriction on what AI can do. They are the governance infrastructure that makes AI answers trustworthy enough to act on. A Finance agent that only sees Finance context, with Finance-certified definitions, returns Finance-appropriate answers. An agent that sees everything returns statistically likely answers — which is a different thing, and a less useful one.

The context graph vs. knowledge graph distinction matters here: the value of a context graph is not its breadth — it is its structure. Domain isolation is how that structure translates into reliable, auditable agent behavior.

The teams that invest in domain boundaries, domain ownership, and domain-scoped context stores before deploying agents find that their AI systems earn trust within the organization instead of losing it. Domain isolation is not the overhead before the AI project. It is the condition that makes the AI project work.

FAQs

1. What is a bounded context space for AI?

A bounded context space is a governed, domain-isolated context environment for an AI agent. It defines the set of data, metadata, and terminology the agent can access and reason over — bounded by domain. A Finance agent in a Finance bounded context space retrieves Finance-certified assets, Finance-approved glossary terms, and Finance-relevant lineage — nothing else.

2. What is domain isolation for AI agents?

Domain isolation for AI agents means restricting each agent’s context access to its relevant domain. Finance agents see Finance context. HR agents see HR context. This is enforced through domain-scoped RBAC, domain-specific context stores, and context routing in the orchestration layer that activates the appropriate bounded context space per query.

3. How do bounded contexts from DDD apply to AI?

Eric Evans’ bounded context principle — an explicit boundary within which a domain model applies — translates directly to AI agents. An agent operating across a large data estate faces the same cross-domain ambiguity problems that DDD was designed to solve: same terms with different meanings, cross-domain data access, and context that makes sense in one domain but not in another.

4. What is context contamination?

Context contamination is what happens when an AI agent retrieves cross-domain context that shouldn’t inform its answer. A Finance agent asking about revenue that retrieves Sales pipeline definitions alongside GAAP revenue is experiencing context contamination. The result is answers that blend incompatible definitions — often wrong in ways that are hard to detect without comparing to a known-good source.

5. How do you implement domain-scoped RBAC for AI agents?

Domain-scoped RBAC for AI agents maps agent identity to domain membership, then inherits the domain’s existing access policies. An agent assigned to the Finance domain can only query Finance-tagged catalog assets, Finance-scoped vector store content, and Finance terms in the business glossary. Cross-domain queries require explicit authorization and translation logic.

6. What is a domain context store?

A domain context store is a context retrieval system scoped to a specific domain — a domain-tagged subset of the metadata catalog, a domain-specific vector store containing only domain-relevant documents, and domain-scoped business glossary terms. Agents operating within a bounded context space query only their domain’s context store.

7. How do shared data assets work across bounded context spaces?

Shared assets need a governance pattern at domain boundaries. Common patterns: a shared kernel (shared context governed centrally), customer/supplier (one domain produces context for another), or a published language (a defined shared schema for cross-domain exchange). A translation layer converts context between domain-specific representations.

8. What is a context map for AI agents?

A context map documents how bounded context spaces relate to each other — where they share data, where they need translation, and which domains are upstream or downstream. It defines the translation logic for cross-domain queries and is maintained as a governance artifact alongside the domain boundaries themselves.

Sources

1. Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans (Addison-Wesley)
2. BoundedContext, Martin Fowler’s bliki
3. Data mesh principles and logical architecture, Zhamak Dehghani
4. Model Context Protocol specification, Anthropic
5. Atlan AI context stack guide, Atlan
6. Context graph vs. knowledge graph, Atlan