I think an interesting point to be mentioned is that the basic unit of any business or work is a person, and the ability of any given person to use their own context when interacting with agents and LLM's is key.
I built my personal context layer with MindStash, where I capture any new piece of information I find relevant (including this piece), as well as my thoughts. It puts it all in a knowledge graph I can talk to and see all of the connections.
Or, you could just use the existing frameworks and guidance and masterfully build context-heavy context for epic guidance to orchestrate very brittle workflows (like signing / certifying / notarizing 30 languages into a single package): https://blog.yen.chat/p/skills
It's not just "proper data", it's also how context is assembled. How conflicting/stale/un-related data is processed to surface the relevant bits.
In some ways, this is not much different from the 2014s, when "data was the new oil" and it was thought that dumping data into data lakes will automatically be useful.
What actually happened was the rise of specialized compute and storage: Spark, document DBs, KV stores that made the underlying data swamps useful.
Same pattern in a different slice: we see the “context layer” problem in eng when code agents (Cursor, Claude, etc.) and humans collaborate on specs - constraints and definitions drift, no single source of truth, tribal knowledge in scattered markdown. We’re building Specularis.org to keep specs canonical and versioned for that workflow. The “living corpus” idea maps cleanly to specs as the context agents and humans share. Great post, thanks!
Great article! I would say it’s a combination of clean data, ontology, semantics, and context to ensure agents are consistently accurate. My reasoning is simple:
Clean data ensures the numbers are technically correct. But correct numbers alone don’t create intelligence.
If ontology is missing, data stays siloed, systems don’t understand how business entities relate.
If semantics is missing, teams interpret the same metric differently, dashboards become debates.
If context is missing, analysis may be accurate but decisions become wrong for the situation.
In other words: clean data enables high level analytics; ontology, semantics, and context enable deep decision grade intelligence.
Context layers vs the underlying business graph: I really enjoyed this post on context layers. The diagnosis feels exactly right: most enterprise agents fail not because of model limitations, but because they lack the organizational context needed to reason about messy real-world data.
One perspective that might resonate: a context layer is often just a manually assembled shadow of the underlying business. Intergraph turns the enterprise itself into a machine-readable coordination graph, so AI agents don’t need a context layer—they reason directly over the structure of the business.
I’ve been exploring this concept, alongside a new data model for AI that I invented for this purpose called Intergraph. I am writing my notes over at Book of Agents (https://bookofagents.com), but the key idea is that modeling the business itself organically produces context, rather than assembling it piecemeal.
If you’re exploring this space further, I’d love to compare notes — it feels like we’re circling the same structural gap from slightly different directions.
Nice roundup, but what’s most important is standards. Especially context stack permissions system standard.
While the thrashing will continue, a standards body and published interfaces that make it work will be where it ends up… just as the last 30 years. USB consortium, XML, JCP, security,
The best investors can do is pound the drum around “Interfaces, interfaces, interfaces” interop. Modular.
But first-pass shit show of fish with three eyes will continue for foreseeable future driven by fresh dev with no clue, and stalwarts delaying wanting to use AI.
The stalwarts will win, they are last generations 3-eyed-fish builders.
Interfaces, interfaces, interfaces is the investor drum. Short term gains will all be washed away by standard, swappable components.
In that line, prompt resolution will be one a major component, as will context injection via frameworks. Observe & inject is a pattern stalwarts can focus on today, it’s very deterministic.
This is a precise articulation of the context problem on the query side. The part that stayed with me is "governance guidance" sitting inside the context layer, because it signals where the data context problem starts bleeding into an execution context problem.
Once these agents move from answering questions to taking actions across production systems, a second context layer becomes necessary: who authorised this action, what are the failure boundaries, what is the system of record for what actually happened. The "brittle workflows" problem from the MIT research lands here too. Workflows break when the execution substrate lacks ordering, scoped authority, and deterministic failure handling. Those properties are infrastructure design problems at the same layer of the stack your data context sits at, just on the action side rather than the query side.
The data context layer you describe gives agents the right question. The execution context layer gives agents the right constraints when they act on the answer.
This context will not only be for businesses but for users private information, payments information, and for a streamlined permissions set up for human in the loop confirmations.
I think an interesting point to be mentioned is that the basic unit of any business or work is a person, and the ability of any given person to use their own context when interacting with agents and LLM's is key.
I built my personal context layer with MindStash, where I capture any new piece of information I find relevant (including this piece), as well as my thoughts. It puts it all in a knowledge graph I can talk to and see all of the connections.
Or, you could just use the existing frameworks and guidance and masterfully build context-heavy context for epic guidance to orchestrate very brittle workflows (like signing / certifying / notarizing 30 languages into a single package): https://blog.yen.chat/p/skills
It's not just "proper data", it's also how context is assembled. How conflicting/stale/un-related data is processed to surface the relevant bits.
In some ways, this is not much different from the 2014s, when "data was the new oil" and it was thought that dumping data into data lakes will automatically be useful.
What actually happened was the rise of specialized compute and storage: Spark, document DBs, KV stores that made the underlying data swamps useful.
Shared on this earlier today:
https://www.linkedin.com/pulse/context-assembly-pipeline-harsh-chaudhary-xofie
Same pattern in a different slice: we see the “context layer” problem in eng when code agents (Cursor, Claude, etc.) and humans collaborate on specs - constraints and definitions drift, no single source of truth, tribal knowledge in scattered markdown. We’re building Specularis.org to keep specs canonical and versioned for that workflow. The “living corpus” idea maps cleanly to specs as the context agents and humans share. Great post, thanks!
Great article! I would say it’s a combination of clean data, ontology, semantics, and context to ensure agents are consistently accurate. My reasoning is simple:
Clean data ensures the numbers are technically correct. But correct numbers alone don’t create intelligence.
If ontology is missing, data stays siloed, systems don’t understand how business entities relate.
If semantics is missing, teams interpret the same metric differently, dashboards become debates.
If context is missing, analysis may be accurate but decisions become wrong for the situation.
In other words: clean data enables high level analytics; ontology, semantics, and context enable deep decision grade intelligence.
Strong agree on this piece. From experience it’s also a very challenging problem - both to build the context graph, and to maintain it well.
Context layers vs the underlying business graph: I really enjoyed this post on context layers. The diagnosis feels exactly right: most enterprise agents fail not because of model limitations, but because they lack the organizational context needed to reason about messy real-world data.
One perspective that might resonate: a context layer is often just a manually assembled shadow of the underlying business. Intergraph turns the enterprise itself into a machine-readable coordination graph, so AI agents don’t need a context layer—they reason directly over the structure of the business.
I’ve been exploring this concept, alongside a new data model for AI that I invented for this purpose called Intergraph. I am writing my notes over at Book of Agents (https://bookofagents.com), but the key idea is that modeling the business itself organically produces context, rather than assembling it piecemeal.
If you’re exploring this space further, I’d love to compare notes — it feels like we’re circling the same structural gap from slightly different directions.
Nice roundup, but what’s most important is standards. Especially context stack permissions system standard.
While the thrashing will continue, a standards body and published interfaces that make it work will be where it ends up… just as the last 30 years. USB consortium, XML, JCP, security,
The best investors can do is pound the drum around “Interfaces, interfaces, interfaces” interop. Modular.
But first-pass shit show of fish with three eyes will continue for foreseeable future driven by fresh dev with no clue, and stalwarts delaying wanting to use AI.
The stalwarts will win, they are last generations 3-eyed-fish builders.
Interfaces, interfaces, interfaces is the investor drum. Short term gains will all be washed away by standard, swappable components.
In that line, prompt resolution will be one a major component, as will context injection via frameworks. Observe & inject is a pattern stalwarts can focus on today, it’s very deterministic.
Why is Palantir not mentioned here? Kind of obliterates the stack.
They do mention Palantir?
This is a precise articulation of the context problem on the query side. The part that stayed with me is "governance guidance" sitting inside the context layer, because it signals where the data context problem starts bleeding into an execution context problem.
Once these agents move from answering questions to taking actions across production systems, a second context layer becomes necessary: who authorised this action, what are the failure boundaries, what is the system of record for what actually happened. The "brittle workflows" problem from the MIT research lands here too. Workflows break when the execution substrate lacks ordering, scoped authority, and deterministic failure handling. Those properties are infrastructure design problems at the same layer of the stack your data context sits at, just on the action side rather than the query side.
The data context layer you describe gives agents the right question. The execution context layer gives agents the right constraints when they act on the answer.
This context will not only be for businesses but for users private information, payments information, and for a streamlined permissions set up for human in the loop confirmations.
We’re working on that part at Hyperware