--- title: "How to Build AI-Ready Data From Day Zero in a New Data Stack" url: "https://atlan.com/know/ai-agent/ai-ready-data/build-ai-ready-data-from-day-zero/" description: "How to build AI-ready data from day zero in a new data stack: write meaning, owners and policy into the build, scoped to your first agent, then gate on an eval." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-11-06" updated: "2026-11-06" --- ## How do you build AI-ready data from day zero in a new data stack? Pick one agent use case and write down the questions it must answer, each with a reference answer. Then make context part of the build: descriptions, owners and domains in the model YAML, sensitivity tags applied on every build, lineage from the first run. Add contracts and certificates only to the models that agent reads, and release it only after a known-answer eval passes. The 7 build-time steps: - **Name the use case** and its questions - **Require minimum context** on every model - **Tag sensitive columns** and bind policy to the tag - **Emit lineage** from the first run - **Promote agent-facing models** with contracts and terms - **Deliver context** to the agent through MCP - **Gate the release** on a known-answer eval ## Key takeaways - Scope readiness to one named agent use case and its real questions before you govern anything. - Every model ships with a description, owner, domain and sensitivity class from its first commit. - Contracts, glossary terms and certificates go only on the models the first agent reads. - A known-answer eval in CI gates the agent release; a pass is the owner's cue to certify. --- Building AI-ready data from day zero means writing each model's meaning, owner, sensitivity and lineage into the code that creates it, scoped to your first agent use case, then proving fitness with a known-answer eval before the agent ships. Seven build-time steps make that concrete; three can block a merge or a release. Atlan's context layer reads the descriptions, owners, certificates, tags and glossary terms you write in your dbt project, so the first agent works from owned, reviewed context. ### Audit Your First Agent's Data in Twelve Checks Give it one business question and the data behind it. It runs twelve pass, fail or unknown checks across meaning, trust, boundaries and reproducibility, and names the artifact to fetch for every unknown. [Read the skill](/skills/ai-ready-data-audit.md). *Paste into a new chat* ``` Use the skill at https://atlan.com/skills/ai-ready-data-audit.md to audit whether the data behind my first AI agent use case is ready before the agent ships. Ask me for whatever it needs. ``` *Run once in a terminal* ``` curl -fsSL --create-dirs \ -o ~/.agents/skills/ai-ready-data-audit/SKILL.md \ https://atlan.com/skills/ai-ready-data-audit.md ``` *For an agent* ``` curl -fsSL https://atlan.com/skills/ai-ready-data-audit.md ``` Human Agent ClaudeChatGPTGeminiCursorOther Copy --- A new stack has one advantage an old one never gets back: you can ask the person writing a column what it means before anyone depends on it. According to Gartner's Rita Sallam, Distinguished VP Analyst, in [AI-ready data essentials (Gartner)](https://www.gartner.com/en/articles/ai-ready-data): "There is no way to make data AI-ready in general or in advance. The readiness of data for AI depends on how the data will be used." Day zero works with that, as long as the use case is named before the models are written. | Step | What you build | Where it lives | Tier | Blocks | |---|---|---|---|---| | 1 | The use case and its questions | Use-case spec in the repo | Scope | Nothing yet | | 2 | Minimum context on every model | dbt YAML plus CI | 1 | The merge | | 3 | Column tags with policy bound to the tag | dbt post-hook plus warehouse policy | 1 | Unmasked reads | | 4 | Lineage from the first run | dbt plus OpenLineage | 1 | Nothing | | 5 | Contracts, terms and certificates on agent-facing models | dbt contract or ODCS, Atlan keys in dbt | 2 | The build | | 6 | Context delivery through MCP | Agent runtime config | 2 | Nothing | | 7 | A known-answer eval, then certification | CI plus owner review | 2 | The release | --- ## Why build AI-ready data into a new stack instead of retrofitting a context layer later? Building context into a new stack is easier than reconstructing it later, because at creation the author knows what each column means. That knowledge is the gap between [AI-ready and analytics-ready data](https://atlan.com/know/ai-agent/ai-ready-data/ai-ready-data-vs-analytics-ready-data/): analytics-ready data often left the last piece of meaning to an analyst who knew the business. Forrester analysts wrote in [Build Meaning Before Machines (Forrester, 2026)](https://www.forrester.com/blogs/build-meaning-before-machines-why-semantics-ontologies-and-knowledge-graphs-matter-for-agentic-ai/): "Data without meaning is unusable for autonomous systems." According to [Rumiantsau and Fokeev (2026)](https://arxiv.org/abs/2604.25149), a 4 KB business-semantics document raised text-to-SQL accuracy by 17 to 23 percentage points across three frontier models on 100 questions. Within each condition the three models were statistically indistinguishable. | Dimension | Day zero | Retrofit (existing estate) | |---|---|---| | Who supplies meaning | The model author, in the model file | Reconstructed from analysts, dashboards and owners | | When the owner is set | At first commit | Assigned after the fact | | Where context lives | In the repo, next to the code | In a catalog or wiki, added later | | Sensitivity | Tagged at creation, policy bound to the tag | Found by scanning, then remediated | | Lineage | Emitted by the pipeline | Mapped from logs and query history | | Scope | The first use case's models | The sources an agent already touches | Start here for a new warehouse, domain or first agent. For an estate already in production, [preparing enterprise data for AI agents](https://atlan.com/know/ai-agent/data-for-ai/how-to-prepare-enterprise-data-for-ai-agents/) and [extending your data catalog for AI readiness](https://atlan.com/know/ai-agent/ai-ready-data/extend-data-catalog-for-ai-readiness/) fit better. According to [Gartner (2026)](https://www.gartner.com/en/newsroom/press-releases/2026-05-11-gartner-says-lack-of-semantics-causes-inaccurate-artificial-intelligence-agents-and-wasted-spending), "Gartner advises data and analytics (D&A) leaders to establish a context layer as a core component of their D&A infrastructure." [Atlan's documentation (Atlan docs)](https://docs.atlan.com/agents/concepts/ai-ready-data) builds readiness "asset by asset, use case by use case, starting with the specific domain an agent works on first." On a new stack, that layer can exist the day the tables do, an early answer to the [AI agent cold-start problem](https://atlan.com/know/ai-agent-cold-start-problem/). --- ## What do you need before you start building? You need one funded agent use case, models in version control, a warehouse that supports object tags, and a named owner for each domain the first use case touches. | Requirement | Why it matters | |---|---| | One agent use case with a business sponsor | Readiness is judged against a job | | A domain owner who can certify | Someone signs for meaning | | Models in git, CI on pull requests | Context gets reviewed like code | | Warehouse object tags and masking | Policy follows the tag | | A lineage emitter and a way to serve context to the agent | Context reaches the agent | The team is four roles: an AI lead who owns the eval, an analytics engineer who writes Tier 1, a domain owner who signs, and a platform engineer for CI and context delivery. According to [McKinsey (2026)](https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/ai-data-readiness-the-key-to-scaling-impact), the aim is to "define what "good enough" means for each use case based on business needs and the risk profile of the data and related business processes". [Who owns the context layer](https://atlan.com/know/context-layer-ownership-data-vs-ai-teams/), [AI-ready data owners and stewards](https://atlan.com/know/ai-agent/ai-ready-data/ai-ready-data-owners-and-stewards/) and [AI data architecture](https://atlan.com/know/ai-readiness/data-architecture-ai/) cover the roles and platform. --- ## Step 1: Name the first agent use case and the questions it must answer You finish this step with one named agent use case, its business owner, and a set of real questions, each with a reference query and its expected result. That list is the scope gate: a model gets Tier 2 controls only if one of these questions reads it. **Effort:** Low. It scales with stakeholder availability. 1. Pick a use case tied to a funded need, such as a [talk-to-data agent](https://atlan.com/know/ai-agent/ai-ready-data/ai-ready-data-for-talk-to-data/) for finance or [text-to-SQL for the enterprise](https://atlan.com/know/ai-agent/data-for-ai/text-to-sql-for-enterprise/). 2. Collect questions from the people who will use the agent, for example "What was `net_revenue` for EMEA in Q2 2026?" Pin each to a fixed period so the answer does not drift. 3. Store the reference as SQL plus its result, and set the "good enough" bar for this use case's risk. With 20 questions, each failure moves the pass rate by 5 points, so also mark the few that must always pass. **Check:** questions and reference queries sit in the repo. The [talk-to-data agent blueprint](https://atlan.com/know/ai-agent/talk-to-data-agent-blueprint/) and [preparing data for natural-language analytics](https://atlan.com/know/ai-readiness/how-to-prepare-data-for-natural-language-analytics/) show good question sets. Take questions from users, since the data team tends to test what it already knows. --- ## Step 2: Require a minimum context block on every new model You finish this step with a rule: no model merges without a description, an owner, a domain group and a sensitivity class in its YAML, checked in CI. **Effort:** Low. A few lines per model, plus a one-time CI setup. Mature dbt teams already enforce a block like this; on a new stack you can require it before the first model merges. According to [dbt's documentation on groups (dbt)](https://docs.getdbt.com/docs/build/groups), "Groups are named, and every group has an owner." The table is the two-tier context gate: what every model carries, and what only agent-facing models add. | Context element | Tier | Where you write it at build time | What enforces it | |---|---|---|---| | Model and column descriptions | 1 | dbt `description`, persisted with `persist_docs` | CI check | | Owner and domain | 1 | dbt group owner and `meta` owner | CI check | | Sensitivity class | 1 | Column `meta` in YAML, applied as a warehouse tag by a post-hook | Tag-based masking (Step 3) | | Lineage | 1 | dbt graph; OpenLineage for other pipelines | Emitted by the run | | Glossary term | 2 | Atlan keys in dbt `meta` | Owner review | | Contract | 2 | dbt `contract: enforced: true` or ODCS | Build fails on mismatch | | Certificate | 2 | Draft at build, Verified after the eval | Owner, through a pull request | | Known-answer eval | 2 | Question set from Step 1 | Release gate (Step 7) | The YAML follows [dbt's current `meta` reference (dbt)](https://docs.getdbt.com/reference/resource-configs/meta), which places `meta` under `config` (changed in v1.10 and backported to 1.9). *models/marts/finance/_finance.yml* ```yaml groups: - name: finance owner: email: finance-data@example.com models: - name: fct_orders description: "One row per order line, net of returns and discounts." config: group: finance meta: owner: "finance-data@example.com" sensitivity: "financial" columns: - name: net_revenue description: "gross_revenue - returns - discounts, in USD, at order date." - name: customer_email description: "Email address of the ordering customer." config: meta: sensitivity: "pii" ``` *dbt_project.yml* ```yaml models: my_project: +persist_docs: relation: true columns: true ``` 1. Add the Tier 1 fields to your model YAML template. 2. Turn on [`persist_docs` (dbt)](https://docs.getdbt.com/reference/resource-configs/persist_docs), off by default, so descriptions land as warehouse comments. 3. Add a CI check over dbt's [`manifest.json` (dbt)](https://docs.getdbt.com/reference/artifacts/manifest-json), which holds every model's configuration, and fail any pull request where a new model lacks a description, a group, an owner or a sensitivity class. **Check:** a model without an owner fails CI. Descriptions state the business rule behind each column and feed the [semantic layer](https://atlan.com/know/semantic-layer/), the [dbt Semantic Layer](https://atlan.com/dbt-semantic-layer/) and your [KPI definitions and business glossary](https://atlan.com/know/ai-agent/how-to-manage-kpi-definitions-and-a-business-glossary-in-a-data-catalog/). --- ## Step 3: Tag sensitive columns at creation and bind access policy to the tag Every personal or restricted column ends this step tagged on each build of its table and protected by a tag-based masking policy. **Effort:** Low to medium. It scales with the number of sensitivity classes. According to [Snowflake's tag-based masking documentation (Snowflake)](https://docs.snowflake.com/en/user-guide/tag-based-masking-policies), when the policy's data type matches the column's, "the tagged column is automatically protected by the conditions in the masking policy." Each tag takes one masking policy per data type. A tag set on a schema also covers columns in newly added tables, but it masks every column there whose data type matches, so keep schema-level tags for schemas that hold only sensitive data. ```sql CREATE TAG governance.tags.pii; CREATE MASKING POLICY governance.policies.pii_string_mask AS (val STRING) RETURNS STRING -> CASE WHEN IS_ROLE_IN_SESSION('PII_READER') THEN val ELSE '***MASKED***' END; ALTER TAG governance.tags.pii SET MASKING POLICY governance.policies.pii_string_mask; ``` *models/marts/finance/_finance.yml, added to the fct_orders entry* ```yaml config: post_hook: - "ALTER TABLE {{ this }} MODIFY COLUMN customer_email SET TAG governance.tags.pii = 'email'" ``` 1. Define a short sensitivity set, such as `pii`, `financial` and `public`, as [Snowflake object tags (Snowflake)](https://docs.snowflake.com/en/user-guide/object-tagging). 2. Apply column tags in a [dbt post-hook (dbt)](https://docs.getdbt.com/reference/resource-configs/pre-hook-post-hook), which runs after each build of the model, so the tag is set again whenever dbt rebuilds the table. Snowflake recommends [`IS_ROLE_IN_SESSION` (Snowflake)](https://docs.snowflake.com/en/sql-reference/functions/is_role_in_session) when a policy must respect role hierarchy. 3. In Atlan, turn on [tag propagation (Atlan docs)](https://docs.atlan.com/product/integrations/automation/always-on/references/tag-propagation), off by default, so downstream columns carry the tag in Atlan through lineage. Warehouse masking still depends on the Snowflake tag on each table the agent can query. **Check:** a role without `PII_READER` sees masked values in every table the agent can reach. [Handling PII in AI pipelines](https://atlan.com/know/ai-agent/data-for-ai/how-to-handle-pii-in-ai-pipelines/) and [access control for AI agents](https://atlan.com/know/ai-agent-access-control/) cover policy design. --- ## Step 4: Emit lineage from the first pipeline run Lineage for every model the first use case reads should come from the tools that build the data. **Effort:** Low for dbt models; medium for pipelines outside dbt. Lineage is the path Step 3's tags travel in Atlan, and the trail an owner follows when an eval answer comes back wrong. 1. Let the dbt graph define model lineage. Atlan [crawls dbt Core (Atlan docs)](https://docs.atlan.com/apps/connectors/etl-tools/dbt/references/what-does-atlan-crawl-from-dbt-core) models and sources with their descriptions and tags, and builds column-level lineage for dbt models and the tables they materialize. 2. For pipelines outside dbt, emit [OpenLineage (OpenLineage)](https://openlineage.io/docs/) events, an open standard for lineage metadata; [OpenLineage with Airflow](https://atlan.com/know/ai-agent/data-for-ai/airflow-openlineage-for-ai/) shows the setup. 3. Trace each Step 1 question back to its sources. **Check:** no orphan tables sit in the use case's path. [Data lineage for AI](https://atlan.com/know/ai-agent/data-for-ai/data-lineage-for-ai/) and [AI-ready data lineage](https://atlan.com/know/ai-readiness/ai-ready-data-lineage/) go deeper. --- ## Step 5: Promote agent-facing models with a contract, glossary terms and a Draft certificate You finish this step with the models the first use case reads moved to Tier 2: an enforced contract, glossary terms on business columns, and a Draft certificate. **Effort:** Medium. It scales with the number of agent-facing models. The strongest objection to day-zero governance lives here. [dbt's model contracts documentation (dbt)](https://docs.getdbt.com/docs/mesh/govern/model-contracts) warns: "Introducing governance while models are still changing can complicate future changes." The same page recommends contracts for models others rely on downstream, and the first agent is exactly that consumer. Staging models stay free to change. 1. Set `contract: enforced: true` on agent-facing models. dbt runs a preflight check, and the model fails to build if column names and types do not match. 2. If contracts must travel across tools, use the [Open Data Contract Standard v3.2.0 (Bitol)](https://bitol-io.github.io/open-data-contract-standard/v3.2.0/home/); [Bitol's 2026 release (Bitol)](https://bitol.io/data-contracts-data-products-for-ai/) says it "brings context for AI systems". 3. Add owners, terms and a Draft certificate through dbt `meta`, which [Atlan reads from dbt (Atlan docs)](https://docs.atlan.com/apps/connectors/etl-tools/dbt/how-tos/update-atlan-through-dbt). The keys are copied from Atlan's dbt examples for [certificates (Atlan docs)](https://docs.atlan.com/product/capabilities/build-apps/sdks/python/how-tos/certify-assets), [owners (Atlan docs)](https://docs.atlan.com/product/capabilities/build-apps/sdks/python/how-tos/change-owners) and [terms (Atlan docs)](https://docs.atlan.com/product/capabilities/build-apps/sdks/python/how-tos/link-terms). `ownerUsers` takes Atlan usernames; use `ownerGroups` for a team. ```yaml models: - name: fct_orders meta: atlan: attributes: ownerGroups: ["finance-data"] certificateStatus: DRAFT certificateStatusMessage: >- Agent-facing for the EMEA revenue agent. Verified after the eval passes. columns: - name: net_revenue meta: atlan: termNames: - "Finance@Net Revenue" ``` Atlan's examples put `meta` directly on the model, while dbt's current docs nest it under `config`. Confirm which placement your Atlan dbt connection reads before you merge these keys into the Step 2 template. Keep the certificate in one place: if dbt `meta` sets it, move Draft to Verified with a reviewed pull request, so the YAML and Atlan never disagree. Assets that still lack descriptions can be drafted by [Context Agents](https://atlan.com/know/context-agents/), which, per [Atlan's documentation (Atlan docs)](https://docs.atlan.com/product/capabilities/governance/context-agents-studio/concepts/agents), enrich only assets missing the attribute and leave values a person or source system wrote, including warehouse comments from `persist_docs`. The owner reviews each draft, the pattern behind [context bootstrapping](https://atlan.com/know/context-bootstrapping/). **Check:** a type change breaks the build, and every business column on the surface has a term. Never bulk-accept AI drafts. --- ## Step 6: Deliver the context to the agent through MCP The goal here is an agent that pulls context from one service at query time and runs its SQL as the user who asked. **Effort:** Low to medium. An agent with a schema-introspection tool can read warehouse comments and tags. Owners, terms, certificates and cross-tool lineage need a service, and a copy pasted into each AI tool drifts. Per the [Atlan MCP overview (Atlan docs)](https://docs.atlan.com/product/capabilities/atlan-ai/how-tos/atlan-mcp-overview), Atlan MCP is "a hosted server, available on every Atlan tenant with nothing to install," its tools cover "search, lineage, metadata, glossary, governance, and data quality," and "every action respects the permissions you've already set in Atlan." Those permissions decide what context the agent sees. Snowflake roles and masking decide what data its SQL returns. 1. Connect the agent runtime to the MCP server; see [what is Atlan MCP](https://atlan.com/know/what-is-atlan-mcp/) and [an MCP server for dbt](https://atlan.com/know/mcp/mcp-server-for-dbt/). 2. Run the agent's SQL under the end user's warehouse role rather than a shared service role, so Step 3's masking applies to each person. 3. Point the eval environment at Draft models and production at Verified ones. [Context Engineering Studio (Atlan docs)](https://docs.atlan.com/product/capabilities/governance/context-engineering-studio/concepts/what-is-context-engineering-studio), available by enablement, assembles a context repository for one use case from your catalog and glossary. **Check:** asked about `fct_orders.net_revenue`, the agent returns the Net Revenue definition and owner, and a user without `PII_READER` who asks for customer emails gets masked values. [Context engineering](https://atlan.com/know/what-is-context-engineering/), [an AI agent harness](https://atlan.com/know/how-to-build-ai-agent-harness/), [a semantic layer for AI agents](https://atlan.com/know/ai-agent/semantic-layer-for-ai-agents/) and [AI-ready data over MCP](https://atlan.com/know/ai-agent/ai-ready-data/ai-ready-data-mcp/) cover the runtime side. --- ## Step 7: Gate the agent release on a known-answer eval, then certify You finish this step with an eval that runs the Step 1 questions on every agent-facing change, blocks the release below the "good enough" bar, and tells the owner which models can move to Verified. **Effort:** Medium, and recurring. 1. Run the question set in CI when an agent-facing model or its context changes. Compare result sets, not SQL text, and run each question more than once, since agent output varies. 2. Fix the layer that failed. If the agent joins `orders` to `customers` on `account_id` instead of `customer_id`, declare the key with dbt [`primary_key` and `foreign_key` constraints (dbt)](https://docs.getdbt.com/reference/resource-properties/constraints), which dbt lists as not enforced on Snowflake, then fix the column description and glossary term. Leave the prompt alone. 3. Release only above the bar. The owner then moves the models the passing questions read from Draft to Verified. **Check:** the pass rate is recorded per release, and each failure is traced to retrieval, context, SQL generation or execution. Avoid tuning prompts until the eval passes, and testing only at launch. See [context testing for AI agents](https://atlan.com/know/ai-agent/ai-agent-evals/what-is-context-testing-for-ai-agents/), [context evals vs data quality testing](https://atlan.com/know/ai-agent/ai-agent-evals/context-evals-vs-data-quality-testing/) and [data quality for AI agents](https://atlan.com/know/data-for-ai/data-quality-for-ai-agent/). --- ## What are the most common mistakes when building AI-ready data from day zero? Day-zero programs usually fail in one of two opposite directions: governing everything before the first agent exists, or governing nothing because the stack is "still new". Governing everything up front slows every change, which is dbt's warning about models in flux. Governing nothing is the more common gap. According to [Gartner (2025)](https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk), "Sixty-three percent of organizations either do not have or are unsure if they have the right data management practices for AI", from a survey of 1,203 data management leaders. Context kept in a wiki or spreadsheet drifts from the code as soon as models change. Keep it in the model file and [fix data quality problems at the source](https://atlan.com/know/data-governance/how-to-fix-data-quality-problems-at-the-source-with-governance/). An agent that ships with no eval gate gets judged on its first wrong answer in front of a business user. --- ## How does Atlan help you build AI-ready data from day zero? Atlan's context layer reads the context your team writes at build time and serves it to agents. One dbt project feeding one agent can start from dbt's own artifacts and warehouse comments. The layer earns its place once owners sit outside dbt, lineage crosses tools, certification needs a workflow, or a second agent needs the same context. - Your dbt `meta` sets descriptions, owners, certificates, tags, terms and domains on dbt assets and the assets dbt materializes, per [Atlan's dbt documentation (Atlan docs)](https://docs.atlan.com/apps/connectors/etl-tools/dbt/how-tos/update-atlan-through-dbt). - Column-level lineage comes from the dbt crawl, and tag propagation carries tags along it. - Context Agents draft what is still blank and leave written values alone. - Atlan MCP serves it all to agents under the permissions set in Atlan; Context Engineering Studio, available by enablement, packages it per use case. [Implementing an enterprise context layer for AI](https://atlan.com/know/how-to-implement-enterprise-context-layer-for-ai/), [data catalog vs context layer](https://atlan.com/know/data-catalog-vs-context-layer/) and [what is a context graph](https://atlan.com/know/what-is-a-context-graph/) explain the architecture. --- ## How do you keep day-zero context current after the first agent ships? Day-zero context stays useful only if the same checks run on every change and the next use case reuses what the first certified. - Keep the CI checks and eval gate on, and watch for [context drift](https://atlan.com/know/context-drift-detection/) when sources or definitions change. - Track two numbers: the share of agent-facing models with complete Tier 2 context, and the eval pass rate per release. - Start use case two from the certified terms and owners, and promote only the new models it reads. - Before each new use case, re-run the [AI-ready data checklist](https://atlan.com/know/ai-agent/data-for-ai/ai-ready-data-checklist/) or an [AI readiness assessment](https://atlan.com/know/ai-agent/data-for-ai/ai-readiness-assessment/); [what makes data AI-ready](https://atlan.com/know/ai-agent/data-for-ai/what-makes-data-ai-ready/) and the [AI readiness guide](https://atlan.com/know/ai-readiness/ai-ready-data/) set the baseline. Measure the payback: how long use case two takes to reach its eval bar, against how long use case one took. --- ## FAQs about building AI-ready data from day zero ### 1. What does AI-ready data from day zero mean? It means each model's meaning, owner, sensitivity and lineage are written into the code that creates it, scoped to the first agent use case. Readiness is then proved with a known-answer eval for that use case, because Gartner defines AI-ready data by fitness for a specific use, not as a general property. ### 2. How is building AI-ready data from day zero different from preparing existing data for AI? On day zero, the person who writes the model supplies its meaning and owner in the model file, and the checks run inside the build. Preparing existing data means reconstructing that meaning after the fact, for an estate that already has consumers. ### 3. Do you need data contracts on every model in a new data stack? No. Put enforced contracts on the models your first agent reads and leave staging models free to change. dbt's own documentation warns that introducing governance while models are still changing can complicate future changes. ### 4. How much effort does day-zero context add to a new data stack? The minimum context block adds a few lines per model. Contracts, glossary terms, certification and evals scale with the number of agent-facing models. ### 5. What tools do you need to build AI-ready data in a new data stack? You need models in version control with CI on pull requests, a warehouse with object tags and tag-based masking, a lineage emitter such as OpenLineage, and a way to serve context to agents, such as a context layer with an MCP server. ### 6. Can AI write the metadata for a new data stack? AI can draft descriptions for columns that are still blank, and the owner reviews them before certifying. Wretblad and colleagues found that generated column descriptions consistently improved text-to-SQL, while ambiguous columns still needed manual expert input. --- ## Sources 1. [AI-Ready Data Essentials to Capture AI Value, Gartner](https://www.gartner.com/en/articles/ai-ready-data) 2. [Lack of AI-Ready Data Puts AI Projects at Risk, Gartner (February 26, 2025)](https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk) 3. [Gartner Says Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending, Gartner (May 11, 2026)](https://www.gartner.com/en/newsroom/press-releases/2026-05-11-gartner-says-lack-of-semantics-causes-inaccurate-artificial-intelligence-agents-and-wasted-spending) 4. [AI data readiness: The key to scaling impact, McKinsey (June 23, 2026)](https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/ai-data-readiness-the-key-to-scaling-impact) 5. [Build Meaning Before Machines: Why Semantics, Ontologies, And Knowledge Graphs Matter For Agentic AI, Forrester (June 2, 2026)](https://www.forrester.com/blogs/build-meaning-before-machines-why-semantics-ontologies-and-knowledge-graphs-matter-for-agentic-ai/) 6. [Semantic Layers for Reliable LLM-Powered Data Analytics: A Paired Benchmark of Accuracy and Hallucination Across Three Frontier Models, arXiv:2604.25149 (April 28, 2026)](https://arxiv.org/abs/2604.25149) 7. [Synthetic SQL Column Descriptions and Their Impact on Text-to-SQL Performance, arXiv:2408.04691](https://arxiv.org/abs/2408.04691) 8. [Add groups to your DAG, dbt Developer Hub](https://docs.getdbt.com/docs/build/groups) 9. [meta, dbt Developer Hub](https://docs.getdbt.com/reference/resource-configs/meta) 10. [persist_docs, dbt Developer Hub](https://docs.getdbt.com/reference/resource-configs/persist_docs) 11. [Manifest JSON file, dbt Developer Hub](https://docs.getdbt.com/reference/artifacts/manifest-json) 12. [pre-hook & post-hook, dbt Developer Hub](https://docs.getdbt.com/reference/resource-configs/pre-hook-post-hook) 13. [Model contracts, dbt Developer Hub](https://docs.getdbt.com/docs/mesh/govern/model-contracts) 14. [constraints, dbt Developer Hub](https://docs.getdbt.com/reference/resource-properties/constraints) 15. [Tag-based masking policies, Snowflake Documentation](https://docs.snowflake.com/en/user-guide/tag-based-masking-policies) 16. [Introduction to object tagging, Snowflake Documentation](https://docs.snowflake.com/en/user-guide/object-tagging) 17. [IS_ROLE_IN_SESSION, Snowflake Documentation](https://docs.snowflake.com/en/sql-reference/functions/is_role_in_session) 18. [Open Data Contract Standard v3.2.0, Bitol](https://bitol-io.github.io/open-data-contract-standard/v3.2.0/home/) 19. [Data Contracts & Data Products for AI, Bitol (September 8, 2026)](https://bitol.io/data-contracts-data-products-for-ai/) 20. [OpenLineage documentation, OpenLineage](https://openlineage.io/docs/) 21. [AI-ready data, Atlan Documentation](https://docs.atlan.com/agents/concepts/ai-ready-data) 22. [Enrich Atlan through dbt, Atlan Documentation](https://docs.atlan.com/apps/connectors/etl-tools/dbt/how-tos/update-atlan-through-dbt) 23. [What does Atlan crawl from dbt Core, Atlan Documentation](https://docs.atlan.com/apps/connectors/etl-tools/dbt/references/what-does-atlan-crawl-from-dbt-core) 24. [Certify assets, Atlan Documentation](https://docs.atlan.com/product/capabilities/build-apps/sdks/python/how-tos/certify-assets) 25. [Manage asset owners, Atlan Documentation](https://docs.atlan.com/product/capabilities/build-apps/sdks/python/how-tos/change-owners) 26. [Link terms and assets, Atlan Documentation](https://docs.atlan.com/product/capabilities/build-apps/sdks/python/how-tos/link-terms) 27. [Tag propagation, Atlan Documentation](https://docs.atlan.com/product/integrations/automation/always-on/references/tag-propagation) 28. [Understand context agents, Atlan Documentation](https://docs.atlan.com/product/capabilities/governance/context-agents-studio/concepts/agents) 29. [Atlan MCP overview, Atlan Documentation](https://docs.atlan.com/product/capabilities/atlan-ai/how-tos/atlan-mcp-overview) 30. [What is Context Engineering Studio?, Atlan Documentation](https://docs.atlan.com/product/capabilities/governance/context-engineering-studio/concepts/what-is-context-engineering-studio) ## Next steps - [See how Atlan's context layer works in recorded demos](https://atlan.com/context-layer-demo/) - [Book a demo or talk to Atlan's sales team](https://atlan.com/forms/talk-to-sales-contact/)