What Okta learned governing context for AI agents at scale

In a dbt Summit 2026 breakout session, Pooja Crahen, senior manager of analytics engineering at Okta, framed her talk around a pattern she noticed across her career: building dashboards, then learning content, then AI agents were essentially the same job wearing different interfaces, and the underlying question never changed: whether the person, or now the agent, on the other end could actually trust what they were looking at. At Comcast, she built dashboards, and the question was always whether the numbers were even right. At Pluralsight, she built learning content, and the question became whether anyone actually learned something instead of just watching a video.

At Okta, the interface disappeared entirely: no chart, no course, just a machine generating an answer, but the same trust question remained underneath, whether the agent actually knew what it was talking about or just sounded confident.

Crahen's team, about thirteen analytics engineers embedded across delivery, go-to-market, product, and finance, sits inside a broader technology, data, and intelligence org that runs on Tableau for reporting and Snowflake as the central warehouse.

"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."

Okta's early AI experiments ran on semantic views built directly inside Snowflake's UI, wired straight to Snowflake Cortex agents. It worked, and it worked fast, but those semantic views were completely disconnected from the governed dbt models that actually defined the business logic.

Crahen's team found three cracks in that foundation: context fragmentation between Snowflake and dbt, no auditability since everything lived in UI click history, and all of an agent's instructions flattened into one undifferentiated blob with no distinction between what an agent should always know and what it should look up.

Those three cracks, fragmentation, no auditability, one undifferentiated blob, showed up downstream as three concrete failures: nobody could discover what existed, because semantic views had no catalog exposing them outside Snowflake; nobody could trust what they found, with no shared system of record confirming it was current; and every team ended up re-deriving its own definitions from scratch instead of building on anything shared.

The fix was a three-layer agent context framework, built entirely inside dbt and shipped through normal pull requests. Model and column-level metadata gets a new "agent" sub-block in the YAML, flagging what a model is safe to use for, what to avoid it for, and any filters that need to apply automatically. Context docs, in markdown, capture company-wide facts (Okta's fiscal year starts February 1) and domain-specific routing rules.

And semantic views, migrated out of the Snowflake UI into dbt's own semantic layer spec, become the governed, PR-reviewed source of facts, dimensions, and metrics. Getting semantic views into dbt took a custom skill wired to a slash command that pulls the DDL off 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 asking whether something like a Cortex agent should just be a normal dbt model materialization, or deserves to be a first-class node type of its own, the way an exposure is, and invited the room to weigh in.

All three sync automatically into Agents Schema, an open, warehouse-native metadata standard, so any agent with SQL access, whether it's Cortex or Claude, reads from the same source of truth. In practice that means Claude and Snowflake Cortex, two completely different products, read the exact same underlying context through different doors: Claude queries the metadata directly over MCP and reads context docs as markdown files, while Cortex reads the same information through a search service and its own skill configuration. Write the rule once, in dbt, and both consumers inherit it; add a third agent tomorrow, and it inherits the same rules with zero duplication.

The payoff, in Crahen's telling, is that fixing a wrong answer no longer means editing an opaque agent config and redeploying through multiple cycles. An analytics engineer merges a change to the context layer in dbt, and every agent that reads from it gets smarter immediately. "The result is the 100th question gets the same quality answer as the first," she said.

"It's not about the agent. It's more about the context as infrastructure."

Next up for the team: automated regression tests that run verified queries against the agents every time context changes, extending context beyond a single domain, and eventually closing the loop between an agent's answers and ground truth so corrections can feed back into the context docs automatically, moving, as Crahen put it, from trust but verify to a measurable accuracy score.

Watch every keynote and breakout from dbt Summit 2026 on demand. Watch dbt Summit 2026 on demand →