What is Agents Schema? The spec behind Fivetran Context Layer

TL;DR. At dbt Summit 2026 on September 16, Fivetran + dbt Labs introduced Fivetran Context Layer and open-sourced the standard underneath it, Agents Schema: a reserved warehouse schema named AGENTS where metadata for AI agents lives as plain SQL tables. We read the spec rather than the press release. The binding contract turns out to be one three-column registry table plus conventions, loose on purpose because its intended reader is a model, not a parser. The part that deserves your attention is smaller and sharper: agent instructions, which the spec calls skills, are delivered as rows in that table. Whoever can write to AGENTS.ROOT is writing prompts for every agent that queries it.

The pitch behind Agents Schema is easy to state. Agents that query a warehouse need context that table schemas do not carry: what a model is for, how the business defines a metric, which of four tables named revenue is governed. Vendors have answered with catalogs, MCP servers, and memory products. Agents Schema answers with the warehouse itself: put the context in a standard schema named AGENTS, as ordinary tables, next to the data the agent is reasoning over. Anything that can run SELECT can read it, which is the point; the README names Cursor, Claude Code, notebooks, and internal agents as consumers, and ships a Claude Code and Codex plugin that discovers the schema on connection.

Fivetran Context Layer is the managed service on top, and the launch labels are worth recording precisely: Fivetran's product post says Limited Public Preview, while the same day's press release says Private Beta. Either way it shipped beside the general availability of dbt v2, the Rust engine we covered when its artifact layer became a contract, which is not a coincidence. The metadata dbt v2 emits is exactly what this schema ingests.

The contract is one table

Strip the marketing and the specification, SPEC.md in the repository, defines surprisingly little. Everything lives in a schema named AGENTS, uppercase canonical. The one required object is the registry:

CREATE TABLE AGENTS.ROOT (
  provider    VARCHAR NOT NULL,
  key         VARCHAR NOT NULL,
  content     TEXT NOT NULL,
  PRIMARY KEY (provider, key)
);

That is the whole hard contract: a provider name, a key unique within the provider, and free-form text. Around it, conventions. Each ingestion source writes its own table family beside the registry, AGENTS.DBT_MODEL, AGENTS.DBT_COLUMN, and AGENTS.DBT_DEPENDENCY from a dbt manifest.json, AGENTS.LOOKML_VIEW and friends from LookML, AGENTS.OSI_METRIC and its siblings from Open Semantic Interchange YAML, Sigma from its data model exports. A registry row per table tells a generic consumer what each one means. The spec is explicit about why the shape is loose: it "assumes its consumer is an AI agent, not a deterministic application that needs a fixed contract from providers," so content is free to be semi-structured markdown and free to change shape as models evolve. The README's own comparison is apt: closest in spirit to information_schema, but extensible across providers.

Two operational details tell you how young this is. Each ingestion run replaces its table family wholesale with CREATE OR REPLACE TABLE, so the schema carries current state and no history. And the current release tag is v0.0.11, with the spec document already carrying a migration guide for a BigQuery dataset rename between early versions. Calling this an open standard is aspiration; today it is a small, sensible convention published early, the same move Ossie made in the semantic layer, and what the Ossie spec standardizes first went through the same versions-before-a-version phase. Early is not a criticism. Early is when the defaults are still negotiable, which is exactly why the next section matters.

Instructions are rows now

The registry does not just describe tables. A row whose key starts with skill/ is a skill: markdown instructions an agent is meant to load and follow, published into the warehouse like any other metadata. The convention includes YAML frontmatter with a uses field declaring which schemas and tables the skill may touch, and the spec is candid that these declarations are additive and express no exclusions. The CLI publishes a built-in analyst skill on every run, matched to the destination warehouse. The spec's own example rows sketch the intended future: an acme_corp provider publishing a refund workflow skill and a note telling agents to check query costs before expensive joins.

This is the most consequential design decision in the project, and the announcements barely mention it. A skill row is not context an agent may consult; it is behavior an agent is expected to adopt. The delivery channel for that behavior is now a database table, written by a GitHub Actions workflow holding a WAREHOUSE_CREDENTIALS secret, readable and writable by whatever else holds write access to the schema. We made this argument about the MCP instructions field, where servers write into the system prompt and nobody logs it; Agents Schema moves the same class of surface into the warehouse. It inherits real advantages from that move: rows are queryable, diffable, and subject to warehouse permissions. It also inherits the blunt consequence. Write access to AGENTS.ROOT is authorship of what your agents are told, and a CREATE OR REPLACE pipeline means yesterday's instructions are gone unless something outside the warehouse kept them.

What the managed service adds

Fivetran Context Layer wraps the open schema in the parts that are genuinely hard to run: metadata connectors for the dbt Semantic Layer, Looker, Sigma, and Power BI; parsing and indexing of unstructured sources such as Confluence, Google Drive, Jira, and Zendesk; a discovery step that drafts an ontology from metadata you already have; an Agent Context MCP interface in front of the tables; and traces, agent sessions written back to the warehouse with the answer, the SQL or document behind it, and the assumptions made along the way. The press release adds that the context is reachable through integrations in AI marketplaces including Anthropic's and a ChatGPT plugin. Fivetran says its internal evaluations show agents on Context Layer making fewer tool calls and using fewer input tokens than generic MCP setups; treat that as a vendor claim until someone reproduces it, but the direction is plausible, and it matches the argument we made building a context layer on plain Postgres: retrieval from resolved context beats rediscovery every time.

The preview gate names Snowflake, BigQuery, and Fivetran's Managed Data Lake Service as the homes it expects, and the open-source workflows write to Snowflake, Databricks, and BigQuery. Notice what that list is: analytical estates. The catalog vendors arrived at this same territory from the metadata side when OpenMetadata rebranded the catalog as a context layer; Fivetran + dbt arrive from the pipeline side with the strongest distribution in the market. The land rush is real, and the warehouse is where every incumbent is planting its flag.

Governance you already enforce, and its ceiling

The governance story is one sentence in the announcement: context lives in your warehouse under the access controls you already enforce. As far as it goes, that sentence is correct and attractive. No new store, no second permission system, context rows covered by the same grants as the data they describe.

Its ceiling is that warehouse access controls answer one question: who is asking. A role that can read AGENTS.ROOT reads every skill and every description its grants cover, whatever the task at hand. Nothing in the schema scopes context to what an agent is currently doing, distinguishes reading a metric definition from adopting a workflow instruction, or records which rows an agent actually consumed on the way to an answer. The traces feature writes down what the agent did; the grants decide only who may look. That gap between caller-scoped access and task-scoped need is where most of the interesting agent governance work now sits, and inheriting the warehouse's ACLs, the genuine convenience here, does not close it.

The second boundary is scope. This whole design assumes the data an agent reasons over lives in an analytical warehouse fed by batch metadata syncs. The operational estate, the production Postgres serving your application, is not in the destination list, and the context that matters there decays in hours, not sync cycles.

Where Datapace fits

That operational side is where Datapace sits: a context layer for production databases, where resolved meaning is validated by the people who own the data, workload evidence sits beside it, and execution is governed per task rather than per credential, served to agents over MCP. Agents Schema putting context into SQL tables is a pattern we like; the databases that need it most are the ones no warehouse sync covers. If your agents touch production Postgres and their permissions still answer only who is asking, book a call.

The spec itself is worth thirty minutes of your time, precisely because it is small. One table, a handful of conventions, instructions as rows. What becomes of it depends on whether the defaults harden before the surface gets abused, and on how many vendors decide that the schema every agent reads is a place they want to write.

Sources

1. Fivetran, Announcing Fivetran Context Layer, September 16, 2026 (Limited Public Preview, feature list, warehouse ACL governance framing, internal token and tool-call evaluations, preview gate naming Snowflake, BigQuery, and Managed Data Lake Service).
2. Fivetran + dbt Labs, dbt Summit 2026 press release, September 16, 2026 (dbt v2 and dbt State general availability, Context Layer as Private Beta, Agents Schema as open source standard, marketplace integrations, Lake Compute).
3. dbt Labs, agents_schema repository README (AGENTS schema, sources and destinations, GitHub Actions workflows and WAREHOUSE_CREDENTIALS, information_schema comparison, Claude Code and Codex plugins, release tag v0.0.11).
4. dbt Labs, agents_schema SPEC.md (AGENTS.ROOT contract, provider table families, skill rows and additive uses frontmatter, built-in analyst skill, CREATE OR REPLACE ingestion, BigQuery dataset migration).