Snowflake Summit 2026: Everyone Owns Context Now

Source: Austin Kronz, Vivek Dubey, Atlan · 2026-06-11

Everyone owns context now.

Every platform at last week’s Snowflake Summit in San Francisco announced a version of it. The keynotes named it. The booths demonstrated it. The standards bodies wrote specifications for it. By the end of four days, the practitioners on the floor were more confused than when they arrived.

Something significant happened at this summit. For the first time, context infrastructure was the main story, not a footnote.

Sridhar Ramaswamy, Snowflake’s CEO, used his opening keynote to say it plainly: a model is not a unique advantage, because your competitor has the same model. The moat is your data. The company with the best governed, contextualized, machine-readable data wins the AI era, not the one with the best model subscription. In Snowflake’s framing, data is the most defensible moat a company has, and if it is fragmented, competitive advantage is buried with it.

Christian Kleinerman, Snowflake’s EVP of Product, made the same point from the product side: models keep changing and capabilities keep advancing, but the data is constant.

Two years ago, the mainstream position was that frontier models would solve the data quality problem downstream. The industry’s largest data platform is now saying the opposite. Governance, context, and meaning are the irreducible requirements. The category has arrived.

Context is on every stage, in every booth, in every product roadmap. Which is exactly what makes the floor conversation so interesting.

Every vendor at this summit defined context with respect to what their software produces.

When every tool claims context, the word stops meaning anything precise.

And the imprecision is not a new mistake, it is the latest version of an old one. Data and analytics has spent 20+ years treating the artifact as the goal, the dashboard, the model, now the semantic view, when the goal was always to answer the business question. That confusion is what triggered the whole data product movement. It is showing up again as “my job is to build the agent” instead of “my job is to solve the business problem.” The agent is the newest artifact to mistake for the outcome.

Then Ramaswamy named the actual problem in the same keynote: too many enterprises still struggle to exploit their data because it sits in fragmented silos, each with its own version of the truth.

Their own versions of the truth. No semantic model resolves that. No metadata connector decides which version is authoritative. Two teams disagree on what “revenue” means, both are correct within their own context, and nothing announced during the summit holds the layer where that conflict gets reconciled and kept reconciled. This is not a gap in the warehouse. It is a missing layer above it, and that layer has to be engineered, not just willed into existence with more meetings.

Sanjeev Mohan, an independent analyst, said it plainly in a floor interview: the moat has moved to the context layer, because that is where you can apply security. Then he added the line that did not make the summaries: the entire attempt to build a single corporate data warehouse is fraught, and it is not for everybody.

The demos landed. When practitioners watched an undocumented environment go from zero to AI-ready, lineage mapped, definitions bootstrapped, an agent returning a trusted query result, the reaction was consistent: this is real, I can see how it works. The demos are real, and the automation behind them is accelerating. It is worth being precise about what was shown, though. Bootstrapping context from a cold, undocumented estate is a strong assist today, not a finished capability. The direction is not in doubt. The maturity is still arriving.

The questions that followed were not about the technology. They were about what happens after the demo. Who maintains the definitions when the team that built them turns over? When a new data source lands, who governs its meaning before an agent starts querying it? When two business units define the same metric differently, and an agent has to answer a question that spans both, who decides which definition it uses, and what happens when the answer is wrong?

Those questions do not have answers in a product catalog. They have answers in organizational structure, accountability, and process. And the practitioners asking them were not confused about the technology. They were clear-eyed about the distance between what the technology provides and what their organizations need to run on top of it.

Four questions came up repeatedly in floor conversations during the summit. None had a product announcement attached.

The first was memory. There was a memory feature announced, but it was the kind that lives with an individual agent session: per-user recall, preferences, query history. Useful, and not what practitioners were asking about. They were asking about organizational memory. How does an agent know that your definition of “churn” changed after a product pivot? How does it know that “customer” means something different in your North American operations than in EMEA, because an acquisition was never fully integrated? That is durable, shared knowledge that has to outlive any one session and any one person. The feature in the booth remembered the user. The floor was asking how the organization remembers itself.

The second was portability. Why can’t an agent just read the YAML file that defines the semantic layer? The question sounds technical. The reason it isn’t: a YAML file is a snapshot. It does not know who is responsible for updating it. It does not know when it stopped being accurate. It does not have an owner. You can federate a schema. You cannot federate accountability.

The third was ownership. When two teams disagree on the definition of “revenue,” and they will, who decides, and where does that decision live so an agent can act on it? The technical layer can surface the discrepancy. Resolving it, and keeping it resolved, takes a layer built to hold that decision, version it, and serve it to every agent that asks. That layer is buildable.

The fourth was gravity, where the agent actually gets built. This one surfaced less as a question than as a behavior the field had already settled into. Snowflake brought agentic development closer to the warehouse with Snowflake Cowork, and that is the rational move for any platform: pull agent-building toward your center of gravity, and in this case that is data. But the business’s center of gravity is the business process, and the problems it needs to solve. So the teams closest to those problems reach for what is in their orbit, general-purpose coding agents, or specialized agentic platforms built for a particular workflow. Some attendees said they are comfortable with consumer AI tools in their personal life, but their company has not licensed those harnesses for work. They will have the warehouse’s agent environment, so that is where they will start. No enterprise will standardize on a single one of these, and that is fine. The point is not which one wins. Agent development will start in many different platforms across many teams. The context an agent depends on cannot stay locked inside whichever platform a team starts in. It has to be portable across them. Each platform has its own gravity, and agents will form around all of them. Context cannot live in any single orbit. It is the center of mass they all share.

The pattern underneath all four is the same. Each one is a piece of context that the warehouse-layer announcements do not hold: the meaning, the ownership, the freshness, the portability. None of that is unmanageable human overhead. It is a layer that can be engineered, with the same rigor the industry just spent four days celebrating one layer down. The reason it feels unsolved is not that it is about people. It is that no platform builds it as a standalone layer, because each platform’s gravity pulls context back into its own product. Bob O’Donnell, a veteran industry analyst on the floor, said what practitioners have been saying quietly for years: this sounds great in theory, but the nuts and bolts of actually doing it are very hard. He has been saying some version of that for a decade. He is still saying it. The nuts and bolts are exactly the point. They are buildable. They are just not built from inside a warehouse.

But the infrastructure is not the whole of context. Tooling makes a definition machine-readable, which is real work the layer does well. On its own, though, it does not keep that definition current as the business changes, reconcile it when two teams disagree, or stop every new team and every new agent from quietly minting its own version of the truth. That is not a limit of the technology. It is what a context layer is for: it carries the definitions, versions them as they change, reconciles the conflicts, and serves a single trusted answer to every agent that asks. People set the policy and stay accountable for it.