Context at Rest, Context in Motion

On 7 August 2026, Gartner's Emerging Tech Impact Radar: Generative AI added a category called AI context platforms, defined as software that lets data and AI engineering teams "construct, govern, and deliver semantically organized knowledge" to AI agents and applications. Ten sample vendors, from Atlan and Glean to Databricks, Snowflake, Palantir, Microsoft and Google. One to three years to early-majority adoption, mass rated high.

That followed a Data & Analytics Summit in March where the framing was that context layers are the new critical infrastructure, and it was followed by a run of product launches: Microsoft's Fabric IQ, Snowflake's Cortex Sense, Airbyte's Context Store, all inside about eight weeks. Somewhere in there the phrase settled into its final form. Context as infrastructure. It's in CDO budget decks now as a line item.

I agree with most of it, which is why it's worth being precise about the part I don't.

The part that's just right

The category gets the layer right. For two years the industry argued about prompts and models while the actual determinant of whether an agent works was what you put in front of it, and nobody owned that. Treating context as a thing with storage, governance, provenance and freshness requirements, rather than as a string you assemble in application code, is simply correct. IBM's version of the argument puts it well: what's needed is "a unified, governed runtime context layer that agents can call into directly," and "this is infrastructure, not application logic." Policy checked at runtime, federated across sources instead of copied into one AI store, lineage that survives a multi-step run.

The dev-side version of the same argument is the one I find most honest, because it's specific about what context is made of: documents and policies, procedures and runbooks, the reasoning behind past decisions, shared memory between sessions, team preferences. And it names the failure mode exactly right. Stale context is worse than no context, because it's confidently wrong.

We've been making this argument from the other end since Context-Oriented Software Development, which says the stronger version of it: context isn't just the input to execution, it's the unit of execution. And the infrastructure tier the category describes genuinely exists in our world. We call it the organization brain — everything the company produces, ingested, entity-extracted, embedded, tagged, kept current, available to every process instead of rebuilt per agent. If that's what context as infrastructure means, we're not arguing. We're already building it, and we've said publicly that the semantic layer is the right idea.

So this isn't a rebuttal. It's a note about a missing verb.

Construct, govern, deliver

Read the definition again and count what it commits to. Construct. Govern. Deliver. Three verbs, all of which happen to knowledge, none of which happens to a decision.

This isn't me reading uncharitably, either. Gartner files coordination somewhere else entirely, in a separate category for agentic operating systems. The boundary is drawn on purpose: a context platform makes knowledge available, and what happens next is someone else's problem.

What's left outside that boundary is most of the work. Something has to decide which slice of the brain belongs in front of this decision, at the moment the decision is made. Something has to hold state while the process waits two days for a human to approve a refund. Something has to survive a crash at step nine of fourteen without losing its place, re-read what changed, and carry on. Something has to decide where to go next, and leave a record of why it went there. A governed knowledge layer answers none of those, and it isn't supposed to.

You can build a magnificent warehouse and still own nothing that drives.

At rest and in motion

Here's the cleanest way I've found to say the difference.

Infrastructure is a noun you provision. Its context exists before the question does — modelled ahead of time, ambient, sitting there whether or not anyone asks. That's what makes it reusable across every team in the company, and that reuse is real.

A process is the verb that assembles it. Its context comes into being when a decision needs it, out of live sources, scoped to the frame, and then it's carried forward by the thing that's executing. In FloMorphic the mechanism is a query-node: a node that is a read, pulling the relevant slice into a durable context object that the process iterates over. The decision about which sources matter is drawn on a canvas before anything runs, rather than improvised by a model at runtime.

The cost of doing it the other way shows up in the parts of context that go stale fastest. Properties age slowly. A customer's name, a server's hostname, a policy's text, those are fine in a nightly snapshot. Dependencies age fast. Which service is on that host, which database it talks to, who's on call, what falls over with it, that graph is already wrong by lunchtime, and it's exactly the part a decision rests on. Blast radius has to be assembled at the moment you ask, or you're answering a question about yesterday.

I'll concede the trade, because it is a trade. Modelling context up front buys enterprise-wide reuse by construction, and assembling per frame doesn't. We get reuse by composition instead: shared query-nodes, a plugin, a common slice of the brain. That's more work than inheriting one global graph, and in exchange the thing the agent reads is current.

Both claims are universal, in opposite ways

The thing that pushed me to write this was a smaller observation that I think is actually the load-bearing one. Both framings claim to work for any domain. They get there by opposite mechanisms, and the mechanism decides what survives.

Infrastructure is universal by genericity. A context store that has to serve billing disputes, incident response and KYC review can only serve all three by flattening them into shapes that are common to all three: documents, chunks, embeddings, entities, permissions, freshness timestamps. That's a real engineering achievement, and it's also a lossy one. A chargeback and a sev-1 and an onboarding check have nothing in common at the level of what they are. By the time they're in the store they're all just retrievable material, and the domain-specific part — the sequence, the thresholds, the who-signs-off, the what-if-this-fails — has to live somewhere else. Usually it lives in whoever wrote the query, which is to say in code, or in a prompt, or in a person's head.

A process is universal by composition. It doesn't generalise across domains by stripping them down to a common substrate; it generalises because it's a grammar. A KYC review and an incident triage are different graphs built from the same few parts: nodes that read, nodes that judge, edges with conditions, loops that run until something is true, waits that hold for a human. The domain isn't flattened out of it. It's the shape of the graph, and it stays legible as that shape, on a canvas, to the person who owns the domain.

Which matters because the domain-specific part is the deciding part. "What is true about this customer" is shared infrastructure. "What we do about it, in what order, with whose approval, and what happens when the third step fails" is the actual business, and there is no generic form of it that's still useful. A platform that can only be universal by flattening will always hand that back to you as application logic, and then you've got your context governed and your decisions ungoverned, which is a strange place to end up after two years of arguing about governance.

Our infrastructure tier is a process too

The part I'd push hardest: in our stack the infrastructure tier isn't a different kind of thing from the process that uses it.

The organization brain gets built by a flow. Ingest, clean, extract, embed, tag, keep current, running on a schedule and on every new event, waiting on external systems, surviving restarts, running as long as the company runs. Those are the same two properties that make a runtime an agent runtime rather than an automation tool: a real loop and durable long-running execution. The same primitive that pauses and resumes a three-day approval is the primitive that maintains the knowledge layer. One material, drawn twice.

So the stack reads: a durable process builds the substrate, query-nodes pull from it into a scoped context, a bounded model judges one step inside that context, traces go back into the substrate. No seam between the infrastructure and the thing running on it, because there's only one kind of object.

Where I'd be careful

A few honest notes.

We are not an AI context platform and I don't want to be scored as one. If what you need is column-level lineage across fourteen Oracle databases, a glossary with stewardship workflows, enterprise search over a decade of Confluence, go buy one of the ten vendors on that list. That's metadata management, they're good at it, and we aren't building it.

What I'm not disclaiming is governance, and I want to be exact about that, because we've said in public that SurfStat is an authoring substrate for governed data and that everything an organization wants from its data needs that data governed first. We mean it. A plugin reaches a source where the data already lives, so nothing is migrated in order to be governed. Each node gives access to one resource, wherever in the organization that resource happens to sit — a branch's SQL Server, a vendor's API, a queue, a database nobody has documented since 2011, a slice of the brain — under the credential declared on that node. And because a flow is composed of nodes, composing the flow is composing the access: what a process may reach is exactly the sum of the nodes somebody drew, each one scoped at the point where the read actually happens rather than configured somewhere else and hoped for. An action happens on an edge somebody drew, or it doesn't happen. The execution record of the run is the evidence that it went that way. That's governance of data in motion: who reads what, at which step, under whose approval, with a trace that survives the run. A catalog governs the description of data. A flow governs its use. Different jobs, and an organization needs both.

Which also means the complementary reading isn't "they own context, we own process." We build the at-rest tier as well — the organization brain is exactly that — except it's authored as a flow instead of bought as a product. What we don't build is the catalog around it.

And be sceptical of the numbers the category is travelling with. The share-of-teams-investing figures, the percentage of projects predicted to fail, the market sizes — nearly all of them come from vendors selling into the space, sometimes citing each other. The category is real and the budget line is real. The statistics decorating them aren't worth repeating.

One more thing I noticed while reading around: at least one vendor is already using "context as infrastructure" to describe a persistent execution layer with workflow state, multi-day pause and resume, and policy gates in front of every tool call. That's the same bet we're making, named differently. The page doesn't show enough architecture for me to tell whether it's built, so I'll leave it at that and watch.

The useful question isn't whether context belongs in infrastructure. It does, and the industry has now spent the money to agree. It's what you expect to happen after the context arrives. Construct, govern and deliver get you a substrate that's accurate and auditable and sitting still. Everything a business actually recognises as work — the waiting, the escalating, the retrying, the deciding, the three weeks where a case stays open — is a process, and it either lives somewhere you can see it or it lives scattered across prompts and glue code that nobody governs.

Sources: Gartner, "Emerging Tech Impact Radar: Generative AI," 7 August 2026, as reported by Atlan — atlan.com; Gartner Data & Analytics Summit 2026 coverage via TopQuadrant and Atlan; IBM, "Context Engineering: The Foundation for Trusted Agentic AI" — ibm.com; Brian Zimbelman, "Context as Infrastructure: Agents Need More Than Code" — dev.to. The Gartner definition and vendor list are quoted from Atlan's reporting, not from the primary document.