Atlan's Austin Kronz: "Context is the One Thing AI Can't Commoditize"

Every enterprise building AI agents runs into the same wall. The model reasons well, but it doesn't know how the business actually works, and no amount of raw intelligence fills that in. Austin Kronz, Director of AI and Data Strategy at Atlan, sat down with our co-founder and CEO, Gorkem Sevinc, to talk about what closing that gap takes.

Their conversation covered why context is the natural evolution of the data catalog in a machine world, the three parts of context and why two of them are rarely written down, why context drifts the same way data does, and what maturity looks like for a data leader who wants to stay in the room.

Here's what we learned from their conversation:

1. Context is the catalog's evolution for a machine that can't infer what nobody wrote down

Austin frames Atlan's shift toward context as a continuation rather than a pivot. The job a data catalog did for people is the job an agent now needs done, with one difference: the machine starts with none of the tacit knowledge a person brings in.

"Data catalogs were to people what context will be for AI. A lot of our customers still start their journey in the human world, where people need to discover data, trust data, use data. When we hand that over to AI, there's so many other things that are implied or tacit knowledge or things that haven't been explicitly documented or stored or in a way that a machine can read."

Closing that gap is where Atlan's context agents come in, documenting columns, writing descriptions, and filling readme files with the information about the data that a person would otherwise pick up on their own.

The same is true for a human analyst inheriting data they didn't build. An agent and an analyst ask the same questions of the same data, so the context has to make sense for each.

"For us, context kind of comes down into three buckets, and it'll make sense for AI, and it'll make sense for human."

Those three buckets are knowledge, what a term or metric actually means; expertise, the procedural judgment a team builds over time; and norms, the reason two teams can define the same metric differently and both be right. 

2. Two of the three parts of context aren't written down anywhere

Knowledge is the part that tends to get captured. The other two rarely do. Expertise is the reflex any SaaS operator recognizes: if the sales pipeline looks off in Q3, the seasoned move is to check whether Europe is on holiday before assuming something broke. Norms are why the same metric can be calculated two different ways on purpose, because two teams have different goals. Neither lives in a column name.

"If you want to know how a company thinks they operate, go read their documentation. If you want to know how they actually operate, you go to their systems."

That distinction, between how a company documents itself and how it actually runs, is the whole problem. The operating knowledge lives in the systems, not the docs, so Atlan tries to reverse-engineer what it can from existing transformations, dashboards, and query history, then put it somewhere a machine can read.

Austin points to metric conflict resolution as a concrete case. Ask an agent to build a CAC-to-LTV ratio and it may find four columns named CAC and four named LTV, surface its best guess at the right pair, and let you correct it, because in a particular analysis you might be reaching for a different column on purpose.

"There is a global metric of how we view it. But two teams might correctly interpret it slightly differently, because they have different use cases or goals in mind."

3. Context decays the same way data does, so it needs its own lifecycle

Context has a shelf life. The moment you build a skill for an agent, it reflects the business as it existed that day, and the business keeps moving.

"Context, much like data, can drift and get stale."

Without treating context as a managed lifecycle, teams land back where they started, waiting for someone to notice a skill has drifted. The failure mode Austin sees most is a team hardcoding a new acronym or definition into a config file, so the fix doesn't travel the next time someone builds a similar agent on a different platform. Managing the lifecycle means tracking when a skill was last updated, who built it, whether that person is trusted, and whether anything is watching the skill for a wrong result.

Drift is also where the context problem meets the data problem. Context can be fluid, because an agent's path to an answer is non-deterministic. The data underneath cannot.

"In data, there is a right answer. There is a right answer to how much revenue we have."

Usability, explainability, and auditability of data matter more now than ever, and combining governed context with real-time controls is what lets a team trust both what the data means and whether it can be acted on. That’s what a trusted ecosystem looks like end to end.

4. Intelligence got commoditized, so context is where companies differentiate

Every company building agents has access to the same models as its competitors, so intelligence itself no longer separates one company's agent from another's. What differentiates them is the specific way each business runs, which is what Austin means by context.

"Your secret sauce is your context. There's no semantic layer in the world that can give you an answer on bad data."

Context tells an agent how a business operates, but a semantic layer sitting on top of wrong data still returns a wrong answer. Getting the context right does not get you off the hook for the data.

Austin's take is that agent-building is what finally forces companies to get their data foundations in order, because you can't build a working agent on a bad foundation. And the leader who owns that foundation is in a different position than the one who doesn't.

"If you are a Chief Data Officer right now, you have to try to own this. You have a very important ingredient, and I think if you become a "just submit a ticket, we tell you how to get to the data" [type], you'll be left out of what is next."

Owning it means becoming a partner to every C-suite peer and an owner of platforms without being the implementer, with business users co-owning data quality rather than leaving it to one governance team.

That ownership has to hold up under sprawl. Different teams are already standing up their own agent platforms, from someone working locally to teams on Codex, Genie, or Snowflake Cortex, and context hardcoded into one of them doesn't travel when the business builds its next agent somewhere else.

Context is everybody's job 

The thread running through the conversation is that neither trusted context nor trusted data is one team's job. Intelligence is commoditized, so context becomes the differentiator, and the data beneath that context still has a right answer that someone has to keep usable, explainable, and auditable. The two requirements sit next to each other: definitions and knowledge on one side, quality signals exposed as controls on the other.

Gorkem's question from earlier in the conversation is worth sitting with: are you building the same trusted context for your AI agents that you would insist on for a human analyst, or are you still building for one and hoping the other catches up?

‍