Skip to main content

How to build enterprise context layer

Connect docs via MCP

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 Studio, which runs a Build, Simulate, and Deploy workflow, with Observe as the feedback channel.

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.

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 Studio, every context repository is versioned and certified, and each certification is logged with the contributor, timestamp, and accuracy score. 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

Versioning, certification history, and event logs give auditors a version history and 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 through a workflow that tests context before production. Context Studio runs a continuous loop.

  1. Build. Context Studio reads your existing catalog (Snowflake schemas, dbt models, BI tools, query history, and your glossary) to generate an initial semantic model for a domain.
  2. Simulate. Run a question set with the semantic model to see which questions land, which miss, and what specific change closes each gap, before exposing the context to agents.
  3. Deploy. Certify the context repository and deploy it. Targets include Snowflake Cortex Analyst, Databricks Genie, and any MCP-compatible agent such as Claude, Cursor, or ChatGPT through the Atlan MCP server.
  4. Observe. Monitor production query traces and feed failures back into the question set. Corrections from production use drive the next certification cycle, so context improves over time. Observe is currently available for Snowflake Cortex deployments.
tip

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

See also​