Skip to main content
Community Hub
TL;DR

Context Engineering Studio (CES) generates the semantic layer AI agents need to answer questions accurately. CES assembles a context repository for one use case from the governed context in your Atlan catalog and glossary, then renders it as a semantic view for Snowflake Cortex Analyst, metric views for Databricks Genie, MetricFlow models for dbt, and context Claude reads over MCP.

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

What is Context Engineering Studio?

Context Engineering Studio (CES) generates the semantic layer AI agents need to answer questions accurately. Describe the use case, approve the assets CES proposes, and you get a context repository: the canonical definition of what your data means, ready to deploy as a semantic view. CES assembles it from context that your team and Context Agents keep current in Atlan (Context Agents generate and maintain descriptions, metrics, and definitions across your estate). The same repository works across Snowflake Cortex Analyst, Databricks Genie, dbt, and Claude.

  • Deterministic. CES assembles the repository from your governed assets instead of re-deriving it from scratch each time, so the same context produces the same repository.
  • Governed at the source. The repository links to your Atlan assets instead of copying them, so every definition traces back to where it's governed. When a source changes, regenerate the repository to pull the update.
  • A portable semantic layer. Build once. The repository renders into the semantic layer each deployment target expects: a semantic view in Snowflake Cortex Analyst, metric views in Databricks Genie, MetricFlow models in dbt. Agents that read it over MCP get the same definition without a deploy.

This page explains the concepts behind CES: why AI agents need business context, when to use CES, what a context repository is, and how the assemble-and-deploy workflow operates. To enable CES and build your first repository, see Get started.

How context is built. Context Agents generate and maintain your context in Atlan. Context Engineering Studio assembles the slice one use case needs into a context repository, which references those assets rather than copying them. At deploy, the repository is rendered into the format each engine expects.

Why AI agents need business context​

AI agents fail in production not because models can't write SQL, but because they don't know your business. Ask an agent "What was Q4 revenue by region?" and it has to make decisions no model can reason its way to:

  • Which of the three tables containing revenue figures is the certified source of truth.
  • Whether revenue includes intercompany transfers, returns, and refunds (in most companies, it doesn't).
  • Whether Q4 means the calendar quarter or your fiscal quarter.
  • Which rows to exclude by default, such as test accounts or internal orders.

Business context is this layer of meaning between your raw data and a correct answer: definitions, relationships, default filters, business rules, and the procedures your analysts apply without thinking. Today it lives scattered across BI dashboards, dbt models, glossaries, SOP documents, and people's heads. None of it exists in a form an AI agent can consume.

Context engineering is the practice of treating that knowledge the way you treat code: define it in one place, deploy it, and keep it current as the sources change. CES is the workspace where that practice happens.

When to use CES​

Use CES when you're taking a data-answering AI agent from pilot to production and accuracy is the blocker, not the model. That covers agents on Snowflake Cortex Analyst, Databricks Genie, or any agent that reaches your context over MCP. CES addresses the two problems that stall most of these projects:

  • Starting from a blank page. The context an agent needs already exists in your dashboards, queries, and documents, but assembling it by hand takes months. CES assembles a complete first draft from the context already governed in Atlan.
  • Effort that grows with every agent. Restating the same definitions for each new agent means they drift apart. With CES, every agent reads the same repository, so one fix propagates to every consumer.

CES is built for the people who own this work: data engineers, analytics engineers, and the domain experts who hold the business definitions. Access is controlled through a dedicated persona; see Get started.

Context repositories​

A context repository is the unit of work in CES: the canonical definition of what your data means for one use case. It's also a portable semantic layer. One definition renders into whatever each deployment target expects, whether that's a semantic view in Cortex Analyst, metric views in Genie, or MetricFlow models in dbt. CES is the workspace where you build and maintain these repositories.

Scope a repository to the job the agent has to do, not to an org chart. "Answer pipeline questions for the sales ops team" is a use case. "Sales" is not. A narrow repository is easier to test, easier to correct when a question fails, and easier to reason about when two teams define the same word differently.

A repository holds two things:

  • Linked assets: the Atlan assets the repository is built from, such as tables and glossary terms, plus skills for a use case that needs deeper analysis. It references them rather than copying them, so every definition traces back to its governed source. When a source changes, regenerate to pull the update.
  • The semantic model: how those assets answer questions. Dimensions, facts, relationships, derived metrics, filters, and verified queries, plus the custom instructions you write to steer the agent.

The references come from your estate. The model is what CES assembles on top of them. For the contents in depth, see What's in a context repository.

How CES works​

You stay in control at each step. CES proposes, you approve, and you can loop back as many times as you need rather than following a fixed sequence.

The workflow follows three checkpoints:

1. Assemble Describe the use case. CES searches your Atlan data graph and proposes a set of assets with a rationale for each one. You approve that selection, and CES assembles the semantic model from it: dimensions, facts, relationships, and derived metrics. Refine from there by adding or removing assets, editing definitions, or rewriting business logic.

CES doesn't generate the underlying context. Context Agents do that across your estate, and CES assembles the slice this use case needs. To create your first repository, see Build your context repository.

2. Keep it current The repository references its linked assets, so the place to fix a definition is the asset itself. Edit a description, a glossary term, or a mined join on the asset, through whatever governance workflow applies to it. The repository shows a banner that its sources have changed, and you regenerate to pull the update into the semantic model. See Update the context repository.

3. Deploy When the model is right, publish it to your target. The repository is stored in an engine-agnostic format and rendered into what each target expects, such as a semantic view for Snowflake Cortex Analyst or a metric view for Databricks Genie. Redeployments replace what's live in place with no downtime. See Deploy to Snowflake or Deploy to Databricks.

What CES assembles from​

CES assembles a repository from context that's already governed in Atlan rather than starting from scratch. Most of that context is mined and kept current by Context Agents, which read across your estate (query history, BI tile SQL, and semantic sources) and enrich your Atlan assets. CES then assembles the use-case slice from those governed assets.

Source in AtlanWhat CES uses
Warehouse tables and columnsTables, columns, primary keys, and lineage. The backbone of the model: asset selection, primary-key detection, and relationship inference.
GlossaryCertified business terms with column linkages. Resolves ambiguous columns and seeds descriptions.
Column profilesTop values per column (columnTopValues), written by a profiling playbook. CES uses these as sample values. Columns that haven't been profiled have no sample values in the model.
Asset names and aliasesSynonyms. CES reads displayName first and falls back to assetAiAlias only when displayName is empty. The two aren't merged. assetAiAlias takes comma-separated values and is set through the API.
Enriched asset metadataThe descriptions, metrics, and SQL intelligence Context Agents have written back onto your assets. This is where BI and query-history signal reaches CES, already governed as asset metadata. Joins, filters, and business questions are editable on the asset's Usage & Intelligence tab, so a wrong insight is fixed once at the source and every repository that regenerates inherits the fix.

CES uses whatever exists today. A table with no query history still produces a model, grounded in catalog metadata alone: descriptions, business rules, and glossary terms. Once that table sees real usage and Context Agents enrich it, regenerating the model folds the new context in. CES doesn't query your warehouse or generate metadata during a build. It reads what's already on your assets, so run profiling and curate aliases before you regenerate.

To use a different source for any part of the model, name it in chat. For example, point CES at a glossary term that lists your dimensions, or at a file of synonyms. CES gives the source you name priority over the default field, such as displayName for synonyms or columnTopValues for sample values.

See also​