Skip to main content
Community Hub
TL;DR

Context Engineering Studio (CES) is Atlan's workspace for assembling, testing, and deploying the business context 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 makes it available to Snowflake Cortex Analyst, Databricks Genie, dbt, and Claude.

Your AI can read this via Docs MCPInstall MCP →Connect

What is Context Engineering Studio?

Context Engineering Studio (CES) is Atlan's workspace for assembling, testing, and deploying the business context 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. 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-test-improve-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, test it on real business questions, deploy it, and improve it from production feedback. 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 three 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.
  • No definition of done. Without tests, you find out an agent is wrong when your users do. CES turns business questions and verified answers into an evaluation suite, so you know the agent is ready before you deploy it.
  • 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 four 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. Test CES autogenerates an evaluation set (business questions paired with verified answers) from your repository's assets, metrics, and scope, and runs it on your deployment target. Each failure identifies the exact thing to fix: a description, a relationship, a filter, or a missing synonym. Review the results, then update the linked assets or custom instructions and regenerate, or describe the change and let CES apply it. To run an evaluation, see Run simulations.

3. Improve CES surfaces fix recommendations from test failures. You apply them by updating the governed assets or the repository's custom instructions and regenerating, then re-run the evaluation to confirm targeted questions now pass and nothing regressed. The context sharpens with each iteration.

4. Deploy When the repository answers the questions the business actually asks, 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 synonyms and descriptions.
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.

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. Enabling Data Exploration lets CES read sample values from your tables, which sharpen the model.

See also​