Skip to main content
Community Hub
TL;DR

Build an enterprise context layer for AI agents across multiple domains, governed for compliance, using Atlan Context Engineering Studio and the Atlan MCP server.

Your AI can read this via Docs MCPcurl -fsSL "https://docs.atlan.com/install-docs-mcp" | bashConnect

How to build enterprise context layer

Atlan is the enterprise context layer for AI—the governed tier between your data estate and your agents, built from metadata, lineage, and policy.

An enterprise context layer is the governed tier between your data estate and your AI agents. It translates metadata into business meaning that every agent can act on. Context layers serve AI agents. Semantic layers serve BI tools. The difference is governance.

You build it in four phases: map authoritative context sources, unify them into one governed graph, apply federated domain ownership and compliance policy, then activate context for agents. Atlan supports this with Context Engineering Studio, which assembles a context repository from governed assets and deploys it to each engine.

This guide is for CDOs, CIOs, and platform leads running a multi-domain estate. If you are building for a single team or a single domain, see How to build a context layer instead.

Prerequisites​

  • An Atlan workspace with the admin role.
  • At least one connected source (warehouse, BI tool, or transformation layer) from Atlan's connector catalog.
  • Identified business domains and accountable domain owners. This is a governance exercise, not a UI step.
  • A prioritized list of AI use cases the context layer must serve first.
  • An access policy framework already in place at the data layer. The context layer overlays existing policy. It doesn't replace it.
note

Enterprise rollouts typically scope the first phase to one or two priority domains. Estate-wide expansion is a multi-quarter program.

Start with field guide​

Before you architect an enterprise context layer, read the field guide WTF Is the Context Layer. It frames the governance-first decisions the phases below assume, and why a context layer serves agents where a semantic layer serves BI tools.

  1. Read the field guide, WTF Is the Context Layer, before you design your architecture.
  2. For how the concept maps to Atlan, see Context layer.

Phase 1: Identify where context already lives​

Before unifying anything, inventory where canonical meaning already lives. Warehouses, BI tools, dbt projects, glossaries, runbooks, and Git repositories all hold partial context that the layer must consolidate.

  1. List authoritative context sources by domain: warehouse, BI, dbt, Git, runbooks, and glossary tools.
  2. Connect those sources to Atlan from the connector catalog.
  3. Confirm asset coverage in the populated metadata graph before moving on. Atlan reconstructs lineage using approaches such as SQL parsing, API crawling, and related source metadata, not only declared dependencies.
  4. Flag domains that lack a clear owner. This is a governance gap to close before Phase 3.
tip

Start with the domains backing your priority AI use cases. Estate-wide coverage is the goal, not the starting line.

Phase 2: Unify metadata into one governed graph​

A graph that spans every domain replaces the per-tool semantic silos that cause agents to give different answers to the same question.

  1. Use lineage to confirm that cross-system relationships are captured. Atlan reconstructs column-level lineage across warehouses, pipelines, and BI tools.
  2. Add business glossary terms and link them to physical assets in each domain. The glossary is the shared source of truth that keeps a term's meaning consistent across domains.
  3. Run context agents to draft descriptions, higher-level README documentation, and SQL usage intelligence at scale. The currently available agents are Description, README, and SQL Intelligence. Link Terms is coming soon.
  4. Resolve conflicts where the same term means different things in different domains. Domain owners arbitrate. The context layer records the canonical definition and the rationale.
note

Atlan MCP documents write-back tools for metadata, glossary, and tags. As teams review, correct, and update context, that governed context compounds over time.

Phase 3: Govern at enterprise scale​

Enterprise differs from single-team in three ways: multi-domain ownership, compliance overlay, and federated policy enforcement. Set those up before any agent touches production data.

  1. Assign domain ownership. Each domain has one accountable owner who approves definitions and policy exceptions.
  2. Configure access policies that govern what each agent can see and act on, scoped by domain.
  3. Track changes to context. In Context Engineering Studio, the Activity tab on each context repository shows what changed upstream since the model was last built, and who changed it. Use Atlan event logs to review metadata changes across the workspace.
  4. Align your access policies and retention to your GDPR, SOX, or CCPA obligations.
note

Activity history and event logs give auditors an evidence layer. They don't replace your compliance program.

Phase 4: Activate context for agents​

With the governed graph in place, expose it to AI agents. Context Engineering Studio assembles and deploys the context.

  1. Build. Context Engineering Studio assembles a semantic model for a domain from the context already governed in Atlan: tables and columns, glossary terms, and the metadata Context Agents have written onto your assets.
  2. Deploy. Deploy the context repository. Targets include Snowflake Cortex Analyst, Databricks Genie, and any MCP-compatible agent such as Claude, Cursor, or ChatGPT through the Atlan MCP server.
  3. Keep it current. When a linked asset changes upstream, the repository flags it. Regenerate and redeploy so agents read the current definitions.
tip

Start with one priority domain and one agent before scaling to the rest of the estate.

See also​