Okta moves AI agent context into dbt so every agent shares one source of truth

Okta has moved the context its AI agents rely on out of the Snowflake UI and into dbt, where it is reviewed through pull requests and shared by different agents. Pooja Crahen, senior manager of analytics engineering at Okta, described the approach in a dbt Summit 2026 breakout session, according to dbt Labs.
- Okta moved AI agent context from Snowflake UI semantic views into dbt, shipped through normal pull requests.
- The framework has three layers: agent metadata in YAML, markdown context docs, and semantic views in dbt's semantic layer spec.
- Context syncs into Agents Schema, so Claude (via MCP) and Snowflake Cortex read the same rules.
- Okta opened a GitHub discussion on dbt Core about making agents a first-class node type.
- Next steps include automated regression tests and feeding corrections back into context docs.
From fast experiments to three cracks
Okta's early AI experiments ran on semantic views built directly in Snowflake's UI and wired straight to Snowflake Cortex agents. According to the dbt Labs write-up, this worked and worked fast. But those semantic views were completely disconnected from the governed dbt models that defined the business logic.
Crahen's team, about thirteen analytics engineers embedded across delivery, go-to-market, product, and finance, identified three problems:
- Context fragmentation between Snowflake and dbt.
- No auditability, since everything lived in UI click history.
- One undifferentiated blob: an agent's instructions were flattened together, with no distinction between what it should always know and what it should look up.
Downstream, these showed up as three failures. Nobody could discover what existed, because semantic views had no catalog outside Snowflake. Nobody could trust what they found, as there was no shared system of record confirming it was current. And every team re-derived its own definitions instead of building on shared ones.
"A couple years in, the realization came in where building the agent was never really the hard part," Crahen said. "What it could see and trust was the hard part."
A three-layer context framework built in dbt
The fix is a three-layer agent context framework built entirely inside dbt and shipped through normal pull requests.
- Metadata: model and column-level metadata gets a new "agent" sub-block in the YAML. It flags what a model is safe to use for, what to avoid it for, and any filters that should apply automatically.
- Context docs: markdown files capture company-wide facts, such as the fact that Okta's fiscal year starts February 1, along with domain-specific routing rules.
- Semantic views: these were migrated out of the Snowflake UI into dbt's own semantic layer spec, and become the governed, PR-reviewed source of facts, dimensions, and metrics.
To migrate, the team built a custom skill wired to a slash command. It pulls the DDL from an existing Snowflake semantic view and converts it into a dbt semantic view spec automatically.
Okta also opened a public GitHub discussion on dbt Core. It asks whether something like a Cortex agent should be a normal dbt model materialization or a first-class node type of its own, the way an exposure is.
One rule, many agents
All three layers sync automatically into Agents Schema, which dbt Labs describes as an open, warehouse-native metadata standard. Any agent with SQL access, whether Cortex or Claude, can read from the same source of truth.
In practice, Claude queries the metadata directly over MCP and reads context docs as markdown files. Cortex reads the same information through a search service and its own skill configuration. A rule written once in dbt is inherited by both, and a third agent added later would inherit it with zero duplication.
The team says this changes how wrong answers get fixed. Previously that meant editing an opaque agent config and redeploying through multiple cycles. Now an analytics engineer merges a change to the context layer in dbt, and every agent that reads from it improves immediately. "The result is the 100th question gets the same quality answer as the first," Crahen said. "It's not about the agent. It's more about the context as infrastructure."
What comes next
Okta plans automated regression tests that run verified queries against the agents whenever context changes. It also intends to extend context beyond a single domain. Longer term, the team wants to close the loop between an agent's answers and ground truth, so corrections can feed back into the context docs automatically. Crahen described this as a move from trust but verify to a measurable accuracy score.
For data teams running more than one AI agent, the Okta account points to a practical lesson: treating context as versioned, reviewable infrastructure in the transformation layer, rather than as per-agent configuration, is what keeps answers consistent as agents are added.
dbt Labs: What Okta learned governing context for AI agents at scale


