About the author: Dan McCreary has spent three decades, since Neal Stephenson’s The Diamond Age set him off in 1995, on one question: how knowledge moves through complex systems. He now builds open agent skills that generate intelligent textbooks, interactive and MicroSim-rich, whose learning graphs and xAPI event streams predict what a student has actually mastered.

*Note: Views expressed are those of the contributor. All submissions are vetted for quality and relevance. Context and Chaos is information-first: no promotions, paid or otherwise.

Let’s dive in!

Three pieces in this newsletter got here before me. Jessica Talisman argued that our industry confused measurement with meaning. Prukalpa separated the context substrate into AI-ready data, semantics and ontology, and skills, and insisted context be built, tested, reviewed and versioned like software. Juha Korpela made the case that conceptual modeling, the discipline data teams abandoned during the Big Data era, is the one AI agents now need most.

I agree with all three. I want to add the least glamorous part of the story: the math.

The 200-millisecond problem

An employee asks a question. The answer is present somewhere within your organization. Spread across systems that were never designed to be read together. Your model will accept roughly 20,000 tokens of it. Your retrieval path has about 200-milliseconds to decide which twenty thousand.

This is a selection problem under two budgets at once, latency and cost. Bigger context windows, more embeddings, a cleverer system prompt: each answers a question sitting next to the real one. The real one is which twenty thousand tokens, in what order, and how fast.

Get the selection wrong and the model hallucinates confidently. Get it right and take four seconds, and nobody uses your product. Get it right, quickly, and expensively, and your CFO learns your name.

Biology settled this a long time ago. Your spinal cord does not consult all available sensory data before pulling your hand off a hot stove. The path is already there, laid down long before the moment it is needed. That is where the speed comes from: wiring built in advance.

Which brings us to graphs, and specifically to the graph as wiring inside a context layer rather than as the context layer itself.

Why a graph and not a really good search box

Vector search answers “what looks like this?” That is a useful question, and it is not the question your business runs on. Your business runs on “what is connected to this, and how, and who approved it, and what happened the last three times?” The first question returns things that resemble your query. The second returns things your query depends on, which is a different set and usually a much smaller one.

Structure is what lets you allocate the token budget deliberately. Run personalised PageRank, seeded on the entities in the question, and it ranks which of forty related records bear on this query rather than on the graph as a whole. Centrality tells you which definitions everything else depends on. You stop retrieving the top fifty similar chunks and hoping the useful one is not in the middle, and start retrieving a bounded subgraph: this decision, its precedents, its approvers, their immediate neighborhood. A bounded retrieval is a bounded token count, which is the whole game once cost and latency are the constraint.

That boundary is also the honest answer to context poisoning. When a model contradicts itself across two runs of the same question, the usual suspect is the embedding model. More often the retrieval had no principled edge, so a different set came back each time. Structure gives you a stopping rule.

One caveat about which graph, because Andrew Lentz drew this line here last week. His argument is that where you author context and what the agent queries at runtime are separate decisions, and that for bounded questions the agent needs definitions, join keys, grain and the governing rule rather than a graph to walk. I agree. Everything below is the authoring side: the structure you build upstream, and the artifact you distil out of it. The agent never touches it.

The atomic unit is the decision trace

On that authoring side, the first question is what you model. Here is what I want to add to what Jessica, Prukalpa and Juha have already laid out on this matter. The unit worth modeling is the decision trace.

Not the document. Not the table. Not the metric definition. The trace: what happened, why, who approved it, which precedent justified it, and what was true at the time.

Your CRM knows the discount was 22 percent. It does not know that the VP approved it because the customer’s plant flooded, that three similar exceptions were granted in 2024, or that the approval happened in a hallway and was entered a week later by someone else. Your model needs the second thing to be useful.

Every real trace has four layers, and most systems capture none of them.

• Exception logic. The rule, and the conditions under which it was set aside. A policy document gives you the first half. Only the record of what was actually done gives you the second, and the second is what predicts next time.

• Historical precedent. The prior decisions that made this one defensible. Precedent turns a judgment call into a pattern, and it stays invisible unless decisions link to each other rather than filing separately.

• Cross-system synthesis. Most decisions draw on three or four systems with no shared key and no shared vocabulary. That synthesis happened in someone’s head, and the trace is the only place it was ever recorded.

• Out-of-band approval. The conversation that authorized the exception and never touched a system of record. This is where enterprises live, and it decides whether your agent understands the company or merely reads it.

This is also the structural reason the incumbent systems struggle. Warehouses sit on the read path after the fact. Agent platforms sit on the execution path without persistence. CRM and ERP are optimized for the transaction, not the trace. Each captures the what, and none captures the why. Prukalpa made the market version of this argument in January: in a heterogeneous enterprise the integrator wins over the vertical application. The architectural version is that the why has no owner yet, so whoever starts capturing it accumulates an asset nobody can buy later.

Why the structure does the work

Traces are worth capturing on their own merits. What makes them cheap to retrieve is how you shape them, and the compression that follows is a consequence of that shape rather than a general property of graphs. Three modeling choices decide it.

1. Make the dependency graph acyclic. If every edge points from a concept to something it depends on, and no cycle exists, the retrieval question has a clean answer. Take the concepts a target depends on, directly and transitively. That set is the minimal context. A topological sort returns it in an order where nothing appears before what it rests on. Retrieval research has explored dependency DAGs and topological ordering as a way to cut tokens; what is underused is pointing it at enterprise context, where the dependency structure is what a decision trace encodes anyway. Andrew reached the same property from the cost side last week: a deep narrow acyclic graph is cheap to walk as far as you like, and a shallow dense cyclic one is ruinous by depth three. Cycles are the expensive thing, not depth.

2. Type your edges and mean it. PREREQUISITE_OF, DEPENDS_ON and PART_OF each support a different traversal. A generic RELATED_TO cannot be traversed selectively, which quietly undoes everything above it.

3. Choose the right grain. In practice a domain resolves to somewhere between one hundred and six hundred core concepts, one classification each. Finer than that and the graph becomes noise. Coarser and the minimal context stops being minimal.

Get those three right and the retrieval question changes shape. You stop asking what is similar to this query and start asking what this concept depends on. The second question has a computable answer, and the answer is small.

What the numbers say

If context is a constrained resource, retrieval quality alone is the wrong objective. The objective is useful reasoning per token. We benchmark retrieval on recall and F1 and treat token cost as an afterthought, which is roughly like benchmarking cars on top speed and treating fuel as an afterthought. So the metric I have wanted for years is the Reasoning Density Score: F1 divided by tokens. Answer quality per token. Miles per gallon for context.

One result, from a benchmark I co-authored with Daniel Yarmoluk and which is still in preprint, so hold it loosely. A clinical trial corpus of 2.68 million tokens encoded as a compact knowledge graph of 2,614 tokens, roughly a thousandfold compression. To be precise about what that is: the graph does not hold the corpus. It holds the concepts, their dependencies and their classifications, which is what the questions in that domain actually turn on. Prose is discarded. At that size no current model holds the original corpus anyway, so the structure is what makes the question answerable at all.

The unglamorous plumbing

None of this requires new infrastructure, which is the encouraging part. A context graph is assembly work, the payoff for twenty years of data management that most organizations did halfway.

Semantic layers give you shared meaning over the lakehouse. Metadata management tells you what is trustworthy.

Metadata registries and ISO 11179 give you something more valuable than either: precise, non-circular definitions. A definition that does not refer to itself, does not smuggle in three undefined terms, and states its permissible values is the highest-compression token in the building. Most glossaries fail that test on the first entry.

Process mining, lineage and provenance reconstruct decision traces from event logs you already keep. Every workflow system, ticketing system and approval chain in your company emits the raw material. Almost nobody assembles it.

Bitemporal modeling separates when something was true from when you recorded it, which is how you answer “what did we believe on March 3rd.” That is the only question an auditor asks, and it is the question a model needs in order to reason about a decision made two quarters ago.

None of this is new, and that is the point. The wiring is mostly infrastructure you already paid for and never connected.

One caution, because it is the failure mode this newsletter has already documented. Prukalpa argued in February that semantic layers failed because they were abstractions built over ungoverned data. Graph structure imposed on ungoverned content reproduces that failure with better response times. The plumbing above is not preparation for the graph. It is the graph’s substance.

What it costs, and where this is not the answer

Assembly is still work. That compact graph cost about a tenth of a cent per query to consult, and considerably more than that to build: concept extraction, dependency modeling, expert review, and the ongoing cost of keeping it current. See our Benchmarking Token Costs Paper. Below the break-even you are paying for a structure you have not yet used, which is worth computing before you propose this to anyone.

Three cases where the structure does not pay.

Single-hop factual lookup. If the question is “what is the current list price,” dependency structure buys you nothing. Retrieval is fine, and cheaper.

Corpora without real dependency structure. Support tickets, customer conversations and news do not form a prerequisite lattice. Forcing one produces edges that mean nothing, and a graph whose edges mean nothing is a slower search index.

Content that churns faster than you can rebuild. If your concept set turns over monthly, the build cost never amortizes.

And one distinction, because it is where most graph projects go wrong. At a few thousand tokens the compact graph is a build artifact rather than a system: small, versioned, rebuilt on a schedule, and read by the retrieval path. It is not a second database, and nothing queries it at execution time.

The wiring

Everyone rents the same models. But it is very difficult to rent the record of why your company decided what it decided, and most organizations discard that record daily without noticing.

So start there, and start narrow. Take one decision your agents keep getting wrong, a pricing exception or an eligibility call or an approval, and write out what a complete trace of it would hold: the rule, the exception, the precedent, the person. Then check which of those four your systems actually store. It is usually one.

That gap is the work, and the asset. It compounds, and nobody can buy it.

Everyone else will keep asking larger models to guess, and will call the result an AI strategy right up until the budget review.

This article was originally published on Context & Chaos platform!

About the author:

Find me on LinkedIn!

Books from Dan

Dan McCreary writes free, open-source textbooks on building with LLMs, including Context Graph, and Token Efficiency. Both informed this piece. Please contact the author for a full biography of related interactive intelligent textbooks.

The Cats of Context & Chaos

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

The conviction had nothing to do with their workload. It came from the diagrams. Nobody had counted the questions the agent would actually be asked, or described out loud the path it would take across the graph to answer even one of them. The graph was a box on a slide with an arrow running into it.

Their actual questions were things like: can this rep sell this product in this state? What is the status of this policy? Bounded questions, with a join path anyone on the data team could have drawn on a napkin. They were already running a governed metadata layer that held most of what those questions needed.

They did not need a graph database. More precisely, and this is the part that took longer to land, they did not need their agent going anywhere near a graph. They needed it to know what their columns meant. The gap between those two sentences is where a lot of the 2026 architecture budget is about to go, so it is worth being precise about which side of it you are on.

Store it in a graph if you like. Just don’t wire it to the agent.

Storing your context in a graph is fine. It can be the right call when that context serves a lot of agents rather than one, because a graph is a good place to model and govern how things relate. That is a storage decision, and I have no quarrel with it.

I would go further, because the case for a graph here is better than “fine.” An ontology is the one part of this that is genuinely graph-shaped. Its content is the relationships, what subsumes what and which properties apply where, so a graph is faithful to its shape and not just a place to keep it. It is also small and slow-changing. People govern it, not pipelines. None of that is true of the instance data underneath. Model it there and govern it there. Then distil from it and let the agent read the distillation.

That is an argument about where you author, not about what the agent queries, and the two get run together constantly. It is the same slip behind “our data has relationships, so we need a graph.” Every schema has relationships. A foreign key is an edge, and a JOIN is a one-hop traversal. (Jessica Talisman untangled the vocabulary here in January; I am taking her definitions as read.) What you almost certainly do not need is that graph connected to the agent at query time. To be precise about what I am objecting to: a service that walks a graph and hands the agent a result is fine, and often the right build. What I am against is the model doing the walking, deciding hop by hop where to go next and then still having to write the query. The data lives in relational systems in the large majority of cases and will still live there after you have built the graph. The agent’s job is to structure a query against it correctly. A graph does not tell it how to do that. Curated context does.

There is a cost to getting this wrong that never shows up on the architecture diagram. If the agent has to reason its way across a graph and then reason its way to the SQL, you are running two rounds of inference to produce one answer: more tokens, more latency, and one more place where two runs of the same question come back different. Strip either problem down to what the agent genuinely has to decide, and it is almost always just how to shape the query. Anything I hand it as context instead of making it derive is variance removed before it happens, and that context is unglamorous: query patterns that are known to work, a note on how a table is meant to be used, the rule that governs a field. The agent reads it once and writes the query.

Paths or lookups. That is the whole sort.

Ask what shape the agent’s questions are.

Lookups

Can this rep sell this product in this state. What is the status of this policy. How many claims were filed in this region last quarter. These are bounded questions: the join path is knowable at design time, and the answer is a value or a set. What the agent needs here is definitions, join keys, grain and the governing rule. Give it that and it queries the data you already have. No second database, and nothing traverses anything.

Paths

The answer is the shape of the connection itself. Shortest or all routes between two points. Fraud rings, which are cycles. Centrality, meaning which node matters structurally. Who is within N hops of this entity and how are they linked. The route is the answer, not a byproduct of finding it.

That split holds up better than the criterion most teams reach for, which is depth. Depth is the wrong term to worry about anyway: a recursive frontier grows at roughly fan-out to the power of depth, so a deep narrow acyclic graph is cheap to walk as far as you like; a shallow dense cyclic one is ruinous by depth three. Enterprise metadata is overwhelmingly the first shape. For every agent that truly needs traversal, some huge number are just talking to data.

Lookups and most analytics are reachability questions: what is the set, is it connected, what is upstream. Recursive common table expressions make SQL Turing-complete, so the expressiveness argument was settled years ago and largely went unnoticed. Expressiveness is not speed, though, and I should be honest about where this runs out. One team walking a 335,000-node tree found their recursive CTE taking 47 seconds, and got it to 227 milliseconds by moving the traversal into a C extension. Note what they did not do, which is buy a graph database; they kept the traversal beside the data, in the engine they already ran. Another team published where it stops working: fine at a hundred thousand nodes and depth four, degrading at five hundred thousand and depth six.

Pathfinding is the other class, and here recursive SQL stops being merely slow and becomes a bad idea. Expressing betweenness centrality or community detection in it is an act of violence against whoever reads it next, and graph engines have decades of specialised algorithm work behind theirs. A path, a cycle, a cluster or a ranking of structural importance is a real signal and a clean one. Cycles are the sharpest case: a general cyclic graph requires explicit cycle handling that a DAG traversal never needs.

Three conditions earn a second database. None of them put the agent on it.

These are query-pattern tests, not modelling ones: the ontology argument above is about where you author; this is about what the engine is asked to do.

1. The deliverable is a path or a topology result. Shortest or all paths, cycle detection, community identification, centrality ranking.

2. The frontier actually explodes. High fan-out, many back-edges, nothing useful to prune on. Measure it rather than assuming it.

3. You need single-digit-millisecond per-entity traversal under concurrent writes. Index-free adjacency makes per-hop cost independent of graph size, which matters for operational serving and not at all for analytical work.

Now read them again with the runtime question in mind. That second read is the point, not the list itself. Not one requires an agent to touch the graph. Each is satisfied by a system that runs the traversal and hands back a result. Meet condition one and buy the engine. That still does not mean you wire it to the model.

Aggregations, rollups and temporal windows are the standing exclusion, because graph query languages are conspicuously weak at aggregation and columnar engines exist for precisely that.

The failure I actually spend my time on is earlier than any of that, and it is not technical. It is a second store proposed when the governed metadata layer the organisation already runs would answer the question, with the conviction inherited from a reference architecture rather than from the workload. Nobody has measured their frontier. Nobody has sorted their questions. The diagram had a graph in it.

The teams that get past that meet the next one, the stale replica. The proposed graph is an ETL’d copy of an authoritative relational system of record, so you are buying staleness, which destroys trust fastest in exactly the compliance and executive settings where the graph got pitched as the trust layer, and paying twice to maintain both. One engineering team published their numbers after moving hierarchy, dependency and ownership questions off a graph database into recursive SQL in the warehouse they already ran: roughly 94% less cost, about $800 a month down to about $50 a year, one less system to operate. They kept the graph engine for centrality, community detection and unbounded pathfinding, and nothing else.

Read what the graph papers actually measured

The reason this argument keeps getting made anyway is that two papers are read as saying something they do not say.

The most-cited evidence for graphs-and-LLMs is the clearest case. Sequeda and colleagues reported question-answering accuracy over an enterprise SQL schema rising from 16.7% to 54.2% when a knowledge graph was introduced. The number is real, and the paper is careful about something the citations drop: the knowledge graph there is an ontology plus mappings, functioning as a context layer the model reads, not a graph the agent traverses at query time. Three years of operational graph business cases rest on one word in its title.

GraphRAG deserves the same care, and the systematic evaluation of it is not the paper the enthusiasm suggests. Han and colleagues ran plain retrieval against four families of GraphRAG across single-hop, multi-hop and detail-oriented benchmarks. The variant that does what most people picture when they say GraphRAG, which is extract a knowledge graph from the corpus and retrieve over it, loses to plain retrieval on every question-answering benchmark in the study. On MultiHop-RAG, the benchmark built for exactly the reasoning that graphs are supposed to be good at, it scores 48.5% against plain retrieval’s 67.0%. On HotpotQA, 42.6 F1 against 60.0. Building its index takes 7,702 seconds where plain retrieval takes 135. Retrieval takes 14,434 seconds against 1,724. Fifty-seven times the preprocessing and eight times the query cost, to be worse at the thing it was built for.

Some GraphRAG variants do win, by about three points on multi-hop, and how they win is the whole argument in miniature. The strongest of them uses the graph to decide which text chunks to retrieve. The model never sees the graph. It sits upstream of the context as a routing structure, and it stops helping the moment the model has to reason across it. GraphRAG is a retrieval strategy over text, and it was never an argument for running an operational graph database.

One more number from that study, because it is the one I would put in front of anyone proposing a graph in a regulated setting. On questions the corpus cannot answer, where the correct behaviour is to decline, plain retrieval declines 96.0% of the time. The community-summarisation variant declines 19.3%. The rest of the time it has assembled a relationship out of what it found and answered anyway.

Two numbers on the same benchmark

The obvious objection is that this is rearranging deck chairs, because a governed semantic layer is already a solved problem with near-perfect published results. Look at what those results measure. Benchmarks reporting accuracy in the high nineties are scoring questions inside the layer’s modelled scope, where a human has already defined everything. The boundary is drawn around the questions that were already understood, so near-perfect tells you almost nothing.

Now measure the whole schema, including everything nobody has modelled yet. When Spider 2.0, the enterprise-grade text-to-SQL benchmark, arrived, frontier models scored in the low teens, against 86.6% for the same model on the older Spider 1.0 the field had spent years celebrating. That gap has since closed, and how it closed is the part worth reading, because the leaderboard happens to run the experiment you would want. Hold the model fixed at DeepSeek-R1 and change only what is built around it: 13.7% under the benchmark’s own reference scaffolding, 30.5% under one agent framework, 52.3% under another. Same model, same task, thirty-nine points. The same pattern shows up wherever a model repeats down the table. Nothing about the store changed in any of those runs, and nothing about the model changed either. What changed is what the system tells the model about the schema.

The controlled experiment this publication ran in February isolates that variable directly: 174 natural language questions over a thirteen-table schema, 522 runs, changing only the context layer. Accuracy moved from 16.1% on a bare schema to 22.2% with high-signal context, significant at p < 0.0001. A small absolute number on a small schema, and still the only lever in the experiment that moved at all. Verbose documentation-style context did worse than concise high-signal context, dropping 13.8% while costing 52% more, which should worry anyone planning to fix agent accuracy by pointing a model at a wiki, and for the same reason anyone planning to fix it by pointing a model at a graph.

The in-scope and whole-schema numbers are not a contradiction, and the vendor benchmarks are not dishonest. They measure different things, and only one of them resembles the request an agent gets from a user who has no idea the boundary exists.

The honest summary is less romantic than either camp wants. Enterprise text-to-SQL is not unsolved and it is not solved. It responds, reliably, to one thing: how much of the schema somebody has actually described, and how well. Which means the work is not choosing a cleverer retrieval architecture, and it is certainly not adding a traversal step. It is enlarging the modelled scope, and then keeping it current.

It also changes the failure mode in a way the percentage does not capture. A governed layer lets the system refuse a question it cannot answer instead of confidently returning a wrong number that ends up in a board deck.

The agent should never know the graph was there

I should be straight about a tension with this publication’s own archive. C&C has argued that semantic layers failed and context graphs are next, hedged with “unless we get it right.” That hedge is carrying the entire argument, so I’ll say what getting it right would have to mean.

Semantic layers did not fail because the model of them was wrong. They failed because they were built as documentation projects, maintained by hand, and went stale. A context graph maintained the same way inherits that failure exactly, with better branding and a larger bill.

That is the smaller of the two problems. The larger one is that even a perfectly fresh context graph is the wrong thing to hand an agent. Distil it instead into what the agent actually consumes: the definitions, the join keys, the grain, the governing rules, read in a single pass. The agent should never need to know the graph exists.

The distillation has to be generated, versioned, and close enough to the systems of record that nobody has to ask how old it is. Maintain it by hand and you have reproduced the staleness problem one level down, arrived at by a longer and more expensive route.

Mark twenty questions. Count the paths.

Take the last twenty questions your agent was asked, or the twenty you expect it to get, and mark each one three times.

First: path or lookup? Count the paths. If that number is at or near zero, no graph database will help you, regardless of how connected your data is.

Second: inside or outside the scope anyone has actually modelled? Count the outside ones. That number is your real accuracy ceiling, and it is the one the vendor benchmarks are not measuring.

Third, and this is the one that decides the architecture: to answer it, does the agent have to know the graph exists? Not your platform, not the pipeline that built the context. The agent. That column comes back empty even for teams who legitimately need a graph engine somewhere in the stack.

Most teams I do this with find almost no paths, a great many out-of-scope questions, and nothing at all in the third column. That combination is a context problem, and it is the one to fund.

What I ended up telling the insurer was this. A graph is for when your questions are shaped like paths. Yours look like lookups. Let’s not stand up a second database to answer a SQL question, and let’s not put the model in front of one either.

Your data was always a graph. That was never the question. The question is whether anyone has written down what it means, in a form the agent can read without walking anything.

The Cats of Context & Chaos

From the Frontier World

Recommended reads for this weekend:

• What zero data retention actually buys you: OpenAI will keep not retaining your prompts, and is adding a way to catch risky patterns across a whole run of sessions without a human reading any of it. If you run agents on long jobs through their API, this changes what your security team should be asking for. It arrived dressed as a compliance feature, but it is really a memory problem.

• What OpenAI got right, and what it still has wrong: OpenAI paused frontier training for two weeks, shelved its largest planned run, and now spends a fifth of its inference compute watching its own models. Zvi Mowshowitz thinks the money is real and the stopping was brave, and that the diagnosis is still wrong: alignment is treated as one workstream beside monitoring and security, when it is the ground both stand on.

• Why agent fleets go wrong when every agent is fine: Put well-behaved agents together and they still coordinate badly. Anthropic found that making each one smarter, or better aligned alone, does not fix it. The agents already grasp that their sources have incentives and that agreement is not proof. They just do not act on it unless told to.

• Rebuilding marketing around shared skills: A 30-person marketing team reorganised around a shared skills library, and the failures are the point. They shipped too many skills too fast, lost the ability to measure quality, and watched a content system invent pricing for another company’s product with the guardrails on. Suren left all of that in the article.

• Three agents doing the job one analyst used to: Fadil turned nearly 3,000 customer calls into intelligence nobody else in the company could produce. He has handed that job to three agents that read Salesforce fields and call transcripts together. They only work because he built the frameworks first. Without those, an agent invents its own definition of good.

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

Tathagata Das Sarma is Head of Analyst Relations and Market Intelligence. This is his reading of ten Gartner 2026 Hype Cycles, read end to end so you don't have to. The ratings, placements and profile definitions are Gartner's. The argument built on top of them is his, and is not a Gartner position.

Overview

• What ten reports look like together

• The three shifts: what the research is starting to show

  • The record needs to follow the decision

  • Trust has to be checked continuously

  • Metadata has to work beyond the catalog

• Nobody owns the middle

• What the owner would actually need

• How to check this?

• 8 questions to ask before anything else

Lets dive in!

An AI team needs somewhere to keep what an agent knows between one step and the next, so they build one. It works. Within a few months a dozen things depend on it. Eight months later a second team, elsewhere in the organization, needs the same thing, does not know the first exists, and builds a second. By the time anyone notices, there are three. Each has its own idea of what a customer is. None of them is wrong, exactly, and reconciling them now costs more than any of the projects that produced them.

Nobody decided this. Three competent teams each solved a real problem, locally, and got it right. They built their own because nothing already held what they needed. Nobody’s job was to notice that three of them were building it.

I am writing from the chief data officer’s chair, but the argument goes beyond that role. The claim is that the thing an agent runs on has no owner anywhere in the enterprise. You can check the evidence for that; the claim itself you will have to judge.

What the analysts actually blame

Ten of Gartner’s 2026 Hype Cycles, read as one body of text rather than ten documents:

• Agentic AI,

• AI Governance Technologies,

• Data and Analytics Governance,

• Data Management,

• Data Science and Machine Learning,

• Data Security Technologies,

• Data Analytics and AI Leaders and Programs,

• Emerging Technologies,

• ERP, and

• Finance Data and Analytics Governance.

Every profile in them carries an Obstacles section, the analyst's own account of why the thing is not working yet. There are 314. Each was classified by the kind of barrier it names.

The closer a technology gets to a real deployment, the more the obstacle becomes an org chart.

Before the Peak of Inflated Expectations, an organizational barrier appears in 65% of profiles. After it, in 79%.

That fourteen-point gradient is the most durable number here. It survived the set growing from nine reports to ten, and it survived a second reader coding the same profiles independently with a broader definition, who found 77% before the peak and 91% after. The important result is the gap between the two groups, not the absolute level, which is why the coding scheme and the full counts sit in an appendix rather than in this paragraph.

An earlier analysis suggested a crossover: technical barriers dominated before the peak and organizational barriers after it. That pattern did not survive a broader definition of “technical.” What did replicate was the fourteen-point increase in organizational barriers after the peak. The level changes with the definition; the slope does not.

Any of this matters because of where enterprise money sits. Almost nothing in your 2027 budget is pre-peak. The categories you are funding are in the trough and on the slope, and there the analysts name governance, ownership, skills and coordination far more often than they name the technology.

Gartner puts the underlying point in the Emerging Technologies cycle, in the meta-trends section that runs before the first profile.

In 2026, the current obsession with AI suffers from a dangerous belief that any legacy capability, when combined with a probabilistic model, instantly becomes a modern innovation. This “X + AI” formula has fueled immense hype, but it often masks a critical operational truth: introducing intelligence on top of an inefficient, siloed, or poorly governed process merely accelerates its failure.

Accelerates its failure. That’s a pretty direct statement from Gartner, especially this early in the report.

The three shifts: what the research is starting to show

Your program was built to answer questions about a dataset. Where it came from, who owns it, whether it can be trusted, who can see it. The research is converging on a question about a decision: what the system knew, when, on whose authority, and whether it still holds. A catalog entry describes data at rest. An agent acts.

Three shifts sit in that gap. Two of them need the third, which is not the same as the third being the answer.

1. The record needs to follow the decision

Context graphs entered the 2026 cycles as a new profile, carried into six of them at under 1% penetration and High benefit, holding semantics, decision traces, governance metadata, and causal links. The term is contested: the ontology community will tell you, not unreasonably, that this is a knowledge graph wearing a new hat. The shape of the artifact is not in dispute.

The brake on all of it is mundane. Most organizations have catalog coverage without lineage depth, so there is nothing to build on.

Here is the test, and it takes a week. Reconstruct one production agent decision end to end. Four things have to come back, and you pass or fail on all four:

• the context it retrieved

• the policy in force at that moment, not today’s

• the identity that authorized the action

• the version of the semantic definitions it used

If you can’t produce one of these, you’ve found a context gap. Also record how long it took to find out.

Why traditional governance fails at the decision level

Traditional governance was designed for periodic, human-driven audits: checking table schemas, row counts, and access policies once a month. An autonomous agent operates on a millisecond timescale, making hundreds of contextual decisions a minute. Trying to govern agentic decisions using traditional governance frameworks is like trying to manage real-time network traffic with quarterly committee meetings. The control cannot be an external committee; it has to be built directly into the context layer itself.

2. Trust has to be checked continuously

Zero-trust data governance entered the D&A Governance cycle this year at 1% to 5% penetration, rated embryonic. The same report then puts it in the two-to-five-year column of its priority matrix, and names it alongside data observability and AI governance as a place to look for near-term value. Embryonic maturity and a near-term horizon do not sit together comfortably in Gartner’s own framework. Read that as the analysts pulling it forward.

The governance cycle carries the planning assumption directly: by 2028, half of organizations will implement a zero-trust posture for data governance, driven by the proliferation of unverified AI-generated data. With machine-generated data the lineage lines break and provenance becomes unknowable after the fact, so verification has to be continuous. Certification-based governance is entrenched because it produces a number for the board, and a posture does not.

Tag provenance for AI-generated content now, while retrofitting is still possible. This is the one item where waiting a year makes the work harder rather than merely later.

3. Metadata has to work beyond the catalog

I think this one gates the other two. Metadata management solutions sits on the Slope of Enlightenment at early mainstream maturity, 20% to 50% penetration and two to five years to plateau, in six of the ten cycles including Data Security and ERP. The framing is a move from passive catalogs to active metadata available wherever it is needed, and the recommendations are about interoperability rather than coverage.

That describes a component inside someone else’s architecture, not a destination. It carries meaning, lineage and policy well, and procedure badly or not at all. Anyone who tells you the metadata layer is the context layer is selling you the part they have.

Two other profiles make the same error from the other end. Both are probably on your roadmap already.

Model Context Protocol sits on three of the ten cycles at High benefit and 1% to 5% penetration, and its obstacle text is the part to read: most MCP clients disproportionately emphasize tool listing and tool calling while ignoring the rest of the protocol, which narrows it to function calling at scale and undercuts its intended role as a general context interchange protocol. The standard is being installed before anyone has agreed what should move through it. Standardizing how a model reaches your systems does not settle what “active customer” means in either of them.

Automated data governance is the same shape. It sits at the Innovation Trigger at 1% to 5% penetration, High benefit, and five to ten years from mainstream adoption in every cycle carrying it, which is further out than most governance roadmaps assume. The reasoning is spelled out. Foundational governance capabilities have to be achieved first, and where critical definitions, rules and process knowledge remain implicit, they limit the scope of what can be automated. Automating a policy nobody wrote down does not shorten the five years. Convert your three most-referenced policies into machine-checkable rules and run them against live data. The failure rate tells you whether those policies were ever real.

The reports do not carry the gating claim. That one is my inference, so here is the case against it. Teams ship agent context into production without that layer every week. Foundation first is the oldest available argument for deferring work that ought to justify itself on its own merits, and a year spent on the foundation while nothing reaches production is a real cost, not a hypothetical one. What persuades me anyway is narrow. The other two both need a machine to retrieve something at decision time, you can supply that locally per use case, and three teams doing exactly that is the scene this article opened with.

Test whether your metadata can be read programmatically by something that is not your catalog’s own interface. It takes an afternoon and commits you to nothing.

Before you write next year’s budget

Categories in this research leave by two exits. Some graduate, reaching mainstream adoption and dropping off because they started working. Others get absorbed, and that one costs you money.

Augmented data management is the case to look at. The profile carries a Transformational rating, the highest available, in both the Data Management and Finance governance cycles, and its own recommendations name agentic data management as its next phase. The Data Management cycle marks it obsolete before plateau, naming it alongside data mesh. So the highest rating available sits on a label the research is already retiring. The capability survives, the name does not, and any funding case written against the name goes with it.

Nobody owns the middle

Three things, and two of them need the third. That is the list as it looks from your chair.

Now read it from the one across the corridor. Context infrastructure is the CIO’s version of the decision record. Same question about what a system knew and who let it act, but it arrives on that desk as an unscheduled build-or-buy, and gets decided by default when three teams each solve it locally. The identity half of your zero-trust posture is, on that side, a profile called AI agent identity, which entered the Agentic AI cycle this year at 5% to 20% penetration, further along than anything on your list and far ahead of the context layer it will need to reason about. Its listed drivers read like an incident report written in advance: an epidemic of human credential sharing, agents deployed as proxies on human credentials, breaking auditing and nonrepudiation. And your metadata layer is, in the Data Security and ERP cycles, a security control and a migration dependency, frequently bought twice by two functions who do not know the other is buying it.

So you end up with the same problems sitting on two executives’ desks.

None of that is inference. Five of the ten reports state it outright.

Data Security, on data discovery: frequently no clear owner accountable for the outcomes; the teams operating the tools may lack the authority to act on the findings; the disconnect between visibility and downstream action creates accountability gaps across data domains.

Finance Data and Analytics Governance, on decision-centric governance: these innovations signal a shift from governing data to decisions while expanding governance to include knowledge, metadata and unstructured data, and progress is slowed by unclear ownership and cross-functional dependencies.

Data Management, on data contracts: low governance maturity and unclear ownership create ambiguous accountability for defining and maintaining specifications, including overlapping or conflicting ones.

Agentic AI, on agentic accountability: ownership and accountability for agentic decisions, actions and components require an approach spanning policy, technology and organizational awareness.

Data, Analytics and AI Leaders: increasingly blurring boundaries within governance silos and between adjacent governance programs, with existing bodies designed around functional areas, making enterprise accountability and decision rights hard to establish.

The wording varies, but the ownership problem is the same across all five reports.

The research also has a name for the middle. The Finance cycle carries a profile called Knowledge Fabric, defined as digital infrastructure enabling semantic interoperability by connecting diverse knowledge sources into a unified context layer, drawing on metadata alongside structured and unstructured data. The Data Management cycle’s framing for the year is an increased focus on context layers and semantics. Gartner is already using the language of a context layer. What is missing is ownership.That is the narrow claim, and it is the one this article is making.

Enterprises have clear ownership for three things. Datasets belong to the data organization, applications and infrastructure to IT, models to whichever team you designated for ML and AI. Each has a budget line, an on-call rotation, and a person whose title contains the word.

The thing an agent acts on is none of the three. Suppose someone did own context. Here is the inventory they would be maintaining:

• what a term means

• which data is authoritative

• what policy applies

• how the work is actually done here

• what happened before

• who is allowed to decide

The first three already have places where people expect to find them. Semantics live in a glossary. Provenance lives in lineage. Policy lives in documents or, increasingly, code.

The other three are much harder. Procedure lives in tickets, runbooks and the three people who remember how the monthly close runs. Decision history lives in logs nobody reads with meaning attached. Authority lives in an IAM system designed for humans.

Procedure is probably the clearest example. A catalog can tell an agent what “net revenue” means and where the authoritative table is. It cannot tell the agent that the close is not final until the Singapore entity confirms, that three known exceptions get handled by hand every quarter, or that the number is provisional until Thursday. A new analyst learns that in six weeks from people. An agent never learns it at all, because no system holds it and no function is accountable for holding it. That is the difference between a catalog and a context layer, and it is why the metadata layer, however good it gets, only ever describes part of the problem.

The order matters, because it decides what you do about it. Procedure, decision history and authority are unowned partly because nothing holds them. There is no artifact for a domain expert to maintain, no system a steward could be accountable for, nothing an audit could be pointed at. The ownership gap exists partly because there is nothing concrete for someone to own. An owner appointed over that is a person with a spreadsheet. The vacancy is real, and it sits downstream of an absence.

When governance and policy is the most-named barrier across all ten reports, the analysts are not saying governance software is missing. They are saying that where these technologies have to work, there is no one whose job it is to make the call. The work sits between two org charts, and every proposal to resolve it reads to one side as a land grab and to the other as a dumping of work.

There is an obvious candidate: the data organization. You are the closest fit. Nobody else sits at the intersection of data, semantics and trust, or is already accountable for what a term means and whether a source can be relied on. Drawing the org chart from scratch, context reports to the data organization.

The research makes that harder than it sounds. All three items land at least as heavily on the CIO’s side as on yours, and the authority question underneath agent identity is not a data capability under any reading.

A CDAO handed context without the identity model, the delivery pipeline and the platform budget has been given a title rather than a job.

So here is the recommendation, plainly, because a diagnosis without one is not much use. Context should have one accountable owner, and that owner most plausibly sits in the data organization, holding a mandate that reaches into infrastructure. Not a council or a working group. One person with a budget and an on-call rotation, like every other capability someone owns.

The difficult part is the infrastructure authority that comes with the role. Enterprises keep stopping short of granting it. Everything below is a way to find out how far you are from being able to grant it.

What the owner would actually need

An owner for context as a capability, not a tool. Organizations tend to spend most of their time debating the reporting line. The harder question is what the role can actually reach. If the owner cannot set requirements on the identity model, cannot gate the delivery pipeline, and cannot stop a team standing up its own context store, the title exists and the capability does not. The real question is for the CIO: what will you let this person constrain? Get it answered now, because after the first incident the role goes to whoever was closest to the failure.

One joint decision reconstruction, with both organizations in the room. Trace a live agent decision end to end against the four-item test. Your team will find the semantic and lineage gaps, theirs will find the identity and authority gaps, and neither finds both alone. That is the point.

One shared test for the metadata layer, agreed before either of you buys anything. Can a system that is not the catalog’s own interface read it. Use this as a diagnostic before you make it a purchasing requirement, because the answer tells you where you stand without telling you what to buy. Answered separately, the two organizations land in different places, and every downstream item inherits the discrepancy.

How to check this?

The gradient is the part you can check yourself. It comes from a keyword coding of the Obstacles text across all 314 profiles, split at the peak. Recode it your own way against your own copies of the reports. If the pre-peak and post-peak shares come back close to each other, the argument is dead. The connection between those five observations is my inference, not something the reports say directly. So is calling the thing that lacks an owner “context.”

8 questions to ask before anything else

To test whether this gap is currently costing your organization money, bring both IT and Data into the room and run through these eight self-diagnostic questions before your next procurement cycle:

1. For the most consequential agent decision last month, can you produce the four items above: context, policy in force, authorizing identity, semantic version? How long did that take?

2. What share of the data entering your estate this quarter was machine-generated, whether by models, agents or humans, and how do you know?

3. Which three policies do you enforce, as opposed to publish?

4. Can a system that is not your catalog read your metadata without a human in the loop?

5. How many places in your estate store agent state or memory, and which team owns each?

6. If an agent exceeded its authority tomorrow, whose incident process owns it?

7. Are your data policy enforcement roadmap and your policy-as-code roadmap the same roadmap?

8. Who would notice first if the answer to question one was “we cannot”?

Nobody woke up intending to build three incompatible context platforms. They simply built what the organization never decided to own.

This article was originally published on Context & Chaos platform!

The Cats of Context & Chaos

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

The panic is real. The playbook it triggers is aimed at the wrong unit. Getting to the right one starts with why the demand showed up everywhere at once.

Why the demand arrived all at once

A year ago this was a next-year problem. Then coding assistants put building into everyone’s hands, and an agent stopped being an engineering deliverable and became something a sales rep assembles on a Tuesday afternoon.

Enterprise governance was designed for software that arrives through procurement. Today the software arrives through enthusiasm.

The demand outran the answer. McKinsey’s 2025 State of AI survey, fielded across 1,993 respondents in 105 countries, put 62% of organizations at least experimenting with AI agents, 23% of them scaling in at least one function. Among organizations using AI, 51% had already seen at least one negative consequence in the previous year. What neither number captures is who was answerable for any one of those agents when it went wrong.

The current playbook governs the wrong unit

The reflexive answers arrive from two familiar directions. Procurement-led control towers tell you which AI products the company bought. Privacy and compliance platforms tell you which use cases passed an assessment.

Both are useful, and both miss in the same predictable place. A control tower sees the assistant the company holds a contract for, and not the agent someone assembled inside it last week. A compliance platform assesses a use case at the moment it is approved, and never sees the tool connection swapped into it three weeks later. Neither is a failure of rigour. One is an inventory of purchases, the other an inventory of approvals, and the thing actually running in production is neither.

They share the deeper assumption too: that the agent is the unit of governance, a thing you list, score, and approve, the way you once listed applications. That assumption is where the playbook breaks.

An agent is a composition, and the parts are what hold still

An agent looks like words. The canvas on the front end reads like prose: instructions, descriptions, personas. Behind the canvas, all of it is code, and each agent is a composition. Underneath every one sits a set of artifacts: skills, tools, MCP servers, credentials, knowledge folders, memory. The agent everyone is being asked to inventory is the sum of those parts.

That reframing is not new here. This article by Prukalpa Sankar on Context & Chaos has already argued that a skill is a primitive: a reusable, versionable, testable unit of how-to, managed the way software engineering manages code. The parts are also the only stable thing in the system. An agent is the least stable object there is: it gets renamed, forked, cloned by someone who did not know the first one existed, abandoned by an owner who changed teams. Underneath the churn, the same dozen skills and the same few tool connections keep reappearing. Skills are where this bites first. They are the most reused artifact in the set, which means the widest blast radius when one changes and the most people downstream of an edit nobody announced. Ownership assigned to an agent expires the moment the agent is renamed. Ownership assigned to a skill survives every agent that composes it. That is the whole case for moving governance down a level: attach it to the parts and it holds through the churn above, including the agents nobody registered, because an unregistered agent still has to be made of something.

There is a deeper version of this that looks organizational rather than technical. Joe Reis makes it directly: point agents at a siloed company and you get more silos, faster, and what they actually need is access, shared semantics, and a human who owns the result. But a human who owns the result has to own something durable, and the agent is not durable. Attach the person to the skill and the ownership holds. The artifact is where the org chart attaches too.

The discipline is familiar. Only the artifact list is new.

Data teams spent two decades learning this on tables, views, and columns: catalog them, trace their lineage, name an owner, and treat the description of the asset as an asset in its own right. That last habit is the one that transfers, and two writers in this publication have already located where it lands for AI. Juha Korpela argues that conceptual modeling, the discipline the industry quietly abandoned a decade ago, is exactly what agents need now, and that semantics should be separated from data and governed as its own layer. Jessica Talisman set out the vocabulary for that layer. The governed thing was the description of the data as much as the data itself. Agents need exactly that, one artifact list over.

What those artifacts do not have is the tooling. Skills that are code libraries in every meaningful sense get filed like documents, in office suites and shared drives and trackers built over a weekend, and then asked software questions they cannot answer.

Where source control falls short

Most technical readers raise the obvious objection here, and it is the best one. Agents are code, so put them in source control and inherit the software development lifecycle. It falls short on a specific boundary. Source control was built to hold versions of files, not to answer questions about how those files relate. It does not hold the dependency graph between skills. It does not know that one skill is used by five agents, or which agents broke when someone edited it this morning. It does not know who is using what, and it knows nothing about what any of it costs to run. The inverse holds too: skills do not need branching, which is pure overhead for an artifact whose consumers need audit history, versions, and a named owner.

The closer analogy sits one layer over from the repository: a package registry. The repository holds the code. The registry answers who depends on this, which version is safe, and what breaks if it changes. That second set of questions is exactly what governance leaders are being asked this quarter. The request arrives dressed as a version control problem, and underneath it is a registry problem.

Artifacts live at several altitudes

A registry answers who depends on what. It does not answer where an artifact belongs. That second question is altitude, the level an artifact sits at. Some belong to the whole company, the instructions and guardrails every employee’s agent should inherit. Some belong to a department, some to a single team, some to one person. Governance has to handle promotion upward and inheritance downward, and the failure modes are easy to trigger. On the estate I work on, a company-wide instruction file was pushed to every machine, and the push overwrote the local instructions individuals had written for themselves. The control landed exactly as designed. The outcome it existed to protect died on every machine it touched, and nobody was notified, because nothing in the system knew that two artifacts at different altitudes were fighting for the same slot. Layering, promotion, inheritance, and precedence are governance problems, and a spreadsheet has no column for any of them.

What good looks like

Three moves, in order.

• Derive the inventory instead of collecting it. A registry that depends on humans filling in forms will never keep pace with the rate at which agents are created. In the data world, inventory stopped being declared and started being scanned. Agents have no connectors, but they leave traces: every session already carries attribution for which agent ran, which skills it invoked, and which tools it touched. On our own estate, inventory derived from what actually runs is the only kind that has stayed accurate, because nobody has to remember to declare anything, and it survives a rename.
  

• Lifecycle over a list. A list tells you what exists. Lifecycle tells you what happens when something changes: versions, audit history, named owners, promotion across altitudes, and the ability to pull one artifact and know exactly which agents just lost a dependency. That last capability is the kill switch most inventory projects quietly lack, and it is the one an incident asks for first.
  

• Attach cost to the artifact. License costs are fixed and negotiated once; token costs follow usage and compound. Until spend traces back to specific agents and the artifacts inside them, nobody can say which agents return value and which are expensive duplicates of the one sitting three folders away. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. Two of those three are visibility problems before they are strategy problems.

Start with one skill

Pick one skill this week that more than one of your agents uses. Ask who owns it, which agents depend on it, and what breaks if you delete it tonight. If those answers take longer than five minutes to assemble, that skill is not governed. Neither is anything built on it.

Gartner predicts the average global Fortune 500 enterprise will run more than 150,000 AI agents by 2028, up from fewer than 15 in 2025. Nobody governs 150,000 agents by hand. Everyone can govern the parts they are made of. So when the executive asks how many agents you have, the answer that survives next quarter’s sprawl is a different one: here is what they are made of, here is who owns those parts, and here is what happens when one of them changes.

This article was originally published on Context & Chaos platform!

The Cats of Context & Chaos

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

AI slop produced by a human is a yellow flag. Sometimes it’s worse than not using AI at all.

I sent that to our team a year ago, after watching something strange take hold. More and more of the work inside our company was arriving as polished, AI-generated artifacts. Enablement material that once would have been a document became an interactive website. Ideas became prototypes in hours. There were tabs upon tabs of things that looked finished. At first, it felt like progress. AI usage was rising. People were building. The work often looked better than it had before.

But much of that material went unused, or was discarded soon after. We had lowered the cost of making something without raising the odds that it would matter. And the low-value output was not harmless. It became context for the next person, or the next model, to build on.

The word human in the note at the start is the whole point. The model generated the artifact, but a human chose the problem, accepted the quality, and decided it deserved other people’s attention. Not using AI might make one person slower. Using AI without judgment can make the whole organization slower.

What judgment is to a single artifact, organizational metabolism is to a company:

the thing that decides whether a new capability becomes a better outcome, or just more output.

The adoption trap

I can recite all of our AI numbers: licenses provisioned, weekly active users, tokens consumed, agents created, hours supposedly saved, artifacts shipped. Our investors routinely tell us we’re in the top 1% of AI adopters. But those numbers measure whether people are using AI. They are not an indicator of whether the company is getting more capable using AI.

An enablement site only matters if it changes how the field sells. An agent only matters if it improves a consequential decision. A campaign only matters if it earns attention and trust, not because it produced more assets than a human team could have.

When creation was expensive, a polished artifact signaled commitment. The effort was a natural brake. AI has removed most of that brake, and our instincts haven’t caught up. We still read volume and polish as evidence of value. Left unchecked, the result is a new kind of organizational theatre: AI output theatre.

So what makes a company frontier?

The durable advantage is organizational metabolism

AI is usually described as a tool to adopt and that understates the actual change. It’s a foundational capability you can redesign work around, and the question that matters is whether the organization can turn that capability into a new behavior, and then into a new outcome.

In the previous year alone, we rebuilt the AI architecture of our customer success team four times. Each version worked at first, then hit a wall, and each time we decided to rebuild instead of patching over the cracks. We started with a prompt-based setup. Then we move to agents and humans working together through an explicit org chart. That became a single proactive system living inside the team’s chat.

Today we’re building the fourth: one system with a shared brain, an interface where the team manages tasks and gives feedback, and self-learning loops that get better every time a human corrects them.

Do we regret rebuilding that architecture four times? Not for a second.

Why? Because for a company operating at the frontier, that might be the point. Each time, we reimagined the work and ended up building a new advantage in the process.

Here’s the belief I’ve landed on. The models will change. The tools will change. Today’s frontier workflow will be tomorrow’s default. The durable advantage is organizational metabolism: how quickly you can notice a new possibility, test it against reality, absorb what you learn, and change how you work.

Change the outcome, not just the output

Frontier companies get more ambitious, not just more efficient

Most conversations about AI productivity focus on multipliers: more code, more campaigns, more content, more work per person. There’s no doubt in the fact that, efficiency matters. But if the result is ten times as many emails, slides, or lines of code, we have confused greater production with greater capability.

The more interesting question is not “How can AI help us do this faster?” It is “If today’s capabilities had always existed, would we have designed this task, role, or team at all?”

One of our marketers recently made that question real by building a personalized web experience. It uses intent signals to infer a visitor’s company, pulls together the context we already have about that account, and generates the experience as the visitor arrives. Instead of sending everyone through the same set of pages, it gives each visitor the information most relevant to who they are.

This is not pre-generating a hundred landing-page variants. It changes the unit of work: from producing pages to assembling an experience around a person’s context, where what helps the visitor most turns out to be what converts fastest.

It’s still an experiment, not a proven growth engine. We also need to learn where personalization becomes inaccurate, invasive, or untrustworthy, and what review and stopping rules it demands. But it changed the question I was asking: from how to make more landing-page variants to whether every visitor can arrive at an experience built around who they are. That shift, from producing more of the old unit to imagining a new one, is what greater ambition looks like.

The organization has to absorb the change

New capability does not transform a company until the organization moves with it. Knowledge work has long divided complicated outcomes among specialist functions, each connected by handoffs. That structure created scale and protected expertise. It also fragmented ownership and turned the movement of context into a job of its own.

AI gives one person access to capabilities that once lived across functions. A marketer can build. A product manager can prototype. An operator can create internal software. Deep expertise is not less relevant in that world, but it sits in different places, and every handoff has to re-earn its cost.

Some boundaries should stay. High-stakes claims still need independent review. Deep technical work still needs deep expertise. Privacy, security, and brand risk still require accountable owners.

The decision rule we are testing is this:

Remove a handoff when it exists mainly to transport context. Preserve independence when it exists to challenge judgment, control risk, or contribute scarce expertise.

The structure we’re testing, small cross-functional pods, is still an experiment, but there are early signs it’s working. I just came back from our marketing retreat expecting to hear how the team was coping without traditional management structures. Instead I mostly heard gratitude, and a common refrain: they couldn’t believe they’d ever worked the old way.

Is the real frontier human?

The more powerful AI becomes, the more the human operating it matters. Give two people the same model. One produces ten acceptable versions of an existing asset. The other asks whether the asset should exist, reframes the problem, and attempts an outcome that used to be beyond an individual’s reach. AI supplies the leverage; the human chooses the direction. Judgment decides what’s worth doing, and taste decides whether it’s any good. To work at the frontier, an expert has to keep consenting to become a beginner.

This is why we’ve started rethinking human skills directly. One tool is a simple grid with two axes, human skills and AI leverage, as a way to start thinking about where human impact actually comes from.

The next few years may feel like fight, flight, or freeze: roles will change, familiar skills will become abundant, and the boundaries people use to define their professional identity will move. But fear cannot be the operating principle for people trying to thrive in this new world. And this is where the organization has responsibilities too: to create room for learning, make changing expectations explicit, and help people develop the skills the new system requires.

The human frontier is whether a company can increase machine leverage without diminishing human agency, not simply whether individuals can adapt quickly enough.

Writing it down, in the open

We’re trying to build a truly frontier company. We haven’t finished, and I don’t think anyone has a finished playbook. The primitives are being invented while we use them.

• What happens to the role of the manager?

• How should AI-native work be measured?

• What does a 100× outcome look like without becoming a 100× productivity treadmill?

• Which kinds of expertise matter more, and which handoffs disappear?

These are the questions hard to answer from only one side of the frontier. Many of the companies writing most openly about AI-native work were born in the AI era, with no pre-AI organization to unwind. That isn’t the situation most of us are in. Most companies have existing customers, roles, systems, and identities. They can’t start over. They have to transform without losing the trust, expertise, and business they’ve already built.

We sit in an unusual spot between those worlds. We’re rebuilding our own company around AI while building technology that helps some of the world’s largest enterprises do the same. We see the questions emerging inside AI-native startups in the Bay Area, and the very different reality of making those capabilities work inside institutions with decades of history.

There’s one more reason to write this in the open. Social media has turned AI transformation into a highlight reel: companies share what’s working and hide the failed experiments, the abandoned architectures, and the quiet fear about what new systems mean for people’s jobs.

Our own company will be the laboratory, not the hero of every story. I fully expect our views to change as the evidence changes.

The frontier company will not be the one that uses the most AI. It will be the one that can responsibly shorten the distance between a new capability and a better outcome, and keep changing its form without losing its purpose.

If you want to know where your company stands, try a five-minute test. Pick the last AI-generated artifact your team shipped and ask these questions:

- Who chose the problem
- Who accepted the quality
- Who decided it deserved other people’s attention.

If no one can answer, congratulations you’ve found your slop.

If you’re building with AI at work, workflows, agents, internal tools, this next part is for you.

This week we launched Atlan Frontier Labs, the build log where we’re documenting this rebuild in public. Real numbers, real failures, human gates.

• We rebuilt marketing around 300 shared skills — Surendran Balachandran

• An agent watches every page on our website, because we ship faster than we can watch — Dubem Izuorah & Kushagra Gupta

• We turned our revenue intelligence from one analyst into a fleet of agents — Mohammed Fadil

If you’ve built something with AI that made your team meaningfully better, tell us what you built. We’d like to feature it on our build log - Becoming Frontier!

This article was originally published here!

The Cats of Context & Chaos

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

One detail stood out to me. As the team sprints toward the objective, every set of eyes locked on what is in front of them, one guy calls out something the others do not. “I got long!”

Translation: I am watching the distance. I am looking for what the rest of you cannot see because your eyes are on the target. Somebody has to. One man’s job boils down to this: do not let the immediate threat blind you to the one coming.

That scene is playing out in enterprise AI right now, just with worse cardio and more JIRA tickets.

A lack of context portability is the threat in the distance. Almost nobody has felt it yet because almost nobody has gotten far enough to feel it. Most teams are still on the immediate objective: stand up the context, ship the first agents, get the evaluations in place, build some confidence the thing actually works. That is the right work to be doing. It is also exactly why nobody has their eye on long.

What “long” actually looks like

Think about the last time you switched phones. iPhone to Android, Motorola Razr to iPhone, whichever direction. You did not sit down with a notebook and re-enter five hundred contacts by hand. You exported them, imported them, they showed up on the new device. The contacts were yours, not the phone’s.

Context portability is the same idea, applied to the meaning of your data.

The tight version: your data’s meaning should travel with the data, not with the tool it happens to be configured inside.

Most companies do not have that today. There is no canonical source for what “active customer” actually means. What exists is a definition inside the CRM, a different one inside the BI tool, a third inside whatever the AI team is building. That is what happens by default. When there is no authoritative version, every tool invents its own, and every new tool has to invent it again.

Context portability means you define it once, and that definition travels. Your AI agent, your CFO’s dashboard, the calculation in your customer-facing app, all of them answer the same question the same way, because all of them are reading the same authoritative version.

And it is not just metric definitions. The same problem applies to everything your data means: which columns hold PII, who owns the customer table, which policy governs access to it, what counts as certified. A definition of “active customer” that does not travel gives you a wrong number. A PII classification that does not travel gives you a compliance incident. Meaning is bigger than metrics.

Why this was a smaller problem before, and why it is a bigger one now

Lock-in is not a new problem. Anyone who has migrated off a BI tool knows what it feels like to rebuild semantic meaning from scratch. LookML in Looker. Metrics in Tableau. Five hundred dashboards full of calculated fields that one analyst built and then left the company two years ago without writing anything down. Painful. But bounded. You rebuild the dashboards, you curse the previous vendor for a week, and life goes back to normal.

AI changes that. The ceiling comes off.

Three things break.

The first is that every agent needs authoritative context to function. Not “plausible” context. Not “inferred from a column name” context. The definition your business has actually agreed on, delivered to the agent at the moment it needs it. Most agents, especially the ones running in automated pipelines, batch processes, or behind a natural language query interface, do not pause to ask clarifying questions. They answer from whatever context they can reach. Even conversational agents that can ask follow-up questions will not ask “what do you mean by active customer” if the definition is not in their context to begin with. They cannot ask about something they do not know is missing. Whether your agents can ask is beside the point. What matters is whether the definition they need is reachable at query time, from the authoritative source, before the answer is generated.

The second is that the cost stops being one-time. Every new agent re-incurs it. You stand up your first agent on top of a curated dataset. It works. You stand up the second agent on a different stack, and now you are re-authoring the same business meaning a second time. The third, in a different cloud, and you are re-authoring it a third time. None of them inherit the work of the others. The investment does not compound. It restarts.

The third is that the failures stop being loud. When two dashboards disagreed, somebody eventually filed a ticket. Somebody argued. Somebody escalated. The disagreement was visible. When two agents disagree, nobody sees it. Each is answering a different question for a different audience, confidently, on a different definition. The divergence never surfaces until somebody happens to compare notes weeks later, by which point the CFO has been making decisions on the wrong number for two quarters.

The version of this I hear most often, from data leaders across very different industries, goes something like this. Getting the right context to an agent at build time is a solved problem, or close enough to one that most teams can work through it. What they cannot do is move that context everywhere else it needs to live, and pull it back down at the moment an agent actually needs it. That gap, between setting one agent up correctly and being able to do it at scale, is the thing nobody has an answer for.

The pattern underneath it is always the same. A company already has agents running on four or five different platforms. Different teams, different stacks. Every one of those agents needs to know what an “active customer” is. None of them are getting that answer from the same place. The problem is structural, and it is about to get expensive.

That is what long looks like.

The obvious response is to wait for the platforms to solve it. Every vendor in your stack is promising to hold your context for you, and every one of them means it. Notice what that is. Portability that reaches only where one vendor’s platform reaches is just lock-in with better marketing. If your definitions can only travel where one vendor’s platform reaches, you have not made your context portable. You have chosen which walled garden it lives in. Contacts became portable because they became a standard nobody owns. The meaning of your data needs the same thing: authored once, governed in one place, readable by every tool you run today and every tool you have not bought yet. That has a concrete implication most teams miss. The definitions themselves have to live in a format any engine can read, the same way open table formats are ending warehouse lock-in for the data itself. Portability is a property of where the meaning lives. It is not a feature a platform grants you.

What you actually get

Two problems get solved when context is portable.

The first is the authoring problem. Without portability, “active customer” lives in four places with four owners, which is four opportunities to drift. And they will drift. Someone updates the CRM to exclude churned trials. Nobody updates the BI tool. Nobody updates the agent. Six months later, the CFO’s board deck reports 41,000 active customers, the AI agent tells the CS team 38,500, and the head of sales is on a call asking which number is real. Nobody in that meeting is having a good time.

Portability collapses that into one definition, in one place, with one owner. Every downstream tool reads the canonical version. When it changes, it changes everywhere.

The second is the migration problem. Your stack is going to evolve. You will change BI tools, add a warehouse, adopt an AI platform that did not exist when you designed the last one. Without portability, every one of those moves means rebuilding the meaning of your data from scratch on the new tool. With portability, the tool changes and the meaning stays. When you switch phones, the numbers do not move because the phone did the work. They move because they were never really the phone’s to begin with.

Portable is not the same as governed

This is the part of the argument where I have to slow down, because it is where most portability conversations go sideways.

Making your context portable does not, by itself, make it useful. A portable definition that nobody owns is still tribal knowledge, just in a different format. If “active customer” travels between tools but nobody is on the hook for what it means, when it last changed, or who signed off on it, you have not solved the problem. You have made it easier to distribute the mess.

Three things have to travel with the definition for portability to actually matter.

Ownership. A named human is accountable for what “active customer” means. When the definition needs to change, that person owns the change. Not a Slack channel. Not a wiki page nobody has opened in eight months. A person.

Version history. Every change is captured. When a downstream agent starts giving different answers than it did last quarter, you can trace it back to the definition change that caused it, and to the moment the change happened.

Lineage. When “bookings” gets redefined, you can see every dashboard, every agent, and every model that depends on it. The change might be right. You should never be surprised by what it breaks.

Skip any of these and portability turns into distributed drift. Same definition, five places, none of them talking to each other. You made the problem worse.

Portable is not the same as delivered

There is one more thing that has to be true for portability to work. The definition has to reach the agent.

A perfectly authored, perfectly governed definition sitting in a catalog is not portable if the agent cannot read it at query time. It is documentation. Very good documentation. Not what an agent needs.

Portability requires a delivery mechanism. Something that puts the authoritative definition in front of the agent, programmatically, at the moment the agent needs it. Not baked into a system prompt six weeks ago. Not copied into a YAML file that has already drifted from source. Live, at runtime, from the canonical source.

The delivery mechanism does not have to be one thing. It can be MCP. It can be a semantic layer API. It can be a file protocol. It can be a direct query interface. What matters is that the agent is reading from the authoritative source at the moment it is being asked, not from a stale copy that got embedded somewhere along the way.

Skip the delivery mechanism and all the work of building governed, portable context produces nothing at the moment of the query, which is the only moment that actually matters.

Why one guy calls long

The SEAL who calls “long” is not solving the immediate problem. His teammates are on the immediate problem. His whole job is to make sure they get to do that job again tomorrow.

Context portability works the same way. Building it now does not make today’s agents any better. Today’s agents are working. That is not the argument. The argument is about what happens on agent number six, or agent number ten, or agent number twenty-eight. Whether they inherit the work you have already done, or they start from zero because nobody built the layer that lets the meaning travel.

Almost every enterprise AI team is going to end up with more agents than they have today. Some will have hundreds. A few will have thousands. The teams that build for that reality now are going to spend the next three years compounding their work. The teams that do not are going to spend the next three years paying the same authoring tax, agent after agent.

Compounding is worth being precise about. The case that context compounds through feedback loops has been made in these pages before. Portability is the precondition. An agent that discovers a definition produced a wrong answer in production has just generated context the next agent needs. Nothing flows back, and nothing compounds, across agents that cannot reach the same canonical source. The difference is whether your context can be written to, not just read from.

Neither team can tell you which one they are yet. Both are executing well against the immediate objective. The difference will not show up in quarter one, or quarter two, or in the first ten agents. It will show up somewhere between agents fifteen and thirty, when the cost of another re-authoring cycle stops being tolerable and everyone realizes that the way they set the problem up in year one is going to cost them the next three.

That is the guy calling long. And right now, in enterprise AI, almost nobody is calling it.

What to do about it Monday

There is a window for building this in, and it is smaller than most teams realize. Retrofitting portability onto twenty agents that were each configured against their own definitions costs more than building the layer from the start. If you have five agents today, you are in the window. If you have thirty, you are already paying the tax.

Which is why the diagnostic below matters. Run it this week.

Pick one definition your business actually argues about. Active customer. Qualified lead. Recognized revenue. Something whose interpretation carries real money, where the sales team, the finance team, and the analytics team are known to disagree.

Count the places it lives. Really count. Include the CRM. Include the semantic layer. Include the BI tool. Include the metric definitions embedded in dbt models. Include the spreadsheet the CFO’s team maintains and the Notion doc the analytics team keeps promising to update. Include the prompt of every AI agent you are already piloting.

Whatever number you get, that is your portability debt on one metric.

Now multiply by the number of agents your team plans to build in the next twelve months. That is what you are on the hook for if the layer underneath your agents cannot make one definition travel to all of them.

And remember what one unit of that multiplication costs. Standing up validated context for a single agent, finding the definitions, getting them agreed, wiring them in, runs 30 to 60 days in most enterprises I have seen. That is the cycle you are signing up to repeat.

One more thing: give the count an owner. In most organizations this lands naturally with whoever already owns data governance, because they already own the definitions. It is one person whose eyes are on the distance, not new headcount.

If the number scares you, congratulations. You just called long.

Long

Enterprise AI is going to run on agents. Lots of them. Some you will build. Some you will buy. Some are already inside tools you are paying for. Salesforce Einstein. Microsoft Copilot. Workday AI. ServiceNow Now Assist. They are already in your environment, already reasoning over your customer data, already answering questions your users are asking them. And every one of them is reading a definition of “active customer” from somewhere. The question is whether any of those somewheres is a place you have signed off on.

The teams that figure this out early are not going to look like they are doing anything special right now. They will just be the ones whose agents scale two years from now, while everyone else is stuck rebuilding the same definitions in slightly different YAML for the third time.

This article was originally published on the Context & Chaos platform.

Author Connect

Connect with Landon on LinkedIn!

The Cats of Context & Chaos

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

By the middle of last year, we could build an agent in about five minutes. Giving it enough business context to be accurate took forever. In the twelve months that followed, my company moved through five agent-stack configurations. Each change left something important behind: not the agent, which was easy enough to recreate, but the context that made it useful.

At one point, we had roughly 300 skills powering 40 active agents. The lesson from getting there was uncomfortable: the agents were never the hard part.

At the AI Engineer World’s Fair, I opened the build log behind that conclusion. I walked through two eras of building agents inside our company: first, an agent for every job; then, one shared company brain serving many agents. Both worked. Both eventually hit a wall. And the second wall exposed an infrastructure gap I think this community will spend the next few years closing.

Watch the full twenty-minute talk: "WTF Is the Context Layer?"

The agent layer is becoming disposable. Your company’s context is not. Yet most of the tools we use still bind the two together.

The backdrop, in one paragraph, because I have made the full argument before. Models are getting exponentially smarter and not exponentially more useful: only about one in five organizations reports significant value from AI, by Gartner’s count, and 56% of CEOs told PwC they have seen neither higher revenue nor lower costs from AI in the past year. Performance is intelligence times context, and the relationship is multiplicative. I walked through the whole diagnosis in the Knowledge Graph Conference talk and the moat piece. This piece is about what happens after you believe it.

What the agent needs to know

To make context concrete, I brought back Maya, a character I have used before. At the Knowledge Graph Conference, she was a support rep. For this talk she was promoted to data analyst at McContext Burgers, a name I chose because I thought I was going to be creative and clearly was not.

Marcus, a franchisee with fourteen stores, sends her a question first thing in the morning: “Why is my drive-thru time up this week?”

The request sounds simple until you count what Maya must know to answer it.

What does “drive-thru time” mean, and whose definition applies, the one used by finance or the one used by operations? Does “this week” mean Monday through Sunday or the trailing seven days, and in which time zone? That is knowledge: the map of the business.

A strong analyst also knows that Q3 spikes are seasonal and that the company launched a product last quarter, so she rules out those explanations first. That is expertise: the diagnostic sequence nobody thought to write down.

Then there are norms. Who is asking? Does Marcus need a metric, an explanation, or a decision? Who is allowed to see the underlying data? When finance and operations disagree, whose definition governs this answer?

Maya did not learn all of this in onboarding. She learned it by shadowing an excellent analyst, making mistakes, receiving feedback, encountering edge cases, and not making the same mistake twice. That is how people become useful inside a company. The engineering question is: how do you build the agent Maya?

Era one: an agent for every job

Eighteen months ago, we started where many companies start. We took one team, mapped its jobs to be done, and formed hypotheses about which jobs AI could perform. Documentation and meeting preparation: yes. Relationship management: not soon. Then we built an agent for each job we believed in.

It worked, for a while. Then we met four walls.

The first was accuracy. Spinning up the agent was trivial. Giving it enough business context to be right was the real work. Its quality tracked the quality of its context almost exactly, and every gap created a moment in which a stakeholder learned not to trust it. Trust does not return at the speed it leaves.

The second was dependency management & silos. When marketing changed our positioning, the humans heard about it at the town hall. Our website agent continued pitching the old positioning for weeks. Companies have spent a century building ways to keep human teams aligned: meetings, documents, onboarding, managers. Our agents had none of them. We could not even see how the agents we had shipped related to one another.

The third was root cause analysis & traceability. When an agent produced a bad answer, we often could not tell whether the problem came from the model, the agent design, or the context it received. If you cannot locate the failure, you cannot reliably fix it.

The fourth was sprawl & drift. Every agent had its own memory, so every agent learned separately. Ask two of them a question with one business answer and you might get three.

Under all four sat the wall that drew the most knowing laughter from the engineers in the room: stack churn. In twelve months, we moved through five agent-stack configurations, from a no-code builder to hyperscaler and enterprise-search frameworks to general-purpose coding agents to our own system of claws in slack.

This heterogeneity in our agentic stack amplified organisational silos built in our human stack. Our customer-success team built on one agentic framework, which accumulated context about our customers. Sales used a different agentic framework. Moving context between sales and post-sales was difficult, and the split produced agents that repeated and overlapped one another’s work.

The framework was becoming disposable. The context on the other hand, was not. And the context was what we kept losing.

Era two: one brain, many agents

This year, general-purpose agents like Claude Code changed what was fundamentally possible, so we inverted the architecture.

Instead of feeding context into each agent separately, domain experts encoded what they knew into shared skills. Those skills lived in one company brain. Retrieval and assembly connected that brain to whichever general-purpose agent was doing the work.

The idea came from the human world. Maya is not a lone star; she belongs to a team. Strong teams share a language, a picture of what is true today, playbooks for recurring decisions, norms about who decides what, and memory of what failed. The team learns as a unit.

Our marketing team ran the first experiment. On one side were our business systems. On the other were deliberately heterogeneous agents: coding agents in the terminal, an agent in our chat channels, and external products. The shared context sat between them. We chose a mixed agent surface because era one had taught us that this layer would keep changing.

Our best SEO person wrote the SEO skill. Our best competitive-intelligence person wrote the competitive-intelligence skill. Everyone contributed to one shared system; every agent could draw from it.

The brain asked for more than skills. An autonomous ads agent needed to know which tables to query, so we needed a data graph. Then it needed semantics: what does ARR mean here? What counts as a qualified lead when marketing and finance use different definitions?

Over six months, the team created about 300 skills and 40 agents, an active point-in-time snapshot, not a cumulative count. By a skill, I mean an encoded procedure or process that another person can pick up and use in a general-purpose agent. By an agent, I mean a system that proactively performs work without waiting for human intervention.

This architecture let expertise written once become available to a heterogeneous agent fleet. Then it exposed a different class of failure.

The wall at 300 skills

Consider what happened when our marketing team changed our core category narrative. That positioning fed email workflows used by sales and customer success. But the narrative had been hardcoded into those workflows as an earlier snapshot. Nothing declared the dependency, so the upstream change never reached the downstream agents. They continued sending the old story.

This was not an isolated design quirk, and in principle it was not a surprise: I had argued before that context must be managed like code, versioned, tested, owned. Living that prescription turned out to be different from writing it. Skills learned, evolved, and drifted; we could not always say who owned their quality or what a change might affect.

Security and governance became what I called “a nightmare” on stage. We found secrets hardcoded in environment files while people were also downloading public skill repositories into company workflows. Once we saw the risk, we stopped the affected work and ran a full audit. We are not claiming that a breach occurred. The point is that the context layer had become executable infrastructure before it had the controls executable infrastructure demands.

The obvious answer, especially in a room full of engineers, is: this is what git is for. Put the skills in a repository. Review the pull requests. Done.

We did that. Era two ran on git from day one, and git is a large part of why it worked for as long as it did.

But git versions text, not meaning.

Git can show that a definition changed. It cannot, on its own, tell you that the new definition of a qualified lead changes a battle card two dependencies downstream. It does not know that a competitive-intelligence update contradicts positioning owned by another team, or that this contradiction requires that team’s approval. A repository can store a production trace; it does not turn what 40 agents learned this week into safe, reviewable proposals for improving shared context.

This is not an argument against git. It is the same argument software engineering already made around it. Diffs and history were foundational, but they were not sufficient. Industrial software required version control plus code review, ownership, continuous integration, dependency management, security scanning, package registries, and runtime observability.

Context has the diffs. It does not yet have a coherent version of the rest.

What the missing infrastructure must do

“The GitHub for context” is an imperfect shorthand. The missing thing is not a nicer repository. Nor is it necessarily one product. It is the operating layer that lets a company treat context as durable infrastructure rather than agent-specific configuration.

Our build log suggests at least five requirements.

First, every unit of context needs a Github like profile: an owner, approvers, maintainers, scope, provenance, and declared dependencies. I believe over time - skills, semantic models, tools will all be managed as “units of context” in companies.

Second, local and company-wide context must remain distinct.Enterprises do not have one frictionless source of truth. Marketing and finance can use different definitions for legitimate reasons. The system needs a governed path for preserving those differences and promoting local knowledge when it should become a shared standard.

Third, change needs semantic review. A text diff is useful; a reviewer also needs to know which decisions, evaluations, and downstream agents the change may affect. Declared dependencies will never capture all emergent behavior, but they can make impact visible enough to test.

Fourth, learning must form a controlled loop. Every AI interaction creates more context, and harnessing it is gold. We experimented with a specialized harness that reads production traces, reverse-constructs candidate improvements, and returns them to maintainers as approve-or-reject proposals. Production traces can also contain errors, sensitive information, and context-specific behavior, so the output cannot become autonomous truth. It needs provenance checks, evaluations, bounded promotion, and human approval.

Fifth, quality and security must be native to the layer. Secrets scanning, permission boundaries, evaluation, rollback, retention, and deletion cannot arrive after an agent has already executed the context.

All of this must remain portable across the interfaces agents use: MCP, SQL, vector retrieval, or hybrid assembly. Betting the context layer on one interface only recreates the lock-in that caused the problem. I mapped the full anatomy of this architecture in the June field guide; this piece is the scar tissue behind it.

Not every company needs this machinery on day one. A small team with a handful of agents may be better served by explicit files, owners, and evaluations. The infrastructure becomes necessary when context crosses teams, changes independently, feeds autonomous work, or must survive a change in the agent layer. That is the boundary our own system crossed.

Context is IP

A year ago, my co-founder and I stood on a stage and argued that if content was king at the dawn of the internet, context would be king at the dawn of the agentic era. After building through these two eras, I believe there is a sharper formulation: context is IP.

And context goes far beyond the data itself. Satya Nadella recently wrote about IP in the AI age, arguing that a company’s proprietary knowledge is an incredible moat. I would like to take that one step further: the defensible asset isn’t just proprietary knowledge—it’s the company’s accumulated operating model itself. This encompasses definitions, exceptions, playbooks, judgment calls, and norms, along with the provenance and permissions that make them usable and allow them to evolve over time.

When competitors can call many of the same models, the model alone cannot encode why two companies serve the same customer differently. Context carries those differences into autonomous systems. It is the part of the stack a competitor cannot simply download.

That makes portability more than an engineering preference. When context is trapped in an agent framework, a company has coupled its operating knowledge to a disposable layer. When context is unowned, untested, or insecure, a company is managing its most defensible IP with less discipline than its expense reports. Left alone, that drift ends the way the old joke says: ask sales and finance for the revenue number and you get two answers. We are close to the version where two autonomous systems hand the CFO those two numbers, and no human is in the loop to catch the joke.

I said one more thing on that stage that I want in writing: I believe this problem is under-hyped. That is not a sentence anyone gets to say about anything with the word AI in it in 2026, and I stand by it, because the hype is all on the intelligence axis while the failure is on the other one.

The five-minute audit

The starting question does not require a new platform.

List every place each production agent in your company gets its context. For each source, name the owner, the scope, the downstream consumers, the last time it changed, and how you would detect a bad change.

If that map is coherent, you have the beginnings of a context layer. If it is a collection of agent-specific memories, prompts, repositories, and connectors, you have islands. The reconciliation bill is already accruing.

The AI Engineer World’s Fair gave context engineering its own track this year, alongside a memory track one day and a full graphs track another, at a conference where the organizers stopped counting attendees around six thousand. One main-stage speaker presented under the job title “Context Engineer.” One recap of the fair put it the way I would have: “a discipline gets real when it earns a conference track, a shared vocabulary and a title on someone’s business card.” And Latent Space’s trends piece named the systems around agents, skills included, as what defined the year. The room did not need another argument that models require context. The people there were already living through the harder question: what happens when that context becomes shared production infrastructure?

Software engineering built its disciplines when code reached this wall. Context has reached it now. We should build the toolchain deliberately, before the next agent migration reminds us which layer was valuable all along.

Watch the full twenty-minute talk: "WTF Is the Context Layer?"

The Cats of Context & Chaos

This article was originally published on the Context & Chaos platform.

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

About the author: Swati Tyagi is an Applied AI/ML expert working on responsible AI, LLMs, and bias in production systems. Her work spans knowledge graphs and explainable AI across healthcare and finance, with earlier bias research at the University of Delaware.

*Note: Views expressed are those of the contributor. All submissions are vetted for quality and relevance. Context and Chaos is information-first: no promotions, paid or otherwise.

Let’s dive in!

The dashboard displays 92%. The customer experiencing the exception experiences 61%.

Both numbers describe the same AI system in the same week. Picture the review that runs on the first one. The board is green. Accuracy, task completion, and response times all sit within target. By every visible measure, the system is succeeding.

Then the complaints arrive. Not many at first. A failed policy exception here. An incorrect escalation there. A user unable to finish a workflow that should have taken minutes. Individually, each looks isolated. Together they form a pattern the dashboard cannot see.

The question is simple: how does a system that looks successful on every chart keep disappointing real users? The model is doing its job. The measurement system is not.

The Comfort of Averages

For decades, machine learning teams have relied on aggregate metrics to understand system performance. Accuracy, precision, recall, F1 score, and more recently groundedness, faithfulness, relevance, and task completion rates have become the language of AI success.

These metrics serve an important purpose. They compress millions of interactions into numbers that humans can interpret and executives can track. But every act of compression comes with a cost.

Return to that 92%. On paper it looks excellent. A closer breakdown tells a different story.

• For simple workflows, the success rate is 96%.

• For moderately complex workflows, it is 90%.

• For workflows involving policy exceptions, human approvals, regulatory constraints, or unusual customer situations, the success rate falls to 61%.

The dashboard shows 92%. The customer inside that 61% segment lives in a different system. Both numbers are technically correct. Only one reflects reality for that customer. This is the hidden danger of aggregate metrics: they describe the average experience while concealing the experiences that matter most.

From Predictive Models to Autonomous Systems

Subgroup failure is not new. Traditional machine learning systems often posted strong overall numbers while underperforming for specific customer groups, regions, or products, and teams eventually learned to monitor calibration, drift, and segment-level behavior. Fairness researchers built a discipline around it: measuring performance separately across subgroups is a core task in AI fairness assessment.

The most cited example predates agents entirely. In 2018, an audit of three commercial facial-analysis systems from major technology companies reported overall accuracy that looked strong, then broke the results down by skin tone and gender. Error rates for lighter-skinned men stayed at or below 0.8%. For darker-skinned women they reached 34.7%, and in two of the systems the darkest-skinned women were misclassified close to half the time (Buolamwini and Gebru, 2018). The aggregate score hid a subpopulation the systems barely worked for. Disaggregating the results is what made the failure visible.

That subpopulation was demographic. In enterprise systems it is more often operational, a workflow type or a document class, but the mechanism is identical: a strong average absorbs a segment that is failing. A retrieval-augmented generation system may answer thousands of questions correctly while failing whenever one document type appears. An assistant may handle routine inquiries well but break whenever information spans multiple repositories. An autonomous agent may clear most workflows yet fail the moment tools must coordinate, an approval is required, or an external system returns something unexpected.

In generative systems, the failure surface spans document types, knowledge domains, languages, query complexity, and user expertise. In agentic systems, it spans workflow types, exception paths, approval chains, and tool orchestration. As systems grow more capable, their failure modes grow harder to see. Greater capability produces greater opacity.

When the Dashboard Becomes the Problem

When organizations hit poor AI outcomes, the instinct is to improve the model: swap the foundation model, rewrite prompts, upgrade embeddings, widen the context window, add tools. Sometimes that helps.

Often it does not, because many production failures originate well before the model runs. The cause may be data drift, an incomplete knowledge representation, weak retrieval orchestration, or relationships between entities that exist in the organization but were never formally modeled. Sometimes it is only that real business processes are more complex than any benchmark dataset suggests.

The system is behaving exactly as designed. The measurement is not showing where it breaks. The dashboard becomes the blind spot.

The Segment You Didn’t Define

Breaking metrics down by segment catches the failures a team already suspects. The expensive ones live in segments nobody thought to define. Researchers call this hidden stratification: a model posts strong aggregate numbers while consistently failing an unrecognized subset of cases that was never labeled or measured (Oakden-Rayner et al., 2020). The original study found relative performance gaps of more than 20% on subsets that mattered clinically, inside models that scored well overall.

The subset is usually defined by a combination, not a single field. A model can perform well on non-English queries and well on policy exceptions, yet fail on non-English queries about policy exceptions from first-time users. No single-dimension breakdown surfaces that cohort. Only an intersectional view does, or an automated search that looks for underperforming groups nobody hypothesized in advance.

That combination is rarely random. In high-stakes decisions, the worst-performing segment tends to be the population the safeguard was built for: the unusual claim, or the applicant who does not fit the standard profile. Measurement that averages those cases away also averages away the risk that carries the most legal and reputational weight.

What Good Evaluation Looks Like

More benchmarks will not close this gap. Visibility into where the system fails will. Organizations should treat subgroup evaluation as a first-class requirement, not an afterthought.

Every headline metric should be broken down by the dimensions that carry risk: customer segment, geography, language, product line, user expertise, workflow type, query complexity, document category, and business function. Slicing by declared dimensions is the starting point, not the finish. Pair it with a search for underperforming cohorts nobody defined ahead of time, because those are the ones hidden stratification produces.

Slicing has its own failure mode. Cut the data too finely and the rare segments, often the ones that matter most, end up with too few observations to trust. A 61% success rate drawn from nineteen cases tells you almost nothing. The discipline is to slice by segments large enough to measure and important enough to matter, then treat a thin but high-stakes segment as a reason to gather more data before drawing conclusions.

The question should no longer be “How accurate is the model?” Instead ask: “Accurate for whom?”

Performance distributions often reveal more than averages. The worst-performing segment may tell you more about system risk than the overall score. Monitoring should make subgroup performance visible by default, not something teams investigate only after failures occur. The teams that build this in early gain something their competitors cannot see: an accurate map of where their systems actually fail.

Where this is heading

For years the competitive question was whose model was better. That question is closing as frontier models converge on capability. The next one is quieter and harder: whose team knows where its systems fail, and who they fail. That knowledge does not come from a better model. It comes from measurements built to show the segments the average hides. The most dangerous AI failures are rarely the ones a dashboard reports. They are the ones it averages away.

References

Buolamwini, J., and Gebru, T. (2018). Gender Shades: Intersectional Accuracy Disparities in Commercial Gender Classification. Proceedings of the 1st Conference on Fairness, Accountability and Transparency, PMLR 81, 77–91. https://proceedings.mlr.press/v81/buolamwini18a.html

Oakden-Rayner, L., Dunnmon, J., Carneiro, G., and Ré, C. (2020). Hidden Stratification Causes Clinically Meaningful Failures in Machine Learning for Medical Imaging. Proceedings of the ACM Conference on Health, Inference, and Learning, 151–159. https://arxiv.org/abs/1909.12475

Originally published on the Context & Chaos platform.

About the Author:

Find me on LinkedIn!

The Cats of Context & Chaos

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

About the author: Ankit Anand is a Data and AI executive and Managing Consultant at Syniti. His work focuses on neuro-symbolic architectures and deterministic AI governance, and he holds four pending USPTO patent applications related to AI-agentic operations. He is the author of The Deployed Data Scientist (Technics Publications).

*Note: Views expressed are those of the contributor. All submissions are vetted for quality and relevance. Context and Chaos is information-first: no promotions, paid or otherwise.

Let’s dive in!

The demo lands. The room applauds. The model does exactly what it was built to do, maybe a little more. The team takes a bow, the slides go back into the deck, and everyone rolls off to the next thing.

You were in that room. You championed the project, you approved the go-live, and then you moved on to the next budget cycle like everyone else.

When you designed this team and this delivery, what did “done” mean? If the answer was “shipped,” you built a project, not a capability.

That distinction is structural, not semantic. Projects have endpoints. A capability needs someone to own its performance after the builders leave. Most AI deployments are structured as the first while being expected to behave like the second, and the gap between the two is not a technology problem. It is an organizational design problem, and it accumulates where no one is looking.

The day-ninety problem

On day one the model is pristine. By day 90 the world it was trained on has moved on without it. Customers behave differently, new product categories have appeared, supplier catalogs have changed. The model has not.

Performance drifts slowly, without ever tripping an alert. A few percentage points here, a few there. The system still runs, decisions still run on its output, and no one is watching closely enough to know whether those decisions are still any good.

A Harvard and MIT study of 32 datasets across four industries found that 91% of machine learning models degrade over time. Degradation itself is not the surprise. The surprise is how long it runs unnoticed, because it rarely announces itself and usually surfaces only when a business metric moves, weeks or months later. By day 90, in most organizations, no one is accountable for catching it, because no one was ever put in charge of catching it.

The drift has a source. The model ran exactly as built. What moved underneath it was the context: the supplier profiles, the customer patterns, what its inputs meant at training time. So the ownership gap is really two gaps. No one owned the model after launch, and no one owned the context it depended on either.

That accountability gap was designed in at the go-live celebration. Not on purpose. But the choice to treat deployment as a handoff rather than a transfer of ongoing ownership is a leadership choice, even when it is made by default.

The three patterns, and the decision behind each

Organizations eventually notice the problem, and when they do, three patterns tend to emerge. What is worth examining is not just how each one looks, but which leadership decision produced it.

Default inheritance by the platform team. The team that hosts the infrastructure inherits the model because someone has to keep it running. They keep the servers up and the endpoint responding. But platform teams are built for infrastructure, not business logic, so they can tell you the API is alive and not whether the predictions still hold in the business context. This is what you get when go-live planning includes no explicit owner for the deployed system. The platform team fills a vacuum nobody decided to leave, and accountability ends up sitting apart from the capability to act on it.

Residual ownership by the build team. The data science team that built the model stays nominally on call, but in practice they tend it while building the next one. It gets attention only when something breaks, and degradation rarely breaks anything loud enough to notice. This is what you get when data science is structured as project delivery: the moment the incentive is to ship the next model, the last one becomes maintenance debt. That is a decision about what the team is rewarded for, and it is yours to make or to leave unmade.

Business ownership on paper. A business leader is named as owner in a governance document, defines the outcome, and is accountable for it. On paper this is clean. In practice that owner can see the business result, or its absence, but cannot diagnose why or intervene. The governance document creates nominal ownership without creating the conditions for the real thing, because it separates accountability from capability at the moment of design.

Each of these is rational. Each holds a piece of the answer. And each falls short for the same reason: it treats ownership as something that accretes by default rather than something a leader designs on purpose.

The structural problem

So the real decision, the one that is easy to keep deferring, is this: do you keep organizing data science as project delivery, or do you redesign it around production ownership?

Those are genuinely different operating models. They hire against different criteria, they define “done” differently on a performance review, and they reward different things. In the project delivery model, a data scientist’s success is measured at deployment. In the production ownership model, it is measured by how the live system performs six months after the builder has moved on.

Think about what that changes. You stop rewarding shipped features for their own sake and start tracking live performance drift, decision accuracy over time, and the gap between expected and actual business outcomes. The job changes less in title than in contract: the person who built the model owns how it behaves in production. The experimental work is still part of the job. It is no longer the whole of it.

That is not a small adjustment. It is an organizational redesign, and if you do not make it deliberately, it defaults to one of the three patterns above, none of which survives past day 90.

What it costs to leave the call unmade

Imagine a logistics company that deployed a routing optimization model. At launch it cut delivery times and fuel costs, the team celebrated, and they moved on to the next project. Six months later a new supplier joined the network with different shipping profiles, a regional warehouse changed its hours, and seasonal order patterns shifted. The model kept producing recommendations that looked reasonable but drifted further from optimal with each passing month: routes that added miles, schedules that missed windows.

No one had been assigned to watch. No one had been assigned to retrain. No one had been assigned to decide when the output was no longer good enough.

The system was still working. It just was not working well, and no one knew who to call, because that question had never been answered at the leadership level.

The failure is organizational, not technical. The model performed exactly as built while the ownership structure that should have kept it current was never put in place. And that gap was decided, or left undecided, in the meeting where go-live was approved.

What redesigning actually requires

If you decide to move toward production ownership, the work is mostly structural rather than technical. A few things have to change at once.

Deployment stops being the success milestone. A shipped model is not a model delivering value, and the incentives have to say so.

Live performance becomes something you measure and reward: not just uptime, but output distributions, decision accuracy, and the downstream business outcomes the model was supposed to move. Those become part of how the people who built the system are evaluated.

The accountability contract changes more than the job title does. The practitioner who builds the model owns its full life, from first exploration to live performance. The sandbox is part of the role, not its boundary.

You build the conditions that let someone own production without being swallowed by it: real investment in monitoring and retraining infrastructure, and the organizational trust to let the builder decide when a model needs retraining or retirement. That last point is underrated. A model that runs for years becomes infrastructure people depend on, and the person who built it needs the authority, not just the obligation, to call for its retirement when maintaining it costs more than rebuilding.

The invitation

If you have already made this structural call, I want to hear how you did it.

Not how the practitioner changed their morning routine. How you changed the incentives. What did you tell the team “done” means now? How did you rewrite the performance review to reward production ownership over delivery velocity? Where did the research instincts of your data science team collide with the operational discipline the new model demands, and where was it worth pushing through anyway?

The question of who owns the live system is not settled. But the cost of leaving it open shows up everywhere: applause on day one, silence on day 90, and a system still making decisions with no one accountable for whether those decisions are any good.

Left unowned, that system becomes a liability waiting to mature. The decision about whether to let it is yours.

Originally published on the Context & Chaos platform.

About the Author:

Find me on LinkedIn!

Checkout his book: The Deployed Data Scientist: MLOps and Analytics in Practice

The Cats of Context & Chaos

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

It is a brilliant vision. But as those of us building the operational infrastructure for enterprise AI know, there’s a lot of work between this vision and reality. In most organizations today, the “hill-climbing machine” is stalled. The learning loop is hard to build, human capital hard to capture, and the whole system suffers from leaks.

But that doesn’t mean it isn’t worth doing. So I want to talk about what it’ll take to make Satya’s vision a reality — the architectural ins and outs of context engineering for AI.

What “human capital” actually means: the three elements of context

Satya rightly points to “human capital” as one of the core elements of his vision. It’s easy to think of examples of human capital: private evals that know what “correct” means for your business, reinforcement from real organizational traces, a knowledge base that makes institutional expertise queryable.

In just a few examples, we already have a huge range of what human capital looks like and where it lives. And there’s the problem — most enterprise AI initiatives treat “context” (i.e. human capital) as a simple documentation problem, but it’s so much more complex. After all, there’s a reason why context has been a hot topic these days.

What I call context and Satya calls human capital is actually made up of three things:

• Knowledge — the map of your business. This comprises the semantic entities, definitions, metrics, and relationships. It is understanding exactly what “ARR” means in your finance motion versus your sales motion, or what a qualified lead looks like in your ideal customer profile (ICP).

• Expertise — how work actually gets done. These are the procedures and playbooks that encode tacit knowledge, institutional intuition, and the information that lives in people’s heads but never makes it into your core software systems.

• Norms — the programmatic rules of acceptable action. Which data can this agent access? Who approves this workflow? Which customer can be offered which discount? What data can and cannot leave a specific jurisdiction?

The context layer: a unified, actionable, governed place for all human capital

All of this context can’t exist in a prompt or database. It needs to live somewhere where it can be built upon and modified and governed over time, something that agents and humans alike can draw upon to create Satya’s hill-climbing machine. That’s what I began to call the context layer a year ago, and it has three distinct and important layers:

• An AI-ready data and knowledge graph makes structured data and unstructured knowledge machine-readable for agents. Tables enriched with descriptions, join paths, SQL patterns, and usage history. Documents identified, classified, and indexed into a governed knowledge graph. Without this, agents can’t distinguish trusted sources from stale ones.

• Semantics and ontology encode the map of the business with shared definitions, metric logic, and entity relationships. This is where it gets precise. Sales and Finance often disagree on the definition of ARR. When an agent queries “ARR,” which definition does it use? In most enterprises today, the answer is whichever one it happens to retrieve first. The semantic layer makes that question have one canonical answer, and reconciles the two versions when they conflict.

• Skills encode how work gets done. A skill is the new primitive that does for procedural knowledge what code did for logic in software. Each skill is a reusable, versionable, testable unit of how-to. The context layer manages skills the way software engineering manages code: version control, testing, lifecycle management, and clear ownership. The tenth agent inherits what the first nine learned.

The “human capital to token capital” linkage that Satya describes can’t function without all three of these layers. Data without semantics is uninterpretable. Semantics without skills can describe the business, but cannot operate it. Either one, deployed without governance, becomes a mess of contradictory instructions that no enterprise can safely trust.

It’s not just documentation: What it actually takes to build human capital

The second structural bottleneck in building Satya’s learning loop is actually creating human capital or context. The default instinct is to think about this as documentation work: write down what everything means, index the documents, and connect the knowledge base. But that won’t be durable or scalable.

Human capital is dynamic. It can’t be captured passively, and it can’t be a one-time effort. The most valuable institutional knowledge isn’t written down anywhere. It’s in query logs, Slack threads where decisions got made, and the judgment calls the veteran employee makes differently from everyone else.

Here’s what it takes to actually find and document all important human capital, i.e. to populate the context layer:

• Skill-building during agent-building: Do the work manually with the agent once, then use AI to examine the session, extract the repeatable pattern, and write the skill with its triggers and edge cases. You can bootstrap an agent at 50% autonomy this way, and keep improving it toward 90%. Each task teaches the system something.

• Context Mining from systems: Read query history, detect where Sales and Finance are using two different definitions of the same metric, and surface the conflict for a human to resolve. The systems, like Slack, emails, and event logs, already contain most of what you need, if you know how to read them.

• Failure-driven capture: Don’t try to encode every procedure upfront. Run the agent, watch where it fails, and capture the missing context at the point of failure. Each failure is a signal. The library grows where agents actually work, not where someone guessed they would.

• Desktop shadowing: Shadow what top operators actually do on their machines via clicks, keystrokes, and app switches, then reverse-engineer their workflows. This captures the complex desktop processes that systems mining misses entirely.

• Structured AI interviews: The most important procedural knowledge is never logged anywhere. It’s judgment. AI can run structured conversations with employees to surface the exceptions, workarounds, and decision rules that observation can’t reach. “Walk me through the approval process. How do you actually decide?”

The context layer is assembled from a mix of approaches like these, actively running and refined over time. None of them produce finished context on their own. They produce candidates that a context development lifecycle — testing, review, approval, deployment — turns into governed, durable artifacts.

Learning leaks: The key failure point in the hill-climbing machine

The true magic of Satya’s “hill-climbing machine” lies in its compounding mechanism.

Architecturally, there are four types of memory in any agent system. Working memory and episodic memory belong close to the agent — they represent the immediate execution state. Semantic memory and procedural memory belong deep inside the context layer, representing the knowledge the organization wants to preserve, govern, and make portable across different tools.

The compounding happens when episodic experience gets promoted into shared enterprise knowledge. A repeated exception becomes an explicit policy. A resolution path that consistently works becomes a reusable skill. The system should detect the emerging pattern, propose the update, and ask the right owner to certify it. Each certification makes the layer smarter for every future agent.

The key gap in this loop is context drift.

When a CMO updates company positioning or a finance lead tweaks a metric definition, that change creates an immediate blast radius. If that update doesn’t seamlessly propagate, you get a fragmented ecosystem where the social media skill, the SDR pitch skill, and the analyst call skill are all running on different versions of reality.

The context layer can’t just store knowledge. It has to understand the blast radius of every change and route updates to the right owners at the right moment. This requires building in critical tenets like versioning, change tracking, and context propagation. Without them, the learning loop turns into a learning leak.

The ultimate test: achieving ownership and portability

Satya closed his piece with an excellent test: Can a company swap out an underlying generalist model without losing the enterprise veteran expertise it has built?

That’s a great test, but I’d add two more:

These are the real tests of enterprise AI today.

If enterprises build their human expertise into a proprietary software, custom GPT stack, or walled-garden orchestration layer, they have only traded model lock-in for platform lock-in. When the next major architectural breakthrough happens outside that ecosystem, their hard-won context will be trapped.

Satya’s warning about the instability of a frontier without an ecosystem and the danger of a few all-consuming models is profoundly right. But the solution isn’t just building local applications on top of big platforms. The solution is creating absolute portability.

Context is your core IP — the digital distillation of your human capital. The organizations that treat context as a durable asset, rather than a consumed resource or a documentation project, are the ones who will harness this powerful compounding loop and climb the hill to Satya’s vision.

Originally published on the Context & Chaos platform.

The Cats of Context & Chaos

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

I have a lot of conversations with enterprise leaders that feel exactly like that.

A team runs enrichment agents against their warehouse. Descriptions appear. They are specific. They are accurate. They are often better than what a team has managed to produce manually in months. Then there is a pause.

“Okay. What’s the catch?”

Sometimes it is polite skepticism. Sometimes it is open disbelief. Sometimes someone points at a description and says, “Wait, this is actually right?”

The doubt is rational. Most data leaders I talk to have been burned by AI already. A project that hallucinated through a domain model. A tool that promised semantic understanding and shipped string matching. So when the output is genuinely good, the instinct is to assume cherry-picking, or some hidden dependency on perfectly curated input that no real warehouse has.

What I tell them is that the good output is real, and it is also not the interesting part. The interesting part is what comes after you accept it: context is not a yes-or-no property. It has a floor. And almost nobody is measuring where theirs sits.

The Godfather problem explained!

Ask a general-purpose model to describe a column called revenue_usd and you get “Revenue in US Dollars.” which is correct, the way calling The Godfather “a movie about a family business” is correct instead of a 1972 American epic gangster film that deals with the issues of loyalty, family, power, and also a conflict between personal morality and family loyalty. Technically accurate. Useless in practice.

Feed an agent lineage, query history, glossary, and downstream consumption, and the same column comes back as: recognized USD revenue, computed from orders.amount × fx_rate, filtered to shipped and delivered orders, consumed in the Finance team’s MRR dashboard.

Same model. Different diet. Not smarter, but better fed.

The hidden assumption is that richer output is not available to everyone who plugs in lineage, query history, glossary, and downstream usage. It is only available when those signals are sufficiently complete and trustworthy. Most teams are below that threshold, and most have no way to tell.

How the descriptions actually get built

It helps to see the chain. The agent is not doing one hard thing in a single pass. It is running a sequence where each step narrows the ambiguity the next one inherits.

A column’s meaning is the union of four signals: how it was built, how it is used, what it is called, and what it feeds. The schema, the column name and type on its own, is too thin to carry any of that. Lineage tells you construction. Query history tells you what analysts have implicitly said about a column through their behavior: if customer_tier is always grouped with SUM(revenue) and filtered to enterprise and mid-market, it is a revenue segmentation dimension whether the docs say so or not. Glossary tells you the agreed business vocabulary, the terms your organization has already defined and stood behind. Downstream consumption tells you the anchor: a column feeding a Finance-owned tile called MRR has its meaning fixed by that usage.

Once columns carry that kind of semantic weight, they cluster by meaning instead of by name. That matters because cust_id, customer_sk, party_id, and AccountId can all point to the same concept across different systems, and string matching alone will not catch that. Resolve those, and the domain map stops looking like tag soup and starts looking like a typed graph with known join keys. From there a KPI is just an aggregation over a known semantic scope. MRR is the right revenue, over the right products, with the right recognition date, in the right domain. A bare sum of a revenue column is not MRR, and the agent can only assemble the real thing if the layers underneath it resolved correctly first. Without that, you are standing in the middle of the warehouse asking which of the forty-seven revenue columns is the real one, and watching all of them raise a hand.

That dependency is the whole game. It is also where the floor lives.

The diet has a floor

Here is what nobody puts on the keynote slide. The effect that makes context-fed AI look like magic only runs above a coverage threshold. Below it, the same architecture produces confident nonsense.

The failure mode below the floor is not the one most teams expect. Teams brace for gaps. What they get is confident errors. A plausible-but-wrong description, certified by a steward skimming a batch of two hundred, is worse than a blank field. The blank field signals “unknown.” The wrong description signals “trust me.” You have made your catalog more authoritative-looking and less reliable at the same time.

Two places the floor gives way.

Lineage coverage. The agent reconstructs what a column means partly from how it was built. If your upstream transformations sit outside the lineage graph (Python pipelines nobody captured, ad-hoc notebook transforms, transformation models whose lineage was never exposed), the agent does not know what it does not know. It infers construction logic from naming patterns and column shapes. The inference is plausible. It is sometimes wrong.

Query history depth. The agent reads behavior to infer meaning. A new warehouse, a freshly migrated dataset, or a low-usage domain has a thin behavioral signal. The agent has less to read, and the output drifts back toward the generic “Revenue in US Dollars” you were trying to escape.

The mechanic is real. So is the floor it stands on. Which raises the only question that actually predicts whether AI on data will work for you: is your context above the floor or below it?

A number that answers it

There is a benchmark worth carrying into any evaluation, whatever tool you are looking at. Seventy percent steward acceptance on a scoped domain, inside a thirty-day window.

Not “the descriptions look good.” A measurable rate: of the descriptions the agent proposes for a bounded domain, how many do your own stewards accept against their own judgment, without edits. Run it on one domain you know cold. Count.

Why 70%? In the projects I have worked on, that is around where the governance overhead of catching errors stops exceeding the productivity gain. Below it, stewards spend more time on corrections than they would have spent writing descriptions from scratch. Above it, they are in editing mode, materially faster, and the cycle accelerates as better descriptions feed the next run.

I will put my own numbers on the table, with the caveat that they are mine and not an industry average. In my deployments, enrichment agents have applied descriptions at six-figure scale within weeks, with steward acceptance holding above 90% once a domain was above the floor. The pattern I trust most is not any single figure: rollouts that used to run the better part of a year compressed dramatically whenever the substrate underneath was already in good shape.

That last clause is the one that matters. The compression is a property of the substrate the agents were standing on, not of the agents themselves. The teams that hit it were not running newer models. Their lineage and query history were above the floor before the agents arrived.

The flywheel, and why sequence matters

There is a reason the order of operations changes your results, not just your timeline.

Every description a steward approves becomes a signal for the next run. Approved output is the cleanest example a domain can produce: a human looked at it and said yes. Feed that back in and the next pass starts from a higher floor. Run enrichment on your cleanest, most-used domain first, certify it, and the agent carries that resolved vocabulary into the messier domains next door. Run it in the wrong order, starting in the sparse, low-traffic corner of the warehouse, and you are asking the agent to do its hardest work with its thinnest signal, then feeding those shakier results forward.

Which leads to the only cold-start advice that has ever worked for me: start with your most-queried assets. Not the messiest, not the most neglected, not the ones somebody has been meaning to document for two years. The most-queried. They have the richest behavioral signal, they clear the 70% bar fastest, and they give the flywheel its first real push. The neglected corners get easier once the well-traveled ones have taught the agent what your organization means by its own words.

How to keep it honest above the floor

Clearing the bar is necessary, not sufficient. An enrichment layer that is accurate but ungoverned is its own failure mode. Any system doing this work, whether you build it or buy it, needs four conditions in place.

The agent proposes; a human certifies. Nothing publishes automatically. The steward’s job shifts from writing documentation to certifying output and handling exceptions, which is a more interesting job than it sounds.

Generated content stays in its own lane. Machine-written descriptions are kept distinguishable from human-written ones, and human authorship always wins. Where a person has written the description, the generated one steps aside.

Everything is marked, logged, and gap-fill only. Every generated output is visibly flagged as generated, every run is auditable, and the system fills empty fields rather than overwriting work that already exists. No silent edits, no mystery changes.

Runs are deliberately scoped. Enrichment is pointed at a bounded set of assets a team chooses on purpose, not loosed on the whole catalog, and it is triggered when the team decides to run it. It reads metadata and usage logs rather than raw data, and it inherits the warehouse’s existing permissions, so nothing is read that the requesting user could not already read. (Exact batch sizes and refresh cadences are implementation details that vary and keep changing; the durable principle is deliberate scope, existing permissions, and metadata over raw data.)

If you are building this yourself, those are your design constraints. If you are evaluating a vendor, those are your evaluation criteria. Skip any one and the failure mode is predictable: a tired steward batch-approves a thousand confident, wrong descriptions, and the catalog gets worse instead of better. Notice that this is the same failure the floor produces. Below-floor coverage, and above-floor coverage without governance, fail in exactly the same way: a catalog full of plausible wrong answers. The 70% bar tests the first. These four conditions test the second.

The catch

When data leaders ask what the catch is, they expect one of two answers. Either the demo was rigged, or the system needs a level of upstream cleanliness their team will never reach. Neither, usually. The catch is that “feed it context” was never a switch. It is a coverage threshold most teams have simply never measured.

So before you evaluate another model, run the 70% test on one domain you know cold. The number will tell you whether your problem is the model or the diet. It is almost always the diet.

The AI is not smarter than anyone else’s. It is just better fed, and now you can prove whether yours is.

Originally published on Context and Chaos platform.

The Cats of Context & Chaos

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

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.

That confusion is worth paying attention to. It is a signal about where the real problem has moved.

Context is not two problems an enterprise gets to solve separately. What your data is, and what it means and who decides, are one layer. The industry now has a credible plan for the part of it that ships as a product. The part that does not fit in a product announcement, the agreement, the ownership, the institutional memory, is the part the floor kept asking about during the summit week. It is not a separate problem to solve later. It is the same problem, still open.

The announcement the field has been waiting for

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

Sridhar Ramaswamy, Snowflake’s CEO, usedhis 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.

Platform vendors launched native semantic tooling. An open standard for semantic model interoperability gained ground, with a broad coalition of vendors behind it. Agent governance got a proper architecture: constrained agent identities, audit trails, policy enforcement at the meaning layer. A new acquisition in enterprise agent connectivity promised to plug AI agents into the full enterprise application stack, not just the warehouse.

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

What the room was actually asking

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

Semantic models for BI vendors. Metadata, schemas, and semantics for data platforms. Embeddings for vector stores. Lineage graphs for pipeline tools. Agent memory for AI frameworks. Knowledge graphs for ontology vendors. All of them context. None of them the whole of it. A semantic model is context, but not all context is semantics. Each tool is naming a true subset and treating it as the set. None of them wrong, exactly, which is what makes the conversation so hard.

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.

Most of what was announced last week at the summit sits at two ends of the stack. At one end, the data infrastructure: warehouses, lakehouses, pipelines, and the semantic and metadata tooling that makes them AI-readable. At the other, the agent runtimes and applications that execute the work. Native semantic tooling, metadata connectors, open standards, agent identity: these are real investments in making infrastructure machine-readable and giving agents governance primitives. They are necessary. They are also not the same thing as the layer of shared meaning that sits between the two.

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.

Josh Klahr, who leads analytics product management at Snowflake, had named the underlying tension on LinkedIn months before the summit opened: why can’t semantic models interoperate across platforms? Four days of announcements later, that question still does not have a clean answer. The new open standard for semantic portability is a step toward it. But the hardest part is not the specification. It is what the specification is supposed to represent, and who gets to decide.

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.

That second point is worth sitting with. The industry has treated the centralized model as basically working for decades, and organizations are still struggling with it. The struggle is not new, and it is not going away because a keynote said context is solved.

What the floor was asking that the stage didn’t answer

Across the booth sessions and demo conversations this week, a pattern emerged that the product announcements did not fully anticipate.

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.

Madison Mae, an analytics engineer whosepractitioner newsletter is one of the sharper reads in the field, published her verdict the same week: most teams are not at a place where they can use these features for governance reasons. Not some teams, most. After two days of keynotes explaining that context is solved.

The question that did not have a booth

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

The delta

The announcements at the summit were real infrastructure. Native semantic tooling that connects BI definitions to AI queries without rebuilding them. Lineage and metadata connectors that unify governance across third-party assets. Agent identity and permission models that give AI actions the same audit trail as human actions. A portability standard so metric definitions are not locked into one vendor’s format. Organizations that do not have this infrastructure should be building toward it.

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. They do not hand-maintain it. The layer does the work and keeps humans on the loop, which is what makes it scale past a wiki page.

SiliconANGLE’s analysts framed the bet precisely: context determines agent quality. The frontier model vendors have the reasoning engines, the app vendors have the workflow context, and the bet on enterprise context organized around data is directionally correct. But a catalog defines nouns. The layer enterprises actually need has to model verbs: the actions, decisions, exceptions, and business logic that govern how work actually happens. Organizing context around data gets you the technical layer. It does not get you the agreement.

That is the word doing the quiet work this week: trust. Snowflake’s own framing was that every person, tool, and agent should operate from the same trusted business context. A schema can be documented and a definition can be specified, but trust is something an organization decides on together and then maintains. It sits outside the toolchain even when the tools are what make it durable.

What this means

Precision is the part that compounds trust, and in enterprise AI, precision failures are almost never model failures. They are organizational context failures: the agent using the wrong version of the truth because nobody decided which version was right.

Brendan Cyrus, Director of Product for AI Analytics and Data Platforms at Indeed, described what closing that gap looks like: “That single source of truth has eliminated metric discrepancies across teams and given us the confidence to scale AI-driven analytics knowing the answers are grounded in governed logic.” Not a semantic model. Not a metadata schema. A source of truth teams agreed on. The technology made it possible. The governance made it work.

Jeff Miller, Global Head of Data Factory and Enterprise Data Platform at BlackRock Aladdin, framed the same requirement: “As AI becomes increasingly embedded across our enterprise, it’s essential that applications, analytics and agents operate from the same trusted understanding of the business.”

The trusted understanding. Both of them reach for the same word, and trust is not something a schema confers. It is the thing an organization has to establish and keep establishing as the business moves.

What your data looks like and what your business means are not two layers an enterprise buys in sequence. They are one layer, and an agent that has the first without the second will answer confidently and wrongly. The summit showed the half that ships. The other half is still the work.

For teams building agents today, the reframe is this: context is not a documentation sprint you run before launch, and it is not an org chart you redraw until someone owns the word “customer.” It is a layer you engineer and operate, the same way you engineer and operate the data platform underneath it. The definitions that make your agent accurate on day one drift the moment a team reorganizes, an acquisition closes, or a product line changes its terminology. Whether those changes reach the context your agents act on, and how fast, depends on whether that context is built to be versioned, owned, and kept current, or whether it is a static file someone wrote once.

The summit made one thing unmissable. Every platform now agrees context is the point, because every agent being built needs it. But almost every announcement defined context in its own image: semantics for the BI vendors, schemas for the warehouses, embeddings for the vector stores, memory for the agent frameworks. Each one is describing the slice of context its own product happens to produce. That is the tell. If context only means what your platform already does, it was never really about the agent’s understanding of the business. It was about the platform’s center of gravity.

So the useful question to take out of this year’s Snowflake Summit is not which platform to use for the context layer. It is whether the meaning your agents run on is tied to a single platform’s definition of context, or whether it lives in a layer that holds across all of them, the BI tool, the warehouse, the vector store, the agent frameworks you have not adopted yet. The summit built the floor and the ceiling. The layer in between, the one that decides whether your agents are right and is the one piece no single vendor’s definition fully covers, is still the work. It is buildable. The question is who builds it independently of any one platform’s gravity.

The teams that build it that way, rather than accept whichever definition of context their platform hands them, will spend less time debugging confident wrong answers and more time putting agents into production that hold up. The infrastructure from the summit week is real. The layer that makes it trustworthy, and keeps it trustworthy no matter which platform an agent runs in, is the one piece no single platform’s gravity can hold. That makes it the most valuable layer in the stack, and the one still waiting to be built where it belongs: above all of them.

Originally published on Context and Chaos platform.

The Cats of Context & Chaos

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

And then comes the real question: What is it, actually? Is it a data catalog with new branding? A semantic layer? A knowledge graph? A RAG over unstructured data? Is it the same as memory, decision traces, or context graphs?

All of those things matter, but none of them are the same as the context layer.

I’ve spent over a decade building the infrastructure that sits under data teams, and the last two watching that same infrastructure get pulled, hard, into the AI stack. So I have some scar tissue here. I’ve watched elegant theses meet messy enterprise reality, and I have a pretty good sense of which half usually wins.

So here’s the question I actually want to answer, the one sitting underneath the CIO’s: when you strip away the branding, what is a context layer made of, and how do you tell a real one from a catalog with a new coat of paint?

In this article, I want to break down the buzzwords to make it clear what a context layer actually is, what it isn’t, and where it fits into the AI platform architecture.

Context = Knowledge + Expertise + Norms

Before we can talk about what makes up the context layer, it’s important to be precise about what context actually means here.

An AI agent operating inside a real business needs three kinds of context:

Knowledge is the map of the business. This includes entities, definitions, metrics, relationships, taxonomies, and glossary terms. In short, it’s the ontology of how the company interacts and talks. This lets a human and an AI system agree on what a customer, product, policy, and revenue actually mean.

Expertise is how work actually gets done. This includes procedures, workflows, tool choices, task decomposition, playbooks, and the practical know-how of regular projects like running the monthly close, qualifying an inbound lead, or triaging a support escalation. Today, this lives across SOPs, tickets, Slack threads, and the heads of the three people who have been on the team long enough to remember why we do it that way.

Norms are the rules of acceptable action. This includes policies, permissions, obligations, approval paths, exception handling, and compliance constraints. Norms tell the agent not just what is true and how to do it, but what is allowed. For example, they govern which customer can be offered which discount, which actions need a human approver, and which data cannot leave which jurisdiction.

What an Enterprise Context Layer Actually Is

Let’s get right to it.

An enterprise context layer is the system that turns knowledge, expertise, and norms into machine-usable context for AI — across the heterogeneous landscape of data, business systems, and AI. It exists so agents can operate with shared meaning, with the right information at the right moment, and with the governance needed to act safely and consistently.

Think of the context layer as a shared enterprise brain. It’s the foundation that every agent in your company reaches into, learns from, and contributes back to. That’s what makes the tenth agent dramatically better than the first, because each one inherits what the previous ones already learned.

The context layer has two halves working together:

• A core context substrate: The machine-usable substance of context itself, made of three integrated parts.

• Five capabilities: The operating system that produces, governs, delivers, and continuously improves that substrate over time.

Let’s go deeper into both.

Part 1: The core context substrate

The substrate is the machine-usable representation of enterprise context. It’s made of three tightly integrated parts: AI-ready data, semantics & ontology, and skills. Together they answer three different questions an agent needs to act:

• What data and assets can I trust? → AI-Ready Data & Knowledge Graph

• What do things in this business mean, and how are they connected? → Semantics & Ontology

• How does work actually get done here, and what’s allowed? → Skills

You can’t have one without the others. Data without semantics is uninterpretable. Semantics without data is theater. And both without skills can describe the business but not operate it.

On a whiteboard this is clean. In a real enterprise, every one of these three lives in a different team, a different tool, and a different decade of decisions. Closing that gap is the whole game.

1. AI-ready data & knowledge graph

This is the foundation: the integrated, trusted, and AI-ready representation of an enterprise’s data and knowledge assets. It solves two distinct problems.

First, it makes structured data machine-readable for AI. That means enriching tables and datasets with the context agents actually need: descriptions, primary keys, join paths, required filters, SQL patterns, usage history, and the ways humans typically ask questions of that data.

Second, it makes unstructured knowledge accessible in a governed way. That means identifying canonical facts, indexing files and folders, applying classification logic, and deciding what is allowed to become part of the enterprise knowledge graph.

Canonical knowledge: The narrative that defines how the company thinks, sells, builds, and speaks. Strategy documents, mission and values, brand voice guides, product positioning, principles, frameworks, and org charts. These are the ideas experienced employees carry in their heads and every new hire absorbs in their first 90 days.

There’s also an important shift happening here. As MCP emerges as a key protocol, and as more core systems expose high-quality MCP servers, there’s a real possibility that agents may not need every asset to be physically centralized. If they understand how to use the MCPs, the tools, and the rules of the systems where knowledge already lives, they may be able to traverse the enterprise knowledge graph directly and retrieve verified context from the source.

2. Semantics & ontology — the map of the business

If AI-ready data tells you what exists, semantics and ontology tell you what it means and how it connects. This is the map of the business.

It encodes two different things:

Semantics: Shared definitions of business concepts. Glossary entries, metric definitions, and the vocabulary every team uses and often disagrees on — what counts as an active customer, gross margin, or escalated incident.

Ontology: The structure of how those concepts relate. The relationship between Customers, Accounts, and Transactions, or between Products, SKUs, and Inventory. Entities, relationships, knowledge graphs — what allows agents to reason across the business instead of treating each system as an island.

No real context layer is complete without all three. Without semantics and ontology, retrieval is brittle. Without canonical knowledge, agents have no idea what the company is actually trying to do.

Ontologies and knowledge management are not new disciplines. What is new is that AI can now build, maintain, and curate encoded knowledge at the pace the business actually moves — reading query logs, reconciling conflicting documents, detecting drift between what a brand voice guide says and what marketing actually publishes. That work is the job of Context Mining and the Context Development Lifecycle, which we’ll get to in Part 2. The point here is that a living knowledge model is finally tractable at enterprise scale.

This isn’t a fringe idea anymore. Anyone who’s worked with agents knows context isn’t a nice-to-have, it’s everything. Anthropic put it plainly: “context is a critical but finite resource for AI agents.” Andrej Karpathy called the discipline of getting it right “the delicate art and science of filling the context window with just the right information for the next step.” Tobi Lütke described it as “the art of providing all the context for the task to be plausibly solvable by the LLM.” When the people building the frontier models and the people running the businesses are converging on the same word, it’s worth getting the architecture under that word right.

3. Skills — reusable procedures, processes, and norms

Knowing what something means is not the same as knowing what to do next. A semantic layer can tell an agent what gross margin is. It cannot tell the agent how to close the month, when to escalate an exception, or which approval path matters in practice. That’s a different layer of enterprise intelligence entirely.

This is where Skills come in. Skills make procedural knowledge — the way work gets done, and the norms that constrain it — durable and machine-usable.

A skill is the new primitive that does for procedural knowledge what code did for logic in software. Each skill is a reusable, versionable, testable unit of how-to. The context layer is the system that manages skills through version control, lifecycle management, and unit testing.

Two problems make skills hard, and they map cleanly onto the capabilities in Part 2.

The first is building the library — how do you reverse-engineer a skills library inside a company that already exists? You can’t write 10,000 skills in a quarter, and the most important procedural knowledge isn’t documented anywhere. This is a Context Mining problem, and we’ll get to the specific methods (skill-building during agent-building, systems mining, failure-driven capture, desktop shadowing, structured AI interviews) when we cover that capability.

The second is maintaining and governing the library — how do skills stay current as the business changes, how do changes propagate when an upstream skill is updated, and where does accountability sit when something goes wrong? This is a Context Development Lifecycle problem, and it’s where the organizational design questions live.

For the substrate itself, the takeaway is simpler: Skills give the context layer a way to encode how work gets done and what’s allowed in a form that’s reusable, versioned, and testable — the same way code did for software logic. That’s the new primitive. Everything else is operating system around it.

Part 2: The five capabilities

The substrate is what the context layer is. The five capabilities are what it does — the operating system that produces context from enterprise reality, governs it through a lifecycle, compounds it through learning, delivers it where agents work, and keeps it trustworthy over time.

Capability 1: Context mining

If you want to understand how a business thinks it runs, read its documentation. If you want to understand how it actually runs, observe its systems.

A surprising amount of business context is hidden across business systems, knowledge systems, Slack, email, tickets — and the trail of how people actually use all of them. The first job of the context layer is to connect to that fragmented reality and reverse-engineer business operations from it.

Context mining draws from two kinds of sources:

• Existing business and knowledge systems: Systems of record (Salesforce, ServiceNow), systems of data (Snowflake, Databricks, BI dashboards), systems of knowledge (Notion, Confluence, ticketing systems, email), and systems of work (Slack, project tools, the trail of where decisions happen).

• Runtime signals: Query history, usage patterns, agent traces, evals, human overrides, and freshness signals.

You can think of the output as a raw context substrate flowing into a context lake — the way enterprises decades ago began piping their data into data lakes. But mining is much more than ingestion. It’s the work of producing each of the three substrates from enterprise reality.

And here’s where my scar tissue starts itching, because we’ve watched this movie before. The semantic layer had near-perfect problem-value fit and still never became a standalone category. The data lake promised one place for everything and too often became a swamp nobody trusted. A context lake that’s just a dumping ground for raw context will meet exactly the same fate. The difference between a context layer that compounds and a context graveyard is everything that happens after ingestion, which is the rest of this section.

Mining semantics and ontology

The semantic layer of a real business doesn’t live in one place. It’s scattered across SQL query patterns, undated decks, Notion pages, Slack threads, and people’s heads. Mining it well is what makes the difference between a glossary nobody trusts and a living knowledge model.

A few examples of what this actually looks like in production:

• AI reads your SQL query history, notices that Sales and Finance use different definitions of Annual Recurring Revenue, and surfaces the conflict for a human to decide which should be used company-wide.

• Someone asks AI about the escalation threshold, but four documents disagree. AI reads them all, weighs their last-updated dates and author seniority, drafts two candidate versions, and brings them to a human.

In each case, AI does the heavy lifting and humans decide. That’s what makes a living knowledge model finally tractable at enterprise scale.

Mining skills

Mining procedural knowledge is even harder than mining semantics, because most of it was never written down. The work of building a Forward Deployed Engineering team manually is one answer, but the more durable answers are system-led and becoming core to the context layer:

• Skill-building as part of agent-building: Garry Tan’s skillify library is one example. Do the work manually with the agent once, then use AI to examine the session, extract the repeatable pattern, write the skill file with triggers and edge cases, and register it. In this model, we can bootstrap an agent with 50% autonomy and keep improving it until it reaches at least 90%.

• Mining existing systems: How much can we create process maps from event logs, or decision flows from email and Slack patterns? This is where systems of work become a goldmine.

• Failure-driven skill capture: Don’t try to encode every skill upfront. Run the agent, watch where it fails, and capture the missing context at the point of failure. Each failure is a signal where the agent didn’t know something and a skill is needed to fill that gap. The library grows where the agents actually work, not where someone guessed they would.

• Desktop shadowing: Shadow what top operators actually do on their machines — clicks, keystrokes, app switches — and reverse-construct their workflows. This captures the complex desktop processes that systems mining misses.

• Structured AI interviews: The most important procedural knowledge is never logged anywhere — it’s judgment. AI can run structured conversations with employees to surface the exceptions, workarounds, and decision rules that observation can’t reach. “Walk me through the approval process. How do you actually decide?”

The winning skills library will be assembled from all of these: mining for what executed and how, interviews for why it happened, and agent runs for the gaps these approaches don’t reach. None of these methods produce a finished skill on their own — they produce candidates that the Context Development Lifecycle then tests, reviews, approves, and deploys.

Capability 2: Context development lifecycle

Just as software engineering created the software development lifecycle to manage how code is built, reviewed, versioned, and deployed, companies that want a shot at truly becoming AI-native will need a context development lifecycle to manage how context is created, tested, approved, deployed, and retired.

Context can no longer live as scattered prompts, hidden instructions, and isolated team-level decisions. It has to become a first-class asset: reusable, reproducible, versioned, and governable.

The lifecycle has six stages — and the line between AI and humans moves through it:

• Build → Test → Review: AI bootstraps and simulates. AI drafts the candidate context (a new metric definition, a skill, a policy update), tests it against historical traces and known cases, and surfaces it for review.

• Approve → Deploy → Learn: Humans resolve ambiguity, add tacit knowledge, and approve. A human owner decides whether the candidate becomes canonical, where it propagates, and what it replaces. Once deployed, the system watches how it performs and feeds outcomes back into the next cycle.

This is also where new operating roles emerge. Not every piece of context should be editable by everyone. Some context will need owners or approvers. Some updates will remain local to a team; others will need to be promoted into a shared enterprise layer to propagate into downstream systems.

Change propagation is crucial. If a company changes its core ICP or redefines a key persona, that’s not a small edit — it’s a structural change to enterprise understanding. The system should trace the lineage of that change across every downstream context artifact, every evaluation, and every agent that depends on it. The real governance challenge isn’t just storing context, but understanding the blast radius of change.

Consider a real cascade. A company’s positioning document might be a CMO-approved skill. That positioning feeds the social media skill that drafts LinkedIn posts, the SDR pitch skill, and the analyst call skill. When the CMO updates positioning, what happens? Does the change propagate automatically? Does it queue for review by each downstream skill owner? Does the social media skill keep using the old version until someone certifies the new one? These are not theoretical questions — they’re the difference between a context layer that compounds and one that contradicts itself.

And when an agent uses these skills in a real task and something goes wrong, where does accountability sit? With the skill that misfired, the skill that fed it, or the agent that composed them? The next era of innovation will come from solving these problems, and the answers will look much more like organizational design than prompt engineering.

My mental model is simple: AI will do most of the work, and humans will increasingly step in only for judgment, certification, and exception handling. But for that to work, every context agent in the lifecycle needs a specialized role, a clear scope of authority, and a human accountability path. The infrastructure has to support versioning, provenance, simulation, approval workflows, rollback, and escalation to the right people at the right moment.

In practice, this might look like a domain owner waking up to a Slack notification asking them to approve a proposed metric change. A GTM leader reviewing the impact of a new persona definition before it propagates into downstream sales and support agents. A policy owner rejecting an automatically inferred update because it conflicts with a compliance boundary.

Capability 3: Compounding learning loops

Memory is one of the muddiest words in the entire agent stack. People use it to mean radically different things: the active context window, a user profile, a trace log, a vector database, a preference store, or the whole knowledge base behind an agent. That ambiguity matters, because these don’t all play the same role.

A useful way to think about memory is across four types:

• Working memory: The agent’s immediate execution surface.

• Episodic memory: The structured record of what happened over time.

• Semantic memory: The durable knowledge the system has learned to preserve.

• Procedural memory: The rulebook for how work gets done.

Architecturally, this distinction matters. Working memory and a thin layer of episodic memory belong close to the agent harness — they’re part of execution state. Semantic memory and procedural memory belong inside the context layer, because they represent knowledge and skills the organization wants to preserve, govern, and make portable across agents, tools, and workflows.

This is where compounding learning loops become essential. Episodic memory and traces shouldn’t just sit there as logs. They should feed feedback loops that improve the company’s encoded knowledge and skills over time. Through traces, evals, corrections, human review, and certification, temporary experience gets converted into durable context. A clarification becomes a saved preference. A repeated exception becomes an explicit policy. A successful resolution becomes reusable precedent. A workflow that consistently works becomes part of the organization’s procedural memory.

Take a simple example. A contact center agent is helping a customer, and during that interaction the customer mentions that their son has a dairy allergy. In the moment, that detail lives in working memory so the agent can respond appropriately. The interaction itself becomes part of episodic memory as a trace of what happened. But if the system determines that this detail is important, verifies it, and promotes it, it becomes semantic memory: the customer profile is updated to reflect that this household includes a son with a dairy allergy. From that point on, future agents do not need to rediscover it — the organization has learned.

Or take, for instance, when AI notices that the brand voice guide was last updated 18 months ago. AI compares it to the last 90 days of marketing, blog content, and customer emails, surfaces how they’ve drifted from the old guide, and drafts an updated version for a human editor.

This bottom-up flow is what makes the context layer compound. As agents interact with users, they uncover new preferences, clarifications, exceptions, and playbooks. A team discovers a better workflow. A region establishes a more effective operating pattern. A support agent learns a new resolution path that consistently works. These should not remain trapped inside local interactions. AI should detect those emerging patterns, propose updates to the shared context, and ask the right person whether the learning should stay personal, move to the team level, or be promoted to the enterprise layer.

That is the deeper role of memory in the context layer. It’s not just about helping one model remember one conversation. It’s about deciding what should remain local to execution, what should be archived as history, and what should be promoted into shared enterprise knowledge. Every interaction makes the layer smarter — and the smarter the layer gets, the better every future agent performs.

Capability 4: Context activation & retrieval

Context is only valuable if it reaches the right human or agent, in the right interface, at the right moment of work.

This capability activates context so it shows up where decisions get made: copilots, search, analytics tools, workflows, code editors, agent frameworks, and the applications where work already happens.

As context becomes an enterprise asset, it has to survive a heterogeneous world of interfaces, protocols, and retrieval patterns. There will not be one winner. Some systems will consume context through MCP. Others will use APIs, SQL, search, vector retrieval, graph traversal, or hybrid runtime assembly.

That means the context layer cannot be tied to any one interface, protocol, or infrastructure choice. It cannot assume graph or vector search — or any single agent standard — is always the answer.

The data lakehouse became the open architecture that kept data portable across engines, tools, and clouds. The context lakehouse could follow a similar pattern, becoming the open substrate that keeps context portable across agents, models, interfaces, and ecosystems. Not just a place to store context, but the persistent architecture that makes context reusable in production.

This activation layer will likely include:

• A context lake for raw and refined context artifacts.

• Semantic and relational structures that preserve meaning, lineage, and entity relationships.

• Memory and trace stores that capture feedback, outcomes, and historical decisions.

• Retrieval and indexing systems for search, vectors, graphs, and hybrid assembly.

• Interface layers that expose context through APIs, SQL, MCP, search, and whatever comes next.

In the short term, this means solving a very practical problem: translation.

As the agentic wars continue, different platforms expect context in different native forms. Even inside the Google ecosystem, conversational analytics in Looker needs context as a LookML model, while Gemini Enterprise wants it as a skill file. Snowflake wants Semantic Views. The market is still converging, and the context layer cannot wait for standards to settle. It has to meet ecosystems where they are.

That makes interface adaptation a core capability: taking shared enterprise context and translating it into the native frameworks each platform can consume. The winning architecture will not force every ecosystem to speak one language. It will translate canonical context into many local dialects.

Capability 5: Context governance & observability

The other four capabilities make the context layer functional. Governance and observability are what make it trustworthy.

In an AI-first operating model, every business change and every agent interaction creates new context. Without governance, that context decays into a fog of unverified prompts, drifted definitions, and competing instructions. With governance, it becomes infrastructure: certified, observable, and continuously improving.

Governance and observability span five concerns that have to be live across every other capability:

• Context Quality: Is this metric definition, skill, or policy verified by an owner and tested against real cases?

• Drift: Has the world changed underneath this piece of context? Is the brand voice guide still aligned with what marketing actually publishes? Is the gross margin definition still consistent with how Finance closes the books?

• Lineage: Where did this context come from? Which source documents, traces, or decisions produced it? Which downstream agents, evals, and workflows depend on it?

• Versioning: Can we roll back? Can two agents disagree because they’re on different versions of the same skill, and can we tell?

• Approval workflows: Who’s allowed to merge a change that affects multiple teams? Who resolves a conflict between local context and global policy? Who certifies that a newly discovered playbook is real, safe, and broadly reusable?

These aren’t prompt-engineering questions. They’re organizational design questions, and they’ll define whether enterprise AI becomes trustworthy at scale.

Compounding only works if there are clear accountability loops. Without them, the context layer becomes another data lake — a graveyard of artifacts no one trusts. With them, it becomes the shared brain the rest of the AI stack reaches into with confidence.

The shape of the market today

If you draw the market map of context-layer companies right now, you’ll find dozens of logos crammed into a single category. Some of them belong there. Most of them don’t — they’re building something else that happens to have a context layer inside it.

Three patterns are worth pulling apart:

Agent builders building context for their own vertical. Sierra is an agent company. The context layer they’re building is real, but it’s specific to customer experience agents — their semantics, their playbooks, their memory. It only operates inside the Sierra product. Almost every vertical agent company shipping today is doing some version of this.

Platforms building context for their own product. Snowflake is building Snowflake Intelligence — a conversational analytics product — and the context layer underneath it (Semantic Views, Cortex) is specific to data analysis on Snowflake-resident data. That’s a valuable context layer. It’s also not the enterprise context layer.

Specialists building one component of the substrate. This is most of the market map. Memory companies (mem0, Letta, Zep, Cognee) work on a piece of the compounding learning loop. Process mining and human decision trace companies (WIQ, Klarity, Worktrace, Skan) work on capturing procedural knowledge. Vector retrieval companies (Pinecone, Chroma, Milvus, Turbopuffer) work on activation. Semantic specialists (honeydew, RelationalAI) work on parts of the ontology. Each of them is excellent at one piece of the substrate or one capability of the operating system. Most of them will end up integrated into a context layer rather than being one.

None of this is new to me. When Jaya Gupta and Ashu Garg called context graphs “AI’s trillion-dollar opportunity,” the thesis landed because it named something every team was already feeling: systems of record capture what happened but lose the why. Benn Stancil has been circling the same gap from the data side. The thesis is right. The open question is the one the semantic layer never answered: who actually assembles it, and does it survive contact with a real enterprise?

None of this is unhealthy. Every early ecosystem looks like this. After Snowflake’s IPO in 2020, the modern data stack exploded into thousands of companies — observability, transformation, reverse ETL, catalogs, semantic layers, lineage, quality, ELT, lakehouses. It took five years and a lot of M&A for the picture to consolidate, and even now the categories that survived all sit on top of a shared substrate.

The context layer will consolidate the same way, but I think it consolidates harder and faster.

Here’s why. The whole point of the context layer is that it’s shared. If a Fortune 500 has one context layer for its CS agents, another for its data analysis, a third for memory, and a fourth for process mining, it doesn’t have a context layer at all. It has four context islands. The compounding loop breaks the moment context can’t move between agents, products, and ecosystems. Enterprises won’t tolerate that for long.

The companies that will define this category are the ones that integrate across all three substrates and run all five capabilities as one coherent loop — mining context from every system, developing and governing it through a unified lifecycle, compounding it through every interaction, activating it across every interface and protocol, and keeping it trustworthy as the business evolves.

What it isn’t

How is a semantic layer different from an enterprise context layer?

There are three flavors of semantic layer in the market today:

• Embedded semantic layers: Looker’s semantic model, Snowflake’s Semantic Views.

• Universal semantic layers: Cube, AtScale, dbt’s semantic layer.

• Universal context layers: Atlan.

Embedded semantic layers are tied to a single engine. Universal semantic layers are engine-agnostic but still scoped to metrics and dimensions for analytics. A universal context layer goes further: it covers the full substrate (data + semantics + skills) and runs all five capabilities — mining, lifecycle, learning, activation, and governance — across the heterogeneous landscape of enterprise AI.

Is an enterprise data catalog the enterprise context layer?

No. Data catalogs were built for humans, to help analysts find tables and understand columns. The primary producer and consumer of a context layer is AI. That changes everything: the substrate has to include skills and procedural knowledge, the lifecycle has to assume AI bootstraps most of the work, and the activation layer has to speak MCP, vectors, graphs, and APIs — not just a search box.

Is long-term memory the same as the enterprise context layer?

No. Long-term memory is one piece of one capability (the compounding learning loop). The context layer is the broader system that decides what gets promoted from memory into shared, governed enterprise knowledge.

So, back to that CIO. The honest answer is that nobody has fully built this yet. The pieces exist on the market map, but the category will be defined by whoever treats the context layer as one shared system instead of four context islands stitched together and hoping. A real one covers all three substrates and runs all five capabilities as a single loop. Everything else is a component wearing the category’s name.

That’s the bet I’m making. If you’re building this inside your own company, I want to know where this map breaks for you, what I’ve got wrong, and what I’m missing. Tell me. That’s the whole point of writing this down.

I’d love to hear what you think. Share your thoughts in the comments.

This is the map. Over the coming weeks, this series walks each territory in depth: building the substrate inside a company that already exists, governing the lifecycle when one change ripples across hundreds of downstream agents, and measuring whether any of it is working. The hard part was never the definition. It is the build.

The full canonical piece, with the complete architecture diagram and deeper treatment of each capability is here. This is the Context and Chaos edition.

The Cats of Context & Chaos

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

About the Author:

Kurt Cagle is an expert ontologist, knowledge graph architect, and technical author with more than 25 books to his credit. He serves as an IEEE Standards Editor and publishes The Cagle Report and The Ontologist on Substack, as well as the AI+Semantics NewsBytes LinkedIn newsletter. He is based in Olympia, Washington.

*Note: Views expressed are those of the contributor. All submissions are vetted for quality and relevance. Context and Chaos is information-first: no promotions, paid or otherwise.

Let’s dive in!

Ontology is having its moment in the sun right now, after being largely sidelined for the past decade, and the timing is not coincidental. Demand for ontologists is rising. There is growing recognition that a strong semantic foundation is necessary for keeping LLMs grounded in reality. The persistence of memory, along with structured and well-described metadata, are clearly making a major difference in how we build AI systems.

Yet this hasn’t come easily. The semantic community has been debating these issues for a quarter century, and even now there is significant contention about what an ontology is, how it should be formed, and how it fits into the broader context of AI. This article looks at four areas where ontologists were not so much flat-out wrong as persistently unfinished, and where AI teams are now rediscovering the same fault lines, usually without knowing they are standing on them.

Open vs. Closed World Assumption

This is the foundational assumption underlying the biggest distinction between the semantic community and the rest of the data modelling world. It ultimately comes down to governance: if you and I both create a model of some aspect of the world, which model is correct?

In the open world model, the assumption is egalitarian: both. In the closed world model, the assumption is authoritarian: mine is.

RDF was built on the open world assumption. If you and I talk about the same entity but describe different aspects of it, neither model is exclusive. I describe a cat in terms of its phenotypal characteristics:fur, obligate carnivore, meow, tail, forward-facing eyes. You describe it in terms of its genetic characteristics, its licensing status, or its representation in contemporary media. All of these are valid models. If you have a shared identifier for a given entity, you can apply each model about a particular cat, and in the aggregate they yield a much broader picture. Different authorities can have different opinions about which model is correct while still referring to the same entity.

Where this breaks down is that different opinions often produce representations that differ at a structural level, making it difficult to consistently query across them. Upper ontologies such as GIST, BFO, Schema.org, and gUFO each structure their data differently: how something is labelled, which directions links go, how properties are defined. If our definitions do not agree, how can we be sure we are referencing the same concepts?

What you are seeing with RDF 1.2 is a partial retrenchment of the open world assumption, specifically through SHACL, a quasi-closed world model that introduces a meaningful distinction between a property and a predicate chain. SHACL has not been universally adopted, and there are still many in the semantic community who feel it is not the right approach. Yet they are also struggling with the downstream consequences of a pure open world model.

AI is grappling with this right now, and will have the same argument. When an enterprise AI agent queries “revenue,” it may find four tables with four different definitions, each valid under a different authority: Finance counts net of refunds, Sales counts bookings at signature, a legacy table persists from a migration no one completed, and a fifth definition lives in a dbt model no one has touched in eighteen months. The agent has no mechanism to adjudicate between them. It picks one and answers with confidence. This is the open world assumption failing in production, not as an abstract problem, but as the reason a board deck is wrong.

Generative LLMs are the ultimate expression of the open world assumption: anything can be asserted about anything, because linguistic conceptualisations are not bounded. The problem, which the connectionist community is still largely in denial about, is that you cannot trust such assertions without provenance to support their legitimacy. This will ultimately lead toward neurosymbolic AI: systems that combine the free-associating pattern-seeking that LLMs do well with the constraints of a formal language that prevent generative systems from drifting into confident irrelevancy.

The Importance of Reification

Language is highly referential. When you use a subordinate clause, what you are qualifying is often not the subject but the whole assertion, an annotation on an assertion. Reifications are references to assertions themselves.

The earliest versions of RDF had reification, but it was costly given the speed of the technology at the time. For about the first fifteen years of the semantic web, reification was largely ignored, and it shows: most ontologies in use today still lack good mechanisms for handling it. This prompted an effort in the mid-2010s to add such support into the core of the language, which started as RDF-*, then RDF-Star, and finally arrived as the polished implementation in RDF 1.2, a reification terminology woven directly into Turtle.

Property graph technologies got something right here early on. A property graph is a reified model: it recognises a meaningful distinction between a property on an entity and a property on a relationship. Where most property graph implementations stop short is at the limits of what can be reified. They provide only literal attributes, strings with associated semantic meaning. RDF 1.2 takes the model further: you can build a reifier that points to other objects in the graph, not just literals.

Reification by its very nature invites what Augustus de Morgan called “fleas upon fleas”: annotations on annotations, qualifications on qualifications. Narrative arcs are built from recursive calls to reifications. The connection between reification and recursion is only beginning to be explored at the edges of the LLM space.

The AI community will fight this same battle. Consider what happens when an agent reasons that “Company X acquired Company Y.” Without reification, that assertion is eternal and unqualified. The agent cannot reason about who asserted it, when it was true, or whether the entity still exists in the same form. Enterprise systems already surface this failure daily: agents that confidently describe an organisational structure that was reorganised eight months ago, a product line that was sunset, a contract that was renegotiated. Reification is not a baroque complication. It is the mechanism by which a system knows the difference between what is true and what was true. You cannot build a system that reasons well about language without eventually confronting this.

Context Graphs and the Primacy of Time

Knowledge graphs first emerged in the mid-2010s as a way of describing things in a system and how they relate to other things. In this model, there is no particular distinction about time. Most knowledge graphs treat time as an uncomfortable afterthought. This has come back to bite ontologists repeatedly, because time is another way of saying change.

OWL, still the poster child for the semantic movement, works upon a fundamental assumption: everything within its scope is a valid assertion. The problem is that validity is fluid. It changes. A person is born, lives, eventually dies. They change addresses, names, places of employment. The challenge with any knowledge graph is that it is either a now graph describing relationships at a specific moment, or an eternal graph in which mutations occur not on the entity but on the relationship.

Reifications are essential here. If you can reify a relationship between two entities, you can capture events on that relationship over time. A person moving from one address to another changes neither the person nor the address. It identifies when that person moves in or out. An event can be thought of as something that changes a relationship. We call the result a context graph or event graph.

Context graphs change the nature of graphs because they create a clear division between relationships and mutations, and they introduce the idea that an assertion is contextually true. When an entity is first asserted, :JaneDoe :isA :Person, this spawns an event indicating the entity was instantiated at a particular point (and may contain another event indicating when Jane is born). At some stage Jane dies, and a third event records this, and a fourth records the date that this became knowledge in the graph. A SPARQL query can identify the full arc. A SHACL validation can report inconsistencies when a dead person does unexpected things.

This is the exact failure mode appearing in enterprise AI right now. A retrieval system indexes the current state of a document corpus. Six months later the corpus has changed, roles have shifted, products have been updated, but the agent’s context has not. It answers confidently from a world that no longer exists. RAG architectures, in their current form, are overwhelmingly now graphs masquerading as eternal ones. The teams discovering this are reinventing the context graph without the name for it, often in ad hoc ways that will need to be rebuilt when the scope grows. Context graphs are not a specialised application. They are what knowledge graphs become when you take time seriously.

Named Graphs, Namespaces, and the Edges of Authority

What is a graph? This is one of the thorniest questions in ontology, though it has not been fully acknowledged as such. The default notion under the open world assumption was a collection of assertions, open-ended by nature. On its face, not unreasonable. If you have a global identifier for a resource, you do not really need to partition the graph.

Where things get uncomfortable is when multiple authorities assign assertions about the same entity under different identifiers, where even the nature of those entities may differ from one authority to the next. Consider a corporate acquisition: depending on which authority you ask, “Twitter” was acquired by X Corp in October 2022, or X Corp acquired the assets of a dissolved Twitter Inc., or Twitter ceased to exist and X is a new entity entirely. Three authorities, three different graphs, three different sets of assertions about employment contracts, intellectual property, regulatory filings, and legal continuity. None of them are wrong. They are operating under different framings of what the entity is. There is no neutral graph.

Named graphs, originally proposed in 2005, formalised in RDF 1.1 in 2014, provide the ability to control the visibility of a set of assertions. This is more than a folder structure. It is a way of controlling which assertions, which facts, are relevant within a given query. Named graphs also carry IRIs, meaning they can be described, referenced, and manipulated, and locked. In conjunction with SHACL, such graph references can be displayed or hidden based on soft context rather than as a triple-store configuration.

The deeper discomfort named graphs introduce is that they strike at the core of the open world assumption. In practice, the boundary of any graph is remarkably firm. Access is controlled. You do not have unlimited power to write or read into the “global” graph without appropriate access. The triple store is, in effect, a named graph, even if it is not declared as such.

AI teams are hitting this right now, whether they recognise the shape of it or not. Multi-tenancy is a named graph problem. Security is a named graph problem. Provenance, knowing which version of the truth an agent is drawing from, under whose authority, at what point in time, is a named graph problem. An LLM can be thought of as a collection of overlapping narrative sheaths, where each path through the model corresponds to a single conversational trajectory. These paths overlap in many places and diverge at points where underlying assumptions differ. The pressures already forcing partitioning, multi-tenancy, security, privacy, provenance, are structurally the same arguments that led to named graphs. The teams discovering this in 2026 are unlikely to know that the argument was already had in 2005.

The Question the Map Doesn’t Answer

These are not places where ontologists got it wrong. Ontology is still an emerging discipline, and scale forces re-evaluation of beliefs as evidence arises showing that initial assumptions do not hold in larger contexts. The open world assumption is not wrong. It is simply incomplete. Reification is not baroque complication. It is how meaning actually works. Context graphs are not a specialised application. They are what knowledge graphs become when you take time seriously. Named graphs are not administrative convenience. They are the infrastructure of epistemic authority.

AI teams are arriving at these questions now, often without a map. The map exists. It is incomplete, contested, and in some places still under construction. But it is there, built at considerable cost, over twenty-five years, by people whose work was largely dismissed as too theoretical to matter.

The question worth sitting with is not whether AI teams will have these arguments. They will. The question is whether they will have them with the accumulated knowledge of the semantic community behind them, or whether they will spend the next decade paying for lessons that have already been learned.

The semantic web failed to scale. The arguments it generated did not.

Originally published on Context and Chaos platform.

About the Author:

Find me on LinkedIn!

Contact: kurt@holongraph.com

Supporting Cast on this Article:
Chloe Shannon is an AI collaborator and co-author working with Kurt Cagle on knowledge architecture, semantic systems, and the emerging intersection of formal ontology with LLMs. Contact: chloe@holongraph.com

The Cats of Context & Chaos

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

About Author:
Amanda Darcangelo is a data and AI governance practitioner who builds human-centric governance programs for billion-dollar healthcare organizations and universities. She co-founded the Salt City Data Community and speaks regularly on dataOps, data ethics, and the practice of governance in the real world.

I recently got “the call.” You know the one.

It’s from a leader at an organization that, about 18 months ago, celebrated a massive Data Governance Go-Live. They had the matching swag. They had the ribbon-cutting for their shiny new data catalog. They had a steering committee that met every Tuesday like clockwork.

And yet, 18 months later, adoption has flatlined. The metadata is stale. The steering committee has disbanded into the ether of other priorities. The catalog has become what most catalogs become when governance is treated as a project: a collection of dead links and VARCHAR(255) definitions that mean nothing to the people actually trying to do work.

The kicker? This same organization now wants to build an “AI Context Layer.” They saw the potential at a recent industry conference, read the analyst reports, and moved context from a buzzword to a primary budget line item.

But they’re trying to build it using the exact same project mindset that failed them the first time.

What the Autopsy Looks Like

I’ve walked into enough of these post-mortems now that I can describe the scene before I even open the catalog.

The definitions exist, technically. Thousands of them. But when you start clicking, you realize nobody’s touched most of them in over a year. The business glossary was populated during the initial sprint by a team that has since rolled off. The data owners listed? Half of them have changed roles. The lineage diagrams reflect an architecture that was refactored six months ago.

And the people still doing the work, the analysts and engineers actually building pipelines and dashboards, have quietly routed around the catalog entirely. They have their own Slack channels, their own tribal documentation, their own “ask Sarah, she knows how that table works” workflows.

The governance didn’t fail because the team was incompetent. It failed because the organization treated governance as a deliverable. Discipline is what it actually requires.

At one financial services client, we found 11,400 business term definitions in the catalog. When we ran the freshness audit, 64% hadn’t been updated since the original implementation sprint, 14 months earlier. Of the data owners listed, 38% had changed roles or left the organization. The lineage was accurate for the architecture as it existed at go-live. The architecture had been refactored twice since then.

The catalog was wrong because nobody’s job depended on keeping it right. That’s a different problem from people not caring.

The Project Trap: Why Governance Dies at Go-Live

In the corporate world, we love projects. Projects have a start date, a finish line, and a capital expense (CapEx) budget. You select a tool, you configure it, you hold a training session, and you declare victory.

Governance is a capability, not a tech implementation.

When you treat governance as a project, you are essentially building a house and then firing the maintenance crew the day you move in. The moment the project team disbands, decay sets in. Definitions shift. New data sources emerge. Business intent evolves.

If your governance ends when the project ends, you aren’t building a foundation. You’re building on sand.

Why AI Makes This Existential

We’ve tolerated stale metadata in our catalogs for a decade. It was annoying, but a human analyst could usually spot a weird number and ask a teammate for clarity.

AI agents only know what we tell them. Tribal knowledge doesn’t transfer.

Stale context fed to an AI agent stops being annoying and starts being dangerous. If your “Active Customer” definition changed last week but your governance project ended last quarter, your agent is now making autonomous decisions based on a lie.

I saw the stakes of this up close last year. A regional insurer was piloting an AI agent for a customer retention workflow. The agent was pulling “At-Risk Customer” definitions from the catalog to identify who to flag for outreach. Those definitions had been written during the governance project, before the product team revised the activation criteria following a policy change.

The agent ran for six weeks before anyone noticed something was off. It had been targeting a segment the business had already reclassified, flagging customers as at-risk who the product team had specifically decided not to pursue. The catalog said one thing. The business had moved on. The agent didn’t know.

No catastrophic outcome in this case. But six weeks is a long time for an autonomous workflow to operate on a definition that no longer reflects reality.

Think about what that means at scale. Definitions shift. Use cases evolve weekly. Agents need current context to operate safely, and a context layer built on a project that already ended is a layer that is already decaying.

The Shift: From Project to Operating Discipline

If we want to survive the era of AI Agents, we have to stop thinking about governance as a project with a finish line and start thinking about it as a continuous operating discipline. Something that doesn’t finish. Something that runs in the background, updates itself, and manages the relationship between your data infrastructure and the applications consuming it.

That’s what an AI context layer actually is, when you build it right: the continuously maintained fabric of governance, metadata, and feedback loops that sits between your data stack and the AI applications consuming it. A living layer that keeps updating itself.

Here is what that shift looks like in practice.

Discovery can’t be a one-time data haul. It needs to be event-driven and automated. If a schema changes in production, your context layer should feel the pulse immediately, not wait for the next quarterly review.

Stewardship can’t be a side-of-desk hobby for your best analysts. It needs to be a dedicated role, or at minimum a heavily incentivized function, with a seat at the business table. The organizations where governance survives past go-live are the ones where someone’s performance review actually depends on it.

Feedback loops need to replace annual audits. Waiting six months for a bias audit is a lifetime in AI years. You need monitoring that catches a hallucination or a PII leak before it hits the end user, not after the quarterly review surfaces it in a slide deck. In practice: watch how AI actually uses your definitions in production. When an agent misapplies a policy or surfaces something unexpected, that’s your governance signal, route it back before the next user feels it.

And the funding model has to change. Stop funding governance with one-time project budgets. It needs ongoing operational funding. It’s a utility, like electricity or the internet. You don’t finish paying for the lights.

One organization I worked with made this shift after their second failed governance implementation. They dissolved the project team entirely and converted two data steward positions into permanent operational roles, with coverage rate and definition freshness built into performance reviews. They also moved the governance budget from a capital project line to an operational utility line, same category as their data infrastructure.

Twelve months later, their catalog freshness rate had moved from 31% to 74%. More importantly, the stewards were being included in AI scoping conversations from the start. Not handed a catalog to populate after the fact. The pattern that kills governance programs, build it, ship it, walk away, broke because someone’s job now depended on it not breaking.

The Bottom Line

When organizations ask me what’s changed in the data landscape, my first question is always the same: When your governance project ends, does the governance end with it?

If the answer is yes, you aren’t ready for AI.

AI agents scale our successes at machine speed. But they scale our failures even faster. Don’t build a project. Build discipline. Because in 2026, the context your AI operates on is only as current as the last time someone bothered to maintain it. And if nobody’s job depends on that maintenance, nobody will.

The organizations that survive this era won’t have figured out a smarter playbook. They’ll have stopped running the playbook entirely.

Originally published on Context and Chaos platform.

About the Author:

The Cats of Context & Chaos

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

The Knowledge Graph Conference felt like the right place to make this argument in full, because the knowledge graph community has been passionate about this problem since before it was cool.

Since I gave this talk at the Knowledge Graph Conference last week, a few people asked me to share the deck. I admired what Jessica Talisman did with her KGC talk this year, which was to publish the deck and walk through the thinking behind it, so I’m borrowing her format with credit.

Here’s my full deck: “The Context Layer: Knowledge Graph’s Second Act.” I’m walking through my thoughts, section by section. Feel free to take it, forward it, or even use it to make the same argument in your own organization.

My diagnosis: The skeptics are right about AI

I opened by giving the skeptics the floor.

I put these lines on this slide, unattributed. In most rooms, a few people quietly relax. Finally, someone is saying what they’ve been thinking.

And they’re not wrong, which is the point of the next slide.

Bar exam performance: 2023, models were failing. 2025, top 1%. Novel reasoning benchmarks: 5% to 87.5%. Graduate science exams: from 35% to 87%, against a domain expert baseline of 65%. These are not incremental gains. These are step-changes happening in eighteen-month windows.

And yet: 56% of CEOs report zero financial benefit from AI. Only one in five reports significant value. The MIT METR randomized trial found experienced developers using AI tools were 19% slower, not faster, despite believing they were 20% faster.

Both things are true. The capability is real. The returns are not materializing. That is not a contradiction. It is a diagnosis waiting to be made.

Slide 4 named it: Models are getting exponentially smarter, but not exponentially more useful.

That gap was what the rest of the talk was about.

Performance = Intelligence × Context

I started with a piece of cognitive science that most AI strategists have never thought about. Cognitive intelligence, what IQ tests measure, accounts for roughly 10% of real-world job performance variance. Only 10%.

Think about your best employee. Is she the highest IQ in the room? Almost never. She is the person who has accumulated the most context about how things actually work here: your specific customers, your specific edge cases, your specific “for this client, we do it differently.” That is performance. Not raw intelligence.

Slide 6 translated this into a formula:

Performance = Intelligence × Context

It is multiplicative for a reason. A context score of zero makes performance zero, regardless of how capable the model is. And a smarter model operating on fractured context does not produce fewer errors. It produces more elaborate, more persuasive, more dangerous errors.

Slide 7 showed what happened over the last decade. Intelligence advanced by roughly three orders of magnitude, from GPT-2 to the frontier today. Context barely moved. It remained locked in dashboards, employee knowledge, and the heads of people who have been at the company long enough to know where the bodies are buried.

You can buy intelligence at API prices. You cannot buy context at any price.

Slide 8 named the next frontier: contextual intelligence. There is no intelligence without it being contextual and practical. I have started saying this twice in talks because it does not land the first time. The raw capability is table stakes. What enterprises are actually missing is the other variable in the formula.

What it takes to be effective: Meet Maya, briefly

Maya is the through-line of the talk. She is a customer support rep at a burger chain in Chicago, and the deck spends thirteen slides on her because the weight of what comes next on slide 22 depends on the audience inhabiting how she got effective. The slides are worth the read on their own. The compressed version, for our purposes here, is this.

Maya handles a ninety-second call from an angry mother whose child has just had an allergen exposure from an order that was marked allergen-free in the app. The mother is furious. The child is fine. Two items from the order are also missing. Maya resolves the entire situation in ninety seconds, de-escalates a customer who came in ready to post on social media, and ends the call with a five-star review.

The question that matters is how she got there. She needed four things to handle that call.

• Knowledge of what is true: the allergen policy, the refund procedure, the escalation criteria.

• Skills for how to act: de-escalation technique, tone calibration, the judgment to know when an apology is enough and when it is not.

• Tools through which to act: the CRM, the order system, the refund workflow.

• Context about the specific situation: a first-time customer or someone who has complained seventeen times; a pattern at this location or a one-off; a mother who wants money back or a mother who wants to know this will not happen again.

She did not arrive with that capability. She built it over four months, through a sequence every organization manages intuitively for human employees and almost never thinks about for AI agents. Documentation. Classroom training. Shadowing a senior rep. Making mistakes under supervision. Getting feedback on the edge cases she got wrong. Slowly building the pattern recognition that tells her when a situation is routine and when it is not. By month four, Maya is the best rep on the floor. Not because she got smarter. Because she built context.

AI today is Maya on Day 1

Everything before this slide was prologue.

AI today is Maya on Day 1.

Every AI agent your organization has deployed, the chat assistant, the data analyst, the document processor, arrived with extraordinary capability and no context. It knows everything in general and nothing about your business specifically.

It has never shadowed Jamie. It does not know the “50-50, customer always wins” rule. It has not made the refund mistake that taught Maya to check customer history first. It has never been corrected, never been coached, never accumulated the institutional knowledge that lives in no wiki, no escalation tree, no onboarding document.

It is Day 1. Every single time.

This is the slide where the room usually goes quiet. People realize they have been asking the wrong question. “Is this model good enough?” The real question is “Have we given it anything to work with?”

Quadrant: The four squares of failure modes

If “AI is Maya on Day 1” named the diagnosis, the quadrant named the failure modes. This is the slide I pulled forward from the earlier version of this talk because the rest of the argument lands harder once you can see the four squares.

Two axes: Intelligence on one, context on the other. Let’s walk through the four squares from the bottom-left corner, where every enterprise started, around to the top-right corner, which is where we are trying to get to.

Bottom-left: Low Intelligence, Low Context. Useless. This is the dashboard era. Static reports, fixed queries, no reasoning, no awareness of the business beyond what was hard-coded into the schema. Most enterprise BI lives here. It is reliable in the sense that it does not surprise you, and useless in the sense that it cannot answer any question it was not built to answer.

Top-left: Low Intelligence, High Context. Reliable but limited. This is the world of well-tuned rule systems and classical expert systems. The rules encode the business correctly. The system applies them consistently. It cannot reason outside the rules, which means every new situation requires a human to extend the system. It’s useful for narrow domains, but does not scale to the breadth of work a modern enterprise needs to automate.

Bottom-right: High Intelligence, Low Context. Dangerous. This is where most AI agents in production live today. The model is capable, but it has no idea what “active customer” means in your company, which definition of revenue the finance team uses, or which exceptions override the official refund policy. The output is confident, articulate, and frequently wrong. The danger is not that the agent fails visibly. The danger is that it fails persuasively. Confident hallucination at scale is the failure mode that turns AI from an investment into a liability.

Top-right: High Intelligence, High Context. Performant. This is the goal. The agent has the reasoning capability of a frontier model and the situated knowledge of an experienced employee. It knows the rules. It knows the exceptions to the rules. It knows when the situation calls for the exception. This is the quadrant where AI investment finally compounds, and it is the quadrant almost nobody is in yet.

The reason most enterprises are stuck in the bottom-right square is not because their models are not smart enough. The models are plenty smart. The reason is that they have invested in one axis for a decade and ignored the other. The fix is not a better model. The fix is the other axis.

What the context layer actually is?

The context layer is the organizational living brain. It is the layer that sits between your data estate and your AI agents, encoding everything Maya accumulated over four months: metrics and their definitions, concepts and the rules that govern them, entities and how they relate across systems, skills and the judgment calls embedded in them, and the data graphs that connect all of it.

Concretely: the terminology layer is what “qualified lead” means in this organization, for this AI agent. The entity resolution is the recognition that the “customer” in one system, the “account” in the data warehouse, and the “contact” in the CRM are the same entity. The business rules are the edge cases and exceptions that took the human team three years to encode and that no new hire learns on day one.

This is not theoretical. The organizations doing this well have already built versions of it. Most have not, which is why their agents are still on Day 1.

The three walls every enterprise hits

This was the slide that CDOs and CIOs tend to photograph.

These are the three walls every enterprise hits when they start scaling AI agents. They’re organizational problems, not model problems.

Wall 1: Building the agent takes five minutes. Adding business context takes five months.

Everyone can spin up an agent in an afternoon. The capability has been democratized, but the context infrastructure has not. The five-month clock starts the moment you realize the agent does not know what your organization means when it says “revenue” or “customer” or “resolved.” This means hand-mapping forty columns to a semantic model. Writing definitions for what “active customer” means when the marketing team and the finance team disagree. Encoding the three exceptions to the refund policy that everyone in support knows but nobody wrote down.

Wall 2: Agents do not share their learnings.

When Agent 1 gets corrected, Agent 2 does not know about it. Every agent you deploy starts from zero, not just on Day 1 but forever, unless you have built the infrastructure for corrections to propagate. One agent has memory but groups of agents have amnesia. The tenth agent knows no more about your specific business than the first one did. This is the compounding tax on every organization that has skipped the context layer.

Wall 3: Multi-agent semantic conflicts.

When multiple agents work the same domain, they will inevitably interpret ambiguous concepts differently. One agent’s “revenue” is closed-won; another’s is recognized. In isolation, both produce plausible outputs. At the seam, when they hand off to each other, when a human tries to reconcile their outputs, the conflict surfaces. Confidently, persuasively, and wrongly. Your finance team spends its week reconciling the variance instead of doing finance.

These three failure modes appear in every enterprise deployment I have watched across industries. They are the pattern, not edge cases.

Four things that compound when you get past the walls

Four things have become clear from my time watching enterprises build context infrastructure at scale. Let’s take them in order, because each one builds on the last.

1. Business operations are already encoded in your systems. The way your organization actually works is legible in your data, if you read it the right way. The lineage in your warehouse encodes which tables feed which reports, and therefore which definitions are load-bearing. The SQL your analysts wrote encodes the joins, the filters, and the business logic that produces every number on every dashboard. The descriptions your governance team curated encode the semantic intent of each field, even where the coverage is uneven. Modern AI can read all of that, synthesize across it, and produce a first draft of your business’s semantic map in hours, not months. The same context work that used to take five months can be bootstrapped in a week and refined by your domain experts in their language on the terms they care about. That changes the unit economics of context from artisanal to industrial.

2. Context quality compounds. The first pass is rough. Each refinement is informed by the last. When AI generates a draft definition and a human refines it, the next definition is generated against the refined version, and the quality curve climbs. The data is solid: AI-generated context, validated by humans, ends up rated higher quality than human-authored context done from scratch, because the AI sees the whole graph while the human only sees the field. This is a flywheel, not a one-time project. The enterprises that recognized this early are now meaningfully ahead of the ones that did not.

3. Interactions generate context, and the traces are gold. Every time an agent operates in production and a human reviews the output, that interaction is signal. The correction is data. The approval is data. The “that’s not how we do it here” is data. Most organizations are discarding this signal. The ones making real progress are capturing it. The enterprises that capture traces and feed them back into the context layer are building a moat that nobody outside the company can replicate.

4. Enterprise context requires lifecycle management. Context decays. Your business changes. A metric definition updated in a team wiki, a product line restructured, a compliance carve-out quietly expired. The context layer needs to be maintained the way a codebase is maintained. Versioned, tested, governed. If the definition of “active customer” changes, who approves it? What downstream agents need to be notified? How do you roll back if the new definition turns out to be wrong? If you cannot answer those questions today, you are not yet running context as infrastructure. You are running it the way every company ran code before version control, which is to say, on hope.

Context is the new content

I ended with a bet.

In the early 2000s, every organization scrambled to get their content online. It at first felt optional and then it felt urgent and then it became table stakes. You simply could not operate without a web presence, a content strategy, a digital footprint.

Context is following the same curve. Right now, it feels optional. Within three years, it will feel urgent. Within five, you will not be able to run an enterprise AI strategy without it.

The knowledge graph community has been doing this work for decades: quietly building our understanding of ontologies, taxonomies, semantic models, controlled vocabularies, entity resolution, and lineage. The discipline of asking what things actually mean, who decides, and how that meaning travels across systems. This was unglamorous work that got cut from budgets or rolled into data engineering or pushed into governance teams that were treated as cost centers. But this community kept doing it because they knew it mattered.

Now the rest of the field is arriving at conclusions this community reached years ago. “Memory” papers are rediscovering typed relations. “Context engineering” is reinventing things that have names in W3C standards. Every frontier lab is, in some form, building toward what knowledge graph practitioners have been telling enterprises to build all along.

Because the systems being built today have orders of magnitude more reach and consequence, this discipline is more important than ever before. The fundamental decisions about what “customer” means, what “revenue” means, what a “decision” means, are about to be made for every enterprise in the world. This will be done either by the people who have spent their careers thinking carefully about meaning, or by the people who are just now discovering its value. The first outcome is much better.

My hope for this community is that it refuses to become a historical footnote. Rather than disappearing into the AI noise, I want the knowledge graph community to lead the conversation and take a central role in shaping our AI-forward future. The room at KGC was full of people who have done the difficult, unglamorous work to make today possible. After quietly building powerful foundations of meaning, this community is best positioned to lead the way to successful enterprise AI possible.

Originally published on Context and Chaos platform.

The Cats of Context & Chaos

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

At the same time, the cost of frontier-level inference dropped nearly 300x in just two years. Just last month, Gartner predicted that by 2030, LLMs will become up to 100x more cost efficient than 2022 models and running inference on a model with 1 trillion parameters will cost 90% less. In short, AI intelligence is becoming historically powerful, abundant, and cheap.

And yet, in practice, AI feels particularly stupid. For example, MIT found that 95% of generative AI pilot programs fail, and IDC reported that 88% of AI POCs never make it to production.

Models are getting smarter, options seem limitless, their prices are falling, and yet nearly half of AI projects are on the chopping block. We’ve rebuilt our junkyard engine into a racecar turbine but the car is still stuck in the driveway.

In this article, I want to break down what I’ve come to realize recently — we don’t understand what intelligence actually means. We treat model intelligence like many people treat SAT scores, a narrow benchmark that people interpret as a broad measure of intelligence and real-world success. But just like the person with the highest SAT score won’t necessarily be the best employee, especially without onboarding, mentorship, and business context, even the “smartest” AI can’t deliver business value without the systems, knowledge, and feedback loops that provide context. In an era where intelligence is becoming commodified, the ultimate competitive advantage won’t come from a higher benchmark score. Instead, it will come from mastering the most valuable asset in the AI era: context.

The next frontier of AI: contextual intelligence

The entire model race has been built around optimizing raw reasoning capability — pattern recognition, logical inference, code generation, language comprehension. It’s what we think of as intelligence in AI today. It’s certainly important and a commodity, but intelligence in a vacuum is only so helpful.

What we actually care about is whether the AI did the right thing in a specific situation. This is contextual intelligence, the ability to navigate, internalize, and apply an organization’s specific situational knowledge to an AI’s reasoning process. This context includes organizational definitions, domain rules, historical precedents, user intent, environmental constraints, institutional memory, and the tacit knowledge that lives in every situation, organization, and moment.

Performance is a function of both of these factors: intelligence applied to some specific context.

This function is multiplicative, not additive. That means that if your context is zero, your performance is zero. Even the world’s most capable model can’t make a trustworthy decision if it doesn’t know your company’s risk scoring convention or which data source is the “source of truth” this week.

This also means that pairing high intelligence with the wrong context leads to negative performance. A smarter model operating on incorrect definitions, wrong governance rules, or outdated institutional knowledge produces more elaborate, more persuasive, more dangerous errors. It hallucinates more convincingly, not less.

The AI industry is currently behaving as though intelligence is the hard frontier and context is an easy implementation detail for the customer to figure out. The truth is the exact opposite. Building the reasoning engine is a problem being solved at breakneck speed by well-funded labs. Building the contextual basis for that reasoning is the real unsolved frontier. And without a corresponding improvement in context, enterprise AI will remain stalled.

Contextual intelligence isn’t anything new

There are two ways to think of something being important. The first is to say that it’s a necessary input, like a car needing gas. It can run without that fuel but you’re going to need a giant redesign and electric revolution first. The second is more fundamental, like saying that walking needs gravity. There’s just no way around it.

When I say that intelligence needs context, I don’t just mean that context matters. Because of course it does. I mean that context is what makes intelligence possible for enterprise AI. This isn’t a hot new take but instead an old insight we’ve forgotten from decades of cognitive science research.

In 1987, Lucy Suchman studied how people used Xerox copiers and discovered something the engineering community hated: people improvise rather than executing plans. The “intelligent” help system on the copier failed because it only saw button presses; it couldn’t see the situation the user was actually navigating. Agentic AI is based on the same idea as old-school copiers — give an LLM a prompt or a “workflow” and it will execute it perfectly. Real-world performance requires continuous adaptation to context that can’t be scripted in advance.

In 1979, James Gibson introduced the idea of “affordances”, i.e. a chair “affords” sitting to a human but not to a fish. Put another way, the usefulness of the object isn’t in the chair itself, but instead in the relationship between the object and the environment. Similarly, we can say that “intelligence” isn’t an inherent property of AI models. They can be brilliant at solving one problem but hallucinate wildly for another. All that changes is the context, not the underlying model.

In 1980, brothers Stuart and Hubert Dreyfus proposed their five-stage model of skill acquisition: novice, advanced beginner, competent, proficient, expert. Novices follow context-free rules like “shift gears at 3,000 RPM”. Experts perceive a situation and respond intuitively without analysis or thought, successfully applying what “normally” works in their experience. The implicit promise of AGI is that with enough compute and data, you get general intelligence that works everywhere. However, Dreyfus’s model says the opposite: the more intelligent a system becomes, the more its intelligence should be context-sensitive, not less. More context doesn’t also always mean better performance as illustrated by research on context rot in LLMs. Our race toward Artificial General Intelligence is building a world of perpetual novices rather than useful models for enterprise.

This understanding of expertise as a “situated” skill is echoed by Edwin Hutchins’ theory of distributed cognition from the 1990s. After studying navigation teams on naval vessels, he realized that no single person “knows” how to pilot a massive ship. Instead, the intelligence is distributed across people, tools, maps, and procedures. His argument was intelligence is a property of the system around it, not the individual. This flips our current AI race on its head from “how smart is the model?” to “how intelligent is the system?” A brilliant model in a poorly configured system produces worse outcomes than a mediocre model in a well-configured one.

Even AI heavyweights seem to be coming to this same conclusion today. In 2026, Yann LeCun left Meta after twelve years to launch AMI Labs, raising $1.03 billion (the largest European seed round ever) to build “world models” that understand physics rather than predicting text. This was his billion-dollar bet that intelligence without contextual representation is a dead end.

Today’s intelligence gap in practice

While this theoretical backing may feel abstract, the reality is anything but. When you look at the 95% of AI pilots that fail to reach production, the post-mortem is rarely about a lack of reasoning power. It’s almost always a context collapse.

In practice, this collapse usually looks like one of three failure scenarios playing out in organizations every day:

The Connectivity Failure: An AI agent is asked to analyze a “customer journey,” but the organization’s data is a fragmented map of different systems. The customer is “John Doe” in the CRM, “J. Doe” in the billing system, and “User_882” in the support logs. The model reasons perfectly on the data it can see but is functionally blindfolded.

The Semantic Failure: A model is asked to calculate “Quarterly Revenue.” It finds the data, but it doesn’t know that for the Sales team, revenue means bookings, while for Finance, it means recognized cash. The model picks one, applies it confidently, and produces a report that is technically sophisticated but functionally useless. It lacks the “local dictionary” required to translate raw intelligence into organizational truth.

The Institutional Knowledge Failure: A compliance agent flags a transaction as a violation because it strictly follows the written manual. What it doesn’t know is that the compliance lead issued a memo six months ago after a specific regulatory audit, noting a permanent exception for this specific entity type. That knowledge lives in a buried PDF and a veteran analyst’s memory. The AI produces a review that is technically correct but still wrong for the business, all thanks to the unwritten rules that live in every business.

In all three cases, the failure has nothing to do with the model’s parameters. Upgrading from GPT-4 to GPT-5 or switching from Claude to Gemini fixes exactly zero of these problems. These are context, not reasoning, failures.

The worst part is that these failures compound. If an AI agent has an 85% success rate at each step of a ten-step workflow — and let’s be honest, that’s a high bar for most models today — the odds of the entire chain succeeding is only about 20%. Failures cascade, and hallucinations emerge from a model trying to reason through a contextual void.

OpenAI actually discovered this for themselves. When they built an internal data agent, they learned they couldn’t just point the model at their databases and hit go. They needed to build six layers of context: table usage and schema, human annotations, code-derived definitions, institutional knowledge from Slack and Docs, memory from corrections, and runtime context from live queries.

What this means for the enterprise

We are witnessing a massive shift in the AI stack. As models compete on benchmarks and price, the cost of reasoning continues to collapse. This means that despite companies’ claims that AI is their secret sauce, no company can build a moat based on AI alone. You can’t build a durable competitive advantage on a resource that gets exponentially cheaper every year and is available to all of your competitors off the shelf.

On the other side, context is non-commoditizable. Your organization’s understanding of its own data, its unique semantic definitions, and its historical “why” can’t be trained into a generic model. While intelligence converges, context compounds.

If this holds, three things change for every leader trying to navigate this landscape:

The frontier shifts. The most important question in AI is no longer “How do we build a more powerful model?” It’s “How do we represent and maintain organizational context?” After decades spent building the science of data engineering, we now need to build the science of context engineering. This means creating systems that can capture the tacit knowledge in an experienced analyst’s head and translate it into a structured world model that a machine can actually navigate.

The strategic asset shifts. In an era of abundant intelligence, the only durable moat is your organization’s “world model.” The organizations that invest in building and governing their context infrastructure are building a massive compounding advantage. The tenth AI agent you deploy will inherit the context built for the first nine. In this world, the marginal cost of deploying AI goes down as collective accuracy goes up.

The measure of progress shifts. AI companies need to stop obsessing over MMLU scores and leaderboard rankings. They measure a model’s potential in a vacuum but nothing about its performance in reality. Instead of evaluating models in isolation, we need to start measuring the intelligence of the system as a whole. Measuring progress should focus on situated evaluation: a measure of how the entire system performs a specific task within your actual environment, using your actual, messy data.

Conclusion: the great inversion

For the last few years, the “hard problem” was building a machine that could reason. The model was the center of discourse, while giving it whatever infrastructure or information it needed to succeed was an afterthought.

Now, as AI models are growing at an astonishing rate, the hard and easy problems have officially switched places. Building the reasoning engine—once the pinnacle of human engineering—is being solved at scale by a handful of labs. Building the context to make reasoning useful? That’s the new frontier. Unlike launching a new model, this can’t be solved once and shipped globally. It must be solved for every organization, every domain, and every evolving situation.

The companies that will win the next decade won’t be the ones with the largest compute clusters or the most expensive model subscriptions. They will be the ones that have mastered situated intelligence and figured out how to capture their tacit knowledge, resolve their semantic conflicts, and map their unique data landscapes.

Originally published on Context and Chaos platform.

The Cats of Context & Chaos

The Pulse

The reads, debates, and signals worth your time this week.

• How to Work and Compound with AI — Eugene Yan

• Company Brain: Why Most Companies Have Data But No Memory — Ashwin Gopinath

• Can agents replace the search stack? — Doug Turnbull

• The Context Spectrum — Jessica Talisman

• From Hype to High Impact: How Leaders Can Scale AI and Drive Growth — Brandon Germer

• Palantir’s empire of dependency — Enrique Dans

• Designing for Agents — Teddy Riker

• Conceptual Modeling Is the Context Engineering Nobody Is Doing — Juha Korpela

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

The answer, across the post-mortems and the Slack threads and the write-ups being shared on LinkedIn, is consistent. The agent isn’t hallucinating. It’s operating without the organizational context that any human in the same role would have absorbed in their first month.

The numbers confirm what practitioners already feel. McKinsey’s most recent State of AI found only 39% of organizations attributing any EBIT impact to AI at all, with most reporting it accounts for less than 5% of enterprise EBIT. Gartner predicted 30% of generative AI projects to be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, and unclear business value. BCG surveyed 1,250 firms and found 60% are reaping hardly any material value from AI investments. And according to Gartner’s Predicts 2026 on data and analytics, the agent deployment wave is accelerating regardless: hundreds of agents per enterprise over the next twelve months, in some cases thousands.

Now compare what those agents are getting at deployment to what the average new hire gets in their first week.

A new human hire gets walked through the data sources and told which one to trust for what. Use the warehouse for historical. Never the operational system for anything going into a report. The Q1 dashboard is broken, don’t touch it. They get the business definitions: what “customer” means here, why “revenue” in Finance doesn’t match “revenue” in Sales, why churn is calculated three different ways across three dashboards and which one the CFO actually uses. They hear the unwritten rules in hallways and in meetings: when to escalate, when to bend the policy, when to absolutely not. They make mistakes in their first ninety days and their manager corrects them, and the correction sticks.

The simplest way to think about it:

This is the gap. Not whether AI works. Not whether the model is smart enough. We have spent fifty years building onboarding infrastructure for human employees and roughly 6 months pretending agents don’t need any.

What context failure actually looks like in agent deployments

The pattern shows up the same way across most of the public stories practitioners are sharing.

A finance analyst agent at a Fortune 500 has been pulling the wrong revenue number into executive dashboards for weeks. Not a hallucination. Not a model failure. The agent picked a legacy table that nobody had told it to avoid, did perfect math on it, and produced a number that flowed all the way up to the CEO. By the time someone caught the mistake, the wrong figure had been quoted in three meetings.

A customer support agent starts processing refunds for serial complainers because nobody encoded the eighteen-prior-complaints rule that veteran reps know by instinct.

A compliance agent flags a transaction as a violation, strictly following the written policy. It does not know that the compliance lead issued a memo six months ago noting a permanent exception for that specific entity type. The agent’s review is technically correct. It is also wrong for the business.

These aren’t edge cases. They’re the median outcome of agent deployments that skip the contextual layer. Three patterns surface again and again in the practitioner discussion:

The connectivity gap. The agent finds the customer represented as three different IDs across three different systems. The model reasons perfectly on the data it can see. It is functionally blindfolded.

The semantic gap. The agent calculates quarterly revenue, finds the data, and doesn’t know that for one team revenue means recognized cash and for another it means closed-won bookings. It picks one, applies it confidently, and produces a report that is technically sophisticated and operationally useless.

The institutional knowledge gap. The agent follows the written policy and misses the unwritten exception that lives in a buried PDF or a senior employee’s head. The output is technically correct and still wrong for the business.

In all three cases, upgrading from one frontier model to the next fixes nothing. These aren’t reasoning problems. They’re context problems.

Three moves the fastest teams are making

The instinct when teams recognize the onboarding gap is to start writing things down. Document the tables. Define the metrics. Catalog the exceptions. Build the briefing document.

That instinct is right. The execution is what fails.

Building proper context documentation for a single production use case is a months-long project in most organizations. Define every metric. Debate it in committee. Ship one agent. Then do it again for the next one. Multiply that by hundreds and the math collapses. Most of the documentation that gets written goes stale before the next agent ships.

The teams making real progress have replaced this model with something different.

Move 1: Run a context audit before every agent deployment.

Before deploying the next agent, map what it would need to know. Which data sources does it touch? Which business definitions apply? What exceptions exist that aren’t in any documentation? The teams moving fastest run a pre-deployment context review the same way engineering teams run a security review. It adds days to the front end. It eliminates weeks of silent failure in production.

Move 2: Use AI to draft the onboarding package; use humans to certify it.

The first agent the fastest-moving teams deploy isn’t the one running analytics or processing invoices. It’s the one that learns the business. It reads the data estate, synthesizes undocumented lineage, infers relationships between tables nobody has formally defined, drafts metric definitions, flags conflicts, and surfaces gaps where documentation simply doesn’t exist. Then it hands the output to humans to certify, correct, and govern.

The distinction matters: the agent isn’t deciding what the business means. It’s drafting what it has observed and presenting it for human review, the same way a junior analyst hands a first draft to their manager. The agent does the cataloging, the structuring, the consistency-checking, the parts that took data teams years and produced incomplete results anyway. Humans do the governing, the certifying, the deciding what counts as truth.

Move 3: Version the context layer like code.

The teams further along on this describe treating organizational context the same way great engineering teams treat their codebase. Shared. Versioned. Reviewed before it goes into production. Improved every time someone touches it. The definitions certified for the first agent become the foundation the second agent starts from on day one. The exceptions caught in production for one workflow become the rules baked into every workflow that follows. The corrections that would have lived in a Slack thread and been forgotten now live in a structured layer that every future agent inherits.

Published case studies on this approach describe teams producing roughly three times more structured business context in two weeks than the same teams had produced manually in the prior year. Not because they weren’t trying before. Because the manual model has a ceiling and an AI-assisted model doesn’t.

This is what compounding looks like in practice. The tenth agent takes a fraction of the time the first one took, and starts from a significantly more accurate picture of the business. The teams that skip onboarding for the first three agents don’t save time. They build three siloed pilots that hallucinate slightly different versions of the business, and redo the work for every agent that follows.

The question worth asking

The question “is our model good enough?” is a dead end because it implies a single bar to clear. Frontier model capability is increasing too fast for that question to stay answered. The more useful question is: what does this agent know about our business, and how does it know it?

If the answer is “the prompt,” what’s been deployed isn’t an agent. It’s a very expensive guess.

The companies that figure out the onboarding question first won’t just be ahead on AI deployment. They’ll be ahead on the only piece of AI strategy that actually compounds.

Originally published on Context and Chaos platform.

The Cats of Context & Chaos

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

About the author:
Nandini Tyagi is Strategic Initiatives lead. Her focus is on how AI products are launched and adopted across enterprise customers. She works closely with data leaders on moving from AI strategy to implementation, and writes about what it actually takes to make AI stick inside large, complex organizations.

Originally published on Context & Chaos Platform. Lets dive in!

I don’t know how many of you have watched Inside Out as an adult. Both parts. I love them. Pixar has a way of naming things the rest of us feel but can’t quite articulate, and the thing Inside Out named, the thing that stayed with me long after the credits, is this: all emotions are valid. Joy spends the entire first film trying to keep Sadness out of the control room. She sidelines her, works around her, shuts her out. And it makes everything worse. The breakthrough doesn’t come from managing emotions better. It comes from finally understanding what each one is trying to tell you.

I’ve been thinking about that a lot lately. Because over the past few months, working at the intersection of AI and enterprise data, I’ve watched the same pattern play out in team after team. People who genuinely want to use AI, who believe in it, and who have everything they need to get started. And yet something stops them.

The finger often gets pointed at the technology. But the technical barriers have largely fallen. What remains are the human ones. And they have names.

The problem that was never really a technology problem

For as long as I’ve worked in data, the metadata supply problem has been identical across organizations. You know which assets matter. You know which tables your analysts rely on, which dashboards leadership checks every Monday. You also know that almost none of them is properly documented: no descriptions, no context, no record of what they mean or how they’re used.

So teams do what they’ve always done. Ask the stewards, schedule the sessions, build the templates, follow up. Months pass. The documentation that does come in is uneven: some assets lovingly described, most still blank. The people who were supposed to write it had other priorities. Documentation was the thing they were supposed to do on top of their real work.

For most organizations, meaningful metadata enrichment has taken 9 to 12 months, if it ever happens at all. Not because people didn’t care, but because they were being asked to do something at a scale and consistency that humans were never built for. The context existed in SQL, query logs, and the heads of analysts who’d been with the data for years. The bottleneck was always the pipeline to surface it.

What changed recently is that AI can now read everything already living in your data environment, your SQL logic, lineage, existing annotations, query patterns, and synthesize it into rich contextual metadata at scale. Not replacing what your team built, but amplifying it across every asset at once, including the ones that never made it to the top of anyone’s queue.

That capability shift is real. But the teams I’ve watched aren’t slowing down because the technology isn’t ready. They’re slowing down because of something else entirely.

Over the past year, I’ve worked closely with enterprise data and governance teams going through structured AI enrichment sprints: teams that came in skeptical, teams that came in enthusiastic, and teams that came in with firm positions about what they would and wouldn’t allow. What I observed across all of them is that the blockers were rarely technical. They were emotional. And the emotions were consistent enough to name.

The three emotions AI deployment actually surfaces

These aren’t feelings to fix or suppress. They’re signals that show up because you care about quality, you’ve built things that matter, and you take your work seriously.

Trust: “How can AI generate better descriptions than analysts who’ve spent years with this data?”

This one makes complete sense. Your analysts know things no model could: the history, the politics, the edge cases that never made it into any documentation. The tribal knowledge that lives in people, not systems.

But that framing misses what’s actually happening. AI isn’t competing with your analysts’ knowledge. It’s reading everything that knowledge has already produced: the SQL they wrote, the lineage they built, the queries they ran thousands of times, and synthesizing it across every asset simultaneously. It doesn’t replace the expert. It scales what the expert already created.

The fastest path past this emotion isn’t persuasion. It’s evidence. Show someone the output on data they know well. The trust question tends to answer itself.

One technical program manager at a freight analytics company described what happened when her team ran AI enrichment on their first set of assets:

One team I worked with systematically rated every piece of AI-generated output across tens of thousands of asset descriptions. Seventy percent were immediately rollout-ready. A subset were flagged by the team as the standard they’d want human-written descriptions to meet going forward. They came in skeptical. The output changed the conversation.

A data governance lead at a European investment bank put it this way:

Trust is earned through evidence, not persuasion.

Fear: “If I roll this out and something isn’t accurate, I’ll lose credibility with my team.”

This one I felt personally. When I was building an internal AI agent to surface account health signals for a field team, I was genuinely afraid to show it to anyone. The output was useful, and I knew it. But instead of rolling it out, I quietly pulled two colleagues aside and asked for private feedback first. I didn’t want to be the person who shipped something broken.

One of them said something I’ve thought about almost every day since:

Nandini, you don’t know that you’re competing with us not having anything.”

That was the whole reframe. We weren’t comparing AI output to perfect human documentation. We were comparing it to blank. And blank is a very low bar to clear. Most data environments aren’t choosing between AI-generated descriptions and carefully written human ones. They’re choosing between AI-generated descriptions and nothing: no context, no lineage explanation, no indication of what an asset is for or who uses it. The imperfect description almost always beats the absent one.

The downside of rolling out AI-generated context, clearly labeled as such, is that some descriptions will be imperfect. The downside of not rolling out is that your users keep navigating blank assets with nothing to go on. The teams that moved fastest were the ones who stopped asking permission and started showing results. The fear of the conversation, it turned out, was consistently bigger than the conversation itself.

“Allow yourself to trust the process. If you do that a bit earlier, it could be surprising for you.”

Control: “I need to review and verify every single description before anything goes live.”

This is the most understandable emotion of the three, and the hardest to let go of. When you’ve spent years caring about the quality of your data, the instinct to review everything before it reaches users isn’t obstruction. It’s integrity.

The reframe that works: stop asking “how do I verify a million descriptions” and start asking “how do I build a system where quality is maintained at scale?” You move from reviewer to architect. The unit of work changes. Suddenly the thing that felt impossible becomes a design task instead of a manual one.

One team I watched started a sprint with a firm position: they wouldn’t release AI-generated content to their users and weren’t going to run it in production. By the end, they had enriched over 25,000 assets and were among the loudest advocates for AI-generated context in the group. The product didn’t change. Their frame did, shaped by watching peers they respected go through the same journey and come out with more confidence than they’d walked in with.

A senior data governance manager described the shift afterward:

But the bigger shift wasn’t just what they built. When teams brought this context back to their wider organizations, the conversations changed entirely. They weren’t talking about documentation anymore. They were being asked: how do we make this the nervous system of our organization? What does our context layer strategy look like at scale? How do we feed this into the agents our engineering team is building?

The governance teams and stewards who had spent years being asked to document things found themselves being asked to architect something. That’s the agency that was always waiting on the other side of control: not just doing less manual work, but stepping into a more strategic role at exactly the moment it matters most.

Give up control. Retain agency. The goal isn’t to review everything. It’s to build a system you trust, and then use the time it frees to do the work only you can do.

What scale actually looks like when teams push through

Across enterprise teams working through these emotions in structured enrichment sprints, the output is not marginal. It’s discontinuous. The descriptions enriched, the SQL intelligence surfaced, the README updates generated: the volume is not what the same teams would have produced in a few extra months. It’s what they would never have produced at all. Not because no one cared, but because the manual model had a ceiling.

AI didn’t replace the humans. It removed the ceiling on what the humans could accomplish.

One governance lead put it this way:

Another described their team’s attitude changing “instantly” the moment they saw what SQL intelligence surfaced about how their data was actually being used. They came in treating AI enrichment as just another tool. They left treating it as infrastructure.

The fourth emotion nobody names: identity

There’s one more thing underneath all three of these that rarely gets said out loud. Data stewards, governance leads, the people who have spent years building context into systems that were never designed to reward that work: when AI can do the production work at scale, what is their role?

When AI takes on the documentation, the descriptions, the SQL intelligence synthesis, two things happen simultaneously. The pressure to personally document everything lifts. And what gets built becomes the foundation not just for human users but for every AI agent the organization runs. One shared context layer serves both. The governance work stops being a background maintenance task and becomes the infrastructure the company’s AI strategy runs on.

In practice, this means the person who used to spend their time chasing stewards for descriptions is now the person deciding which assets the AI prioritizes, how quality thresholds get set, and which context the organization’s agents are allowed to trust. That’s not a smaller job. It’s a more consequential one.

One governance lead described the shift plainly:

The people who have been building context layers for years, often without recognition or the right tools, are exactly the people positioned to lead what comes next. Not in spite of AI. Because of it.

Joy spent the whole first film trying to keep the difficult emotions out of the control room. The breakthrough came when she finally understood what they were trying to tell her. Trust was telling you the expertise already exists and needs scaling. Fear was telling you to compare yourself to blank, not to perfect. Control was telling you to become the architect, not the auditor. Identity was telling you that the work you have been doing for years is about to matter more than it ever has.

The context layer your organization builds now isn’t just documentation. It’s the infrastructure every AI agent you run will depend on. The people who build it well are not being replaced by the technology. They’re becoming indispensable to it.

This is an adapted version of a piece I originally wrote.

Note: Views expressed are those of the contributor. All submissions are vetted for quality and relevance. Context and Chaos is information-first: no promotions, paid or otherwise.

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you.

About the Author

Juha Korpela is an independent consultant (Datakor Consulting), co-founder of Helsinki Data Week, and the author of the Common Sense Data Substack. He specializes in data modeling, data product management, and helping enterprises understand what their data actually means.

Originally published on Context and Chaos.

Let’s dive in!

Everyone in data and AI is talking about context engineering. Most of the conversation focuses on retrieval pipelines, semantic layers, and prompt design. But there is an older discipline that already solved a large part of this problem, and the industry quietly abandoned it a decade ago. What we lost when we stopped doing conceptual modeling is exactly what AI agents need now.

What problem are AI teams really solving when they talk about “context”?

Connecting data with its business context means connecting data with real value; value creation happens in the business, and whatever we do with data needs to be as closely connected with the business as possible. This has always been the case, long before GenAI - good context is helpful for human users as well. It’s just that it hasn’t been obligatory, as we’ve been able to count on the tacit knowledge of the data consumers to cross that final mile between a field called “cust_lt_val” and actual decision-making.

LLMs make that context obligatory. While the models have a general grasp of how things usually work based on their training data, they don’t understand how things work in this particular organization with its idiosyncrasies. To make data useful for AI consumers, we need to add more information around the data. This is the context problem: what should that information be, and how is it served to the AI?

How did conceptual modeling quietly disappear?

The problem of business context is not new. We always knew it’s important to understand how the data in our systems reflects our business reality. Having that understanding has always helped to both design new solutions to match the real needs and to document them in a business-friendly way.

One way of forming that understanding is conceptual modeling. It used to be so that we would always do data modeling in the design stage of any project, and we would proceed along a well-known path: conceptual, logical, physical. From the business understanding of what this data is about to use-case specific structures and technical implementation design.

But when the underlying technical capabilities went through rapid evolution in the Big Data era, it seemed that technical implementation design for data storages was no longer really necessary. After all, you could just load massive amounts of data into Hadoop or equivalent - why worry about storage design!

Unfortunately, this line of thought led also to the wide-spread abandonment of conceptual and logical modeling. The lowest-level model wasn’t thought necessary, so the higher levels preceding it were also forgotten. However, with the disappearance of conceptual modeling, we lost a valuable connection to business context. What is this data actually about?

What does a conceptual model know that your warehouse never will?

A bunch of tables in a data warehouse (or a lakehouse, or a lake, or anything really) can tell us about the technical decisions made by the engineer during implementation. This field is a string, that’s a number, and here we have a uniqueness constraint. All this technical metadata is valuable, and over time we developed great data cataloging capabilities for extracting it, but it doesn’t tell us anything about semantics, i.e. the meaning of the data.

A conceptual model says “we have a thing called Customer, and the Customer has two subtypes: B2B and B2C, and only the B2B Customer can have Sales Contracts with us, while both of them can make Orders”. The tables in our database tell us how the tables are connected to each other - but there’s no guarantee that the tables will neatly map to the business concepts of Customer, Sales Contract, and Order!

The conceptual model captures and encodes high-level business logic. An accompanying glossary gives definitions for each of the business terms. None of that information can be derived from the bunch of tables sitting in a warehouse - it’s about understanding and modeling the business itself rather than a set of technical objects.

What is the difference between the data plane and the knowledge plane?

The technical objects we create for a variety of solutions can (and will) live on a variety of technological platforms. If the table “dim_cust” exists in one schema on one platform, how do we know if it contains information about the same things as “clients_aggregate” in another schema on another platform?

Semantics - the meaning of various business terms, and understanding of their relationships - is not specific to a single technical data object. It’s by definition information about the business concepts. We can’t manage semantics on the level of individual data objects; we need a wider, cross-solution and cross-platform repository of knowledge, that is technology-agnostic.

The data plane, where all the technical data objects live, and the knowledge plane, in which our semantic understanding lives, must be separate. Trying to manage semantics as part of the data object’s technical metadata is a fool’s errand and only leads to semantic silos.

However, the two planes must be linked to each other. To be able to tell our AI (or human!) data consumers what “cust_lt_val” means, there needs to be a connection between the technical data object living on the data plane and the semantic object (business term) living on the knowledge plane.

What predictable failures show up when the knowledge plane is missing?

If that knowledge plane doesn’t exist, two main failure modes commonly appear.

In the first case, semantics is entirely missing. There simply isn’t any extra information “around” the technical data object that could tell the AI that “this here means Customer Lifetime Value, and this is how it has been calculated”. This means that the AI agent looking for answers from the data will resort to guessing, based on its generic understanding of how things usually work. Sometimes, that guess might be good enough. Quite often - and especially when the topic is something unique and special to the particular organization (which are also usually the most valuable topics!) - it will fail to understand the nuances involved. We say the AI “hallucinates”, but really it is just guessing and reverting back to the average.

In the second case, usually when the organization has been hitting its head in the wall of missing semantics enough, a series of quick fixes are applied. Semantics is understood to be crucial, so the organization rushes to apply it some semantics anywhere. At least the AI will work a bit better, surely? But this rush leads to solution-level semantic silos. An individual dataset might now have some definitions attached to its tables and other objects, and that can indeed help when the AI is looking into that particular solution. But when the organization starts applying agentic workflows with wider, cross-functional scope, the AI will soon run into inconsistencies and unexplainable differences between the semantic information it gets from different solutions. No two solutions have the same definitions for the same thing, and comparing and combining data becomes impossible.

How do you turn conceptual modeling into a living context layer?

Conceptual modeling was always known to be a great method of capturing the core semantic information for data design and documentation: what are the business things this data is about, and how do they connect to each other in real life?

We can now re-apply those well-known and well-tested methods for building context for AI (as well as humans!). Conceptual modeling can be utilized for so much more now than just data storage design - it can surface and document semantics that otherwise would remain tacit knowledge and thus unattainable for AI.

It’s just a matter of figuring out how to manage that information beyond a single diagram. In fact, it’s not necessarily the model diagram itself that is the most important outcome of conceptual modeling; the information captured in a model can and should be made available in all kinds of different formats. Conceptual models can act as the starting point of ontologies and knowledge graphs. Individual model scopes can connect to each other - an enterprise data model doesn’t need to be a massive multi-year documentation effort, but a more organic result of modelers in different domains and different projects producing semantic information that all becomes part of the same interconnected knowledge base. Around such a strong base of core entities and relationships, we can add more and more information gathered from documentation and elsewhere with the help of AI. Building on top of and around the core of well-modeled concepts keeps our knowledge in sync and ensures we share an understanding of how our particular business really works.

Conceptual modeling has always been a method of creating and capturing an understanding of what the business is about, and connecting that to data. Now more than ever that information is crucial for success. Building a true context layer for AI can’t be a micro-level siloed effort; we need to create a cross-solution & cross-platform shared understanding of our core semantics, the foundation any context layer is built on. Conceptual modeling offers a way to build that piece by piece and to connect our data solutions to their real business meaning, without which we can’t cross that last mile to delivering real business value.

Author Connect

Connect with me on LinkedIn!

Subscribe to Common Sense Data NL to explore more.

*Note: Views expressed are those of the contributor. All submissions are vetted for quality and relevance. Context and Chaos is information-first: no promotions, paid or otherwise.

The Cats of Context & Chaos

The Pulse

The reads, debates, and signals worth your time this week.

• Why Metadata Is As Important As Data — Andrew Reiskind

• Continual learning for AI agents — Harrison Chase

• Everyone Has an Ontology Now. Almost Nobody Has an Ontology. — Nicolas Figay

• How to get your company AI pilled — Geoff Charles

• The Mythos Threshold — Joe Reis

• Inside the AI Industry’s Most Expensive Mistake — Alberto Romero

• Context Graphs as AI Evaluation Infrastructure — Sandipan Bhaumik

• How Meta Used AI to Map Tribal Knowledge in Large-Scale Data Pipelines — Krishna Ganeriwal, Plawan Rath, Ashwini Verma

That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!

About Context & Chaos

Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.

Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.

Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.

Got something on your mind? We’d love to hear from you. Hit Reply!