Last week, a technology leader who runs finance, HR, and payments systems for a large retailer asked me the question I keep hearing about the context layer: “What’s it going to cost me?” I didn’t have a simple answer. Neither, as far as I can tell, does anyone else yet.
I’ve heard from so many practitioners about the persistent challenge of getting AI right. One team had diligently written skills into markdown files and still could not get its agent to use it reliably for simple tasks like “prep me before this call”. Another fixed an agent that misread its churn scores and still had no production accuracy number to show the fix held.
The bottleneck to enterprise AI has moved from the model (2024) to the harness (2025) to, finally, the context. OpenAI, AWS, Google, Snowflake, Databricks, LangGraph, and a dozen others have put this word at the center of their AI story this year. Yet, despite this, no one agrees about what it means. For some, context means knowledge. For others, it means memory, or skills, or tools and permissions, or the instructions and data model an agent reasons over.
We won’t settle on one definition before October 28, and honestly, I don’t think we need to. What we need are answers to a few practical questions that real practitioners care about, in roughly the same words, regardless of industry.
These are the five questions I most want us to answer at the upcoming Context Conference on October 28th.
1. How do I convince my CFO to invest in a context layer?
AI is the top priority in most boardrooms right now, but it is still barely understood in most parts of the business. What I hear in closed rooms from technologists, architects, and data leaders is some version of the same sentence: “My business does not understand that consistent, reliable AI needs solid foundations, and investing in foundations takes time, money and patience. Heck, they don’t even know the difference between a prompt, a skill, and an MCP server. How do I make a business case?”
The evidence that getting the foundation for AI right pays is getting harder to ignore. A Gartner survey of 353 data and AI leaders, published in April, found that organizations with successful AI initiatives invest up to four times more, as a share of revenue, in data and context foundations than those with poor outcomes, and that the most mature see up to 65% greater business outcomes.
A survey number does not get a budget approved though. The CFO will want a business case. Maybe that’s a strategic case: context is the company’s intellectual property, and it should be owned and portable rather than rebuilt inside every new tool. And maybe a P&L case: lower token consumption, better accuracy and ROI across the other AI projects that depend on the same context, the direct cost of running the system at scale, and how long it takes to get an AI project live.
Calculating ROI when value shows up everywhere | Source: Context and Chaos
That is the question the executive session at 11:20 am ET puts to Cindy Hoots, Leigh-Ann Russell, and Prakash Kota, who have run technology as CIOs at AstraZeneca, BNY, and UKG: why invest in context at all, and how do you build the business case?
2. How do I model context to create reliable AI outcomes?
Most of the companies I talk to are stuck one step earlier, at bootstrapping. How do I get context in at all? Where does it come from, and who writes it? Then they get their first few agents running on it, and all hell breaks loose. The problems that come after bootstrapping get far less attention, and in my experience they are harder.
The clearest example I have seen came from a team at a large consumer internet company. They had already done the work: written definitions, collected examples, specified output formats, and built skills. The context existed. It just lived in six Markdown files.
Yet the agent still would not use it reliably and consistently. So they tried making the context update itself from usage, and that made things worse: “The context keeps updating. It was going really crazy. So we introduced a human in the loop.”
Enterprise AI requires reliable, consistent execution. We can’t just set up an agent to drive a business process that’s right 97% of the time. I like to joke that even if the agent is wrong, in enterprise, you want it to be consistently wrong.
Every advanced team I speak to these days is learning the hard way that context is not a pile of documents. It is a system that has to help an agent retrieve the right pieces, combine them, decide which one wins when two conflict, and apply them at the right moment. That is at least four separate modeling problems: what context exists, how do I model it (metric, semantic view, ontology, skills), how is it retrieved (yes, every harness retrieves context differently), how is precedence decided, and how do you know an update improved the answer instead of breaking it?
The customers furthest along are already asking the next questions. How are corrections captured from traces, and how do they reach the person who owns the skill? How are context changes versioned? Can we run a regression before publishing? Can we see which agents depend on a definition before we change it? How do we roll back a change?
The goal is context that is composable, bounded, and applied the same way every time, which is a different thing from complete. Context management is a discipline, and most of us have barely started treating it as one. Context has to be managed like code: owned, versioned, reviewed, tested before release, and rolled back when it breaks.
At 11:50 am ET, Verizon’s context architecture session by Steven Huang is where I expect this to get concrete, after which our team will do a show and tell on everything we’ve learned in the past year.
3. What will it take to finally ship an accurate data agent?
Data agents have been all the rage for the past 12 months but the general word on the street is, they don’t quite work. I’ve seen this play out firsthand, quite painstakingly, in the past 18 months. I believe we’re finally on the precipice of data and analytics agents going from the lab and into production.
Don’t believe me? In the past 9 months, 43 teams have published content about their internal analytics agents. Ian Macomber at Ramp calls it the post-AI data stack: an agent harness between the data stores and the interfaces, fed by company context and a feedback loop, with the data team’s job shifting to defining the one reality the company operates on. His one piece of advice: when models give different answers to the same question, assume the models are never wrong, but instead that your context is just underspecified. And on October 9, LinkedIn’s engineering team published a write-up of its data context layer, which tells people and agents which datasets to trust, which joins and filters are required, and what a row means. After LinkedIn’s analytics agent was connected to their context layer, the share of acceptable answers in one business-area benchmark rose from 25.9% to 79.5%. In a separate comparison, median time to an answer fell from 10.7 to 4.7 minutes.
LinkedIn's results after connecting its analytics agent to its data context layer | Source: Context and Chaos
At Atlan, we have spent this year on the same problem, on our own research bench and with the teams building alongside us. For the first time, I think we know what it takes to ship an analytics agent the business trusts.
On October 28, we will finally show it publicly: the results from our bench, how to model context so the agent actually retrieves it, and the forward-deployed playbook we use to get an analytics agent live. Then we hand the talk to the people doing this in production. Joe DosSantos from Workday, Piyush Bhargava from DocuSign, and Sowmya Parthan from Upwork will sit on the practitioner panel at 12:30 pm ET and talk about what it really takes to make an analytics agent work.
4. Who owns context quality once agents cross team boundaries?
The moment an agent serves more than one team, context stops being a modeling problem and becomes an operating-model problem.
A large healthcare enterprise told us it had no central semantic model and no control layer across the organization. Definitions were spread across platforms and teams. The hard part was not finding the conflicts. It was deciding whether two different definitions of the same term were a mistake, or whether both were valid for different uses.
A global technology company described the same problem at a much larger scale: roughly 1,200 people in one organization building agents for their own use cases. What they wanted was a place where skills could be stored, evaluated, traced, deduplicated, and assigned an owner with authority.
A third customer had already picked a model. Some teams build their own context. Others rely on a central analyst group. A team is allowed to own its context end to end if it meets the CI/CD and evaluation bar.
Enterprise AI is a multiplayer game. Context is like software dependencies. An update that marketing makes to a skill might feed dozens of downstream processes, including outbound emails that the BDRs send, messaging on the website, and product copy. What if a skill owner just updates a skill? How does it affect all the downstream tooling, especially the more autonomous tooling?
Who owns the blast radius of a skill update? | Source: Context and Chaos
We still have to decide who owns a metric definition, who approves a shared skill, who is accountable when a local preference becomes a global instruction, who reviews a change that touches ten downstream agents, and who owns the regression when an update fixes one workflow and breaks another.
Context quality cannot be owned by nobody. But who owns it?
It’s one of the questions behind The AI Context Gap, a new study from MIT Technology Review Insights on what’s blocking AI projects, including who should own the knowledge and rules AI depends on. Everyone who attends the conference gets early access on October 28th.
We’re launching two more things at the conference: AI Context Platform for Dummies, and the forward-deployed playbook our team uses to get agents into production.
5. How do we keep context portable, and whose is it?
Portability is a question about who owns the accumulated intelligence of a business.
A large multi-product company described a situation I think many enterprises will recognize. Its internal agent platforms handled context well within their own user bases. But employees were also working across several other tools, internal and external, and the team worried that a skill handed from one platform to another arrived only partially, with the meaning diluted on the way. The context existed, but it did not survive the boundary between tools.
We saw a sharper version with a company that had moved to a cheaper cloud stack. It still needed its analytics glossary, the business terms, metrics, and narratives its analysts depended on, and it was rebuilding that glossary by hand in a Git repository. Agents could propose merge requests, but someone still had to push them to propagate the information and approve each change. As far as we could tell, none of the old context carried over on its own.
The definition moved. Its context didn't. | Source: Context and Chaos
These common challenges should change how we think about a customer’s context. It should not be trapped inside whichever data platform, agent framework, or vendor interface the company happens to use this year.
The customer’s context is the customer’s intellectual property. It should move when they do. And so I would put a few questions to any vendor, including us: Can the customer export its context in a form a human can read? Can one definition be used by agents on different platforms? Does a skill keep its owner, permissions, provenance, and version history after a migration? Does the same business definition have to be maintained in five tools? What happens when the company switches its model provider?
We believe that the real hard work will be building a community and ecosystem for open context. That’s why we are so excited to have Josh Klahr from Apache Ossie (Snowflake), Prajakta Damle from Open Knowledge Format (Google), Dipti Borkar from Microsoft OneLake, and Amandeep Khurana from Anthropic on a panel led by Bob Muglia at 1:20 pm ET on how to build an open context ecosystem.
I do not expect the Context Conference to settle all five. But if one of these questions is the one keeping you up, bring it. The sessions are built around them.
The Cats of Context & Chaos
The bottleneck moved from the model (2024), to the harness (2025), to context (2026). The questions moved with it. | Source: Context and 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.
Share this article