Skip to main content

What is Context Engineering Studio? Private Preview

Connect docs via MCP

Context Engineering Studio (CES) is Atlan's workspace for building, testing, and deploying the business context AI agents need to answer questions accurately. Describe a domain in the chat window and CES generates a context repository (a versioned bundle of skills, knowledge, and tools) from your data catalog, BI lineage, and semantic sources. The same repository deploys to any MCP-compatible agent, or to Snowflake Cortex and Databricks Genie as deployment targets.

  • Agent-driven, human-guided. The agent generates, tests, and improves the repository at each checkpoint. You review, refine, and approve.
  • Generated from your existing data estate. CES reads your data catalog, BI lineage, glossary, and semantic sources to generate the repository. No manual scaffolding required.
  • One repository, many consumers. Build once. Any MCP-compatible agent, Snowflake Cortex, and Databricks Genie all read the same repository, so every agent gives the same answer.

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 build-test-deploy workflow operates. To enable CES and build your first repository, see Get started.

How context is built. Sources feed Context Agents and Atlan's harness, which produce a context repository of skills, knowledge, and tools that's tested, evaluated, and deployed to consumers, with an Observe feedback loop.

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: generate it, version it, 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, on Snowflake Cortex, Databricks Genie, or any MCP-compatible surface, from pilot to production, and accuracy is the blocker rather than the model. 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 generates a complete first draft from your existing data estate.
  • 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: a bounded, versioned bundle of context for one agent or use case. Context repositories are to AI agents what Git repositories are to software: the versioned source of truth every deployment reads from.

Each repository is built from three primitives, and a reasoning model uses all three together:

  • Skills: How the agent behaves. Named, reusable capabilities (such as "Forecast ARR by segment" or "Diagnose pipeline freshness") authored in markdown with a persona, plus the runtime artifacts (Python, SQL, YAML) the skill invokes.
  • Knowledge: What the agent understands. The semantic model, glossary terms, parsed SOPs, and policies. The shared layer that keeps every consumer answering the same way.
  • Tools: What the agent acts on. Query tools, MCP servers, APIs, and workflow triggers the repository is allowed to use.

Repositories are domain-scoped, so the finance and sales definitions of revenue can both be correct in their own repositories. Once built, a repository is tested once and replayed across every agent or engine that consumes it. For each primitive in depth, including a worked skill-with-artifact example and system versus custom skills, see Skills, knowledge, and tools.

How CES works​

CES operates as an augmented workflow: the agent does the work at each step and you review, refine, and guide. It loops back as many times as needed rather than following a fixed sequence.

The workflow follows four checkpoints:

1. Bootstrap Describe your domain in the chat window. CES searches your Atlan data graph, selects the relevant assets, and generates a complete context repository, including skills, a semantic model, relationships, and verified queries. You receive a complete first draft, not a list of pending suggestions. Review it and refine through chat: add or remove assets, update definitions, or rewrite business logic. 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 domain scope, and runs it on your deployment target. Each failure identifies the exact component to fix: a skill, a knowledge entry, a relationship, or a missing synonym. Review the results and describe fixes in the chat window. To run an evaluation, see Run simulations.

3. Improve CES surfaces fix recommendations from test failures and from live user interactions once deployed. It applies changes it can make confidently. You decide the rest. 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, CES packages a versioned snapshot and publishes it to your target. The repository is stored in an engine-agnostic format and projected into what each target expects, such as a semantic view for Snowflake Cortex or a metric view for Databricks Genie. Redeployments replace the previous version in place with no downtime. See Deploy to Snowflake or Deploy to Databricks.

What CES reads from​

CES reads from your existing data estate rather than starting from scratch. It extracts business logic already embedded across your catalog, BI layer, and semantic sources, then generates a first draft for you to review.

SourceWhat CES extracts
WarehouseTables, columns, primary keys, lineage, and query history. Drives asset ranking, primary-key detection, and relationship and filter inference.
BI dashboards (Tableau, Sigma, Looker, Hex, Power BI)Tile SQL, named measures, filters, and joins. The most reliable signal for how the business actually defines its measures.
Semantic sources (dbt, LookML, Tableau, Cube)Existing semantic definitions, pulled in deterministically. CES enriches your semantic layer rather than replacing it.
GlossaryCertified business terms with column linkages. Resolves ambiguous columns and seeds synonyms and descriptions.
Knowledge folders and filesSOPs, policy PDFs, runbooks, and rules, parsed into custom instructions, filters, or skill entries.

Because CES is a new category of tool, comparing it with familiar tools is the fastest way to place it. Each comparison starts with a short definition, so you can follow along even if you don't use that tool today.

CES and semantic layers​

A semantic layer (such as dbt, LookML, or Cube) defines your metrics, dimensions, and joins in one place, so every tool that queries your data calculates them the same way. CES isn't a semantic layer. A semantic layer answers what a metric means; CES also answers which team the definition applies to, which exceptions to apply, how the agent behaves when asked, and whether the deployed agent answers correctly. The semantic model is one component of knowledge inside a repository, alongside skills and tools. If you already have semantic definitions in dbt, LookML, or Cube, CES reads them deterministically and builds on them rather than replacing them.

CES and prompt engineering​

Prompt engineering is hand-writing and tuning the instructions given to one AI agent. CES isn't prompt engineering. A prompt serves a single agent, is maintained by hand, and gives you no way to know whether it works. A context repository is versioned, tested with an evaluation suite, shared by every agent that consumes it, and improved from production feedback. Editing a prompt fixes one agent once; fixing a repository fixes every consumer permanently.

CES and Atlan's catalog​

The Atlan catalog is the inventory of your data estate: assets, descriptions, glossary terms, and lineage, organized for people to search and understand. The catalog is CES's main input, not an alternative to it. CES packages that knowledge, scoped to one use case, in a form AI agents can consume. Enrichment work you've already done in Atlan, such as certified terms, descriptions, and lineage, directly improves the repositories CES generates.

Where CES is heading​

CES is the engine-agnostic context layer beneath your agents, not a single-engine tool. Today the deploy targets are Snowflake Cortex, Databricks Genie, and MCP-compatible agents, and knowledge centers on the warehouse and glossary. Direction:

  • Knowledge beyond the warehouse: Runtime retrieval from Confluence, Slack, or enterprise search, fetched through tools at query time without first being stored as an asset.
  • Reference, not copy: Repositories that reference shared skills and definitions so a change in one place propagates everywhere.
  • Composition: A scoped repository behaving as a sub-agent, with an orchestrator routing across several of them for larger problems.
  • More surfaces: Additional consumers and the Context Lakehouse (Apache Iceberg) for SQL-based access.

Anything described elsewhere in these docs as available today is marked as such; the items listed here are direction, not commitments.

See also​