CONTEXT 2026 Highlights: Context Management in Practice

Last year, at CONTEXT 2025, we told you context management was coming. This year, the question changed from whether you need context management to how you manage it.

Ask an agent the same question twice and you can get two different answers. It has no authoritative, current understanding of your data, your metrics, or how your business defines them, so it guesses, and guesses vary. That is what keeps agents out of production.
So the questions get practical:

• Why are my agents still getting things wrong?
• Where does context live?
• Who owns it?
• How do I know it’s working?

Teams that tried the DIY route from pilot to production learned it does not hold up. It takes constant upkeep, results drift, and agents sift through piles of unranked context, which slows answers and drives up token costs. Meanwhile the market got noisy, with plenty of pitches and few specifics.

CONTEXT 2026, our virtual summit on November 4, 2026, answered those questions with experience, rather than theory. Teams from Google Cloud, BlackRock, Optiver, Miro, ICA, iFood, Super Technologies, ReKnew, and more shared what they built, what broke, and how they fixed it. DataHub’s own engineers took the same virtual stage and shared our wins, misses, and learnings, too.

Last year’s message was that context is coming. This year’s is that the practice is here, and DataHub customers are building context now. The same central questions ran through nearly every session. We’ve organized this recap around them. Prefer the full talks? Watch every session on demand.

Why do agents sound confident and still get the answer wrong?

The hardest agent failures to catch are the ones that read like successes. Shirshanka Das, Co-founder and CTO at DataHub, put it bluntly in his keynote address:

“An agent sounds exactly as sure when it is wrong as when it is right.”

Shirshanka DasCo-founder and CTO, DataHub

That is the cost. An answer you can’t check is an answer you can’t ship, so the agent stays in pilot. Gartner expects four in 10 agentic AI projects to be decommissioned by 2027.

Prajakta Damle, Senior Director of Product Management at Google Cloud, put the problem in terms any manager would recognize. In Every Agent Needs an Onboarding Plan, she compared agents to new digital employees. You would not hand a new hire access to your systems and stop there. You would also explain the business, the tasks, and what good looks like. Too often, an agent gets a prompt and a connection string and nothing else. But writing all of that business context down by hand does not scale, so her answer is a context layer that learns from how people and systems already work.

“You really want to have a layer that can observe your environment, learn from both your data and your systems and the people working on these tasks.”

Prajakta DamleSenior Director of Product Management, Google Cloud

DataHub hit the same problem with its own internally-deployed agents. In the keynote, Shirshanka walked through four agents that the team built. Each was built mostly on its own, wired to its own sources, and kept its own copy of what it knew:

• Lisa, the customer intelligence agent, got a simple question wrong: how many customers does DataHub have? Depending on the run, she checked HubSpot, which counts paying logos, or Snowflake, which counts anyone using the product.
• Bart, the coding agent, read a support ticket and saw a linked incident as a bare tag, with no idea whether it was still live, because only one other agent (Willie, the operations and SRE agent) knew how to connect the two.
• Lumbergh, the project manager agent, filed 12 issues into the wrong project after a customer call, because all it knew were project names.

Shirshanka’s diagnosis: “Every one of them is really a context problem, not an agent harness problem, and not a model problem.” The solution was to pull what the team knew out of each tool and into one shared layer. When an agent got something wrong, the team corrected it once, and every agent picked up the change.

For the full breakdown of the five most common context management mistakes we’ve seen across the DataHub team, customers, and community over the past year, and what each one taught us, watch Shirshanka’s full keynote: Why DataHub? What We Built, How It Works, Why It Matters.

Where should context live, and who owns it?

Across the sessions, the answer came in different words but the same shape: one governed context layer, written once, with named owners.

Optiver found out what happens without that layer. After more than 100 teams started writing documentation for their agents, the data platform team counted nearly 2,000 datasets documented independently across offices. One table appeared on more than a dozen separate pages, and when different teams described the same data, only around two-thirds of the descriptions fully agreed. In a CONTEXT Summit first, one of Optiver’s AI agents delivered the session Write Once, Serve Everywhere: How Optiver Built the Context Layer for Agents, in place of Christophe Godefroy, Global Head of Data Platform. The talk was a presentation and a demo in one, showing what agents can do once they have a solid context layer to work from.

“Knowledge is written once as close as possible to the thing it describes. It is versioned. It is connected to the underlying data. And every consumer, human or agent, gets the same context. Write once, serve everywhere.”

Christophe GodefroyGlobal Head of Data Platform, Optiver (presented by his AI agent)

Optiver ran the same tasks with and without the context layer. On one research task, the agent was correct on all five runs versus four of five without it. It used around half the tool calls, completed the task in 40% of the time, and cut heavy warehouse queries by 87%. On real researcher questions with expert-verified answers, governed context raised accuracy from 42% to 74%. Optiver’s summary of the result: “Better answers, less work, lower cost.”

A layer needs owners, and owners need a reason to show up. In Aladdin’s Context Layer: Inside BlackRock’s Blueprint for Agent Ready Data, Jeff Miller, Managing Director, Global Head of Data Factory and Enterprise Data Platforms at BlackRock, described how his team got them to show up. BlackRock treats registration as a gate for bringing data onto its enterprise data platform, and in a regulated industry, Jeff said, enforcement has to be part of the equation. But enforcement alone is not enough. The gate only works because it pays off: registering a data product streamlines the work for the data product owners, the stewardship team, and the engineers building it, and it makes the product easier to make available, understand, and discover. Governance is built into the engineering process, so the schemas a data asset lives in, the warranty and data quality attached to it, and the escalation path when something breaks are all tied to registration.

“People have to have skin in the game and have to believe it’s more than an obligation, it’s an opportunity.”

Jeff MillerManaging Director, Global Head of Data Factory & Enterprise Data Platforms, BlackRock

What does it take to get an agent into production?

In Deploying Data Analytics Agents to Production at Miro, the team connected an analytics agent agent straight to its data warehouse, and accuracy landed around 40%. With DataHub Cloud, the team got past 90%. Ronald Angel, Data Products Manager at Miro, said the biggest gains came from the architecture underneath the agent: domain-owned data products, clear data contracts, and a well-curated output port.

“Context is as good as your data architecture.”

Ronald AngelData Products Manager, Miro

The habits behind that number are specific. Miro’s analytics team certified every eval before it counted, started with the highest-priority data products in each business domain, and runs evals whenever they make a change in the semantic view to evaluate the quality on every trace. Business users send feedback through a skill and a Slack channel for each domain. Ronald Angel explains: “This is something that goes beyond a technical problem. It’s also an organizational problem.” Read the full Miro case study to see each step of the climb from 40% to over 90% accuracy.

The organizational part showed up at ICA too. In Domain Knowledge: Shipped and Maintained in Production, Björn Barrefors, Metadata Management Lead at ICA, described identifying gaps by starting with core definitions that should serve as “golden data”. When there are a dozen dashboards implementing the same concept without a shared definition, that’s the right place to start. To get past the cold start problem, his team uses a stewardship assistant to draft definitions that human reviewers then approve. The agent covers the drafting. People still cover the conversation.

Foundation work shows up in BARC’s research, too. In The State of Context Engineering, Kevin Petrie, VP Research at BARC, walked through Context Engineering for Agentic AI, a 2026 study of 285 data, AI, IT, and business stakeholders. BARC found that 42% of organizations qualify as context leaders. Those leaders were four times as likely as everyone else to also qualify as AI leaders, meaning organizations with strategic, executive-led, governed AI programs in place: 49% against 12%. BARC is careful to note that this does not prove causation. Context engineering appears to advance alongside a disciplined overall approach to AI rather than causing it. Kevin cautions the teams that move fast without that discipline:

“A lot of organizations have rushed into production with agents and I think are creating significant risk and technical debt.”

Kevin PetrieVP Research, BARC

Download the full BARC study for the rest of the findings.

How do you know your context is working?

When a normal service gets worse, error rates climb and someone gets paged. In Evaluating & Maintaining Quality for Data Agents, Chris Collins, Software Engineer at DataHub, opened with what happens when an agent gets worse: Nothing. As he explains, “It just keeps answering.”

This is where evals matter. At DataHub, they work like unit tests for context. Each one has three parts: a real question that people ask, the conditions for a good answer, and a separate judge agent that scores the response and writes down why. The conditions can be a reference query, a plain-language guideline like “revenue has to be net of refunds”, or the sources the agent should or should not cite.

Maggie Hays, Founding Product Manager at DataHub, walked through a first eval in Extract, Enrich, Evaluate: A Playbook For Building an AI-Ready Context Layer. Her advice:

• Start with a tightly-scoped domain
• Be explicit about what the agent should be returning when defining the eval
• Call out common “gotchas” the way you would with a new team member
• Judge the semantic meaning of the output rather than over-indexing on whether the agent generates SQL token-for-token

She also noted that evals are an iterative process, but starting with a small set of the real questions people ask day to day will get you a meaningful result quickly.

In the keynote, Shirshanka recommended picking 20 real questions people already ask and scoring the agent’s answers to give you a baseline. From there, run the set every day and before every context change, and set a target, such as 85%, before an agent goes wide. A regression shows up the next morning, not in a message from a frustrated exec.

Miro put that approach into practice at a larger scale. In Deploying Data Analytics Agents to Production at Miro, Ronald Angel, Data Products Manager at Miro, described building more than 1,000 evals, each certified by analytics experts. Miro runs them whenever the semantics change, and checks traces to confirm agents use the right tools and data sources.

How do you keep context maintained?

A score tells you when context slips. Keeping it from slipping is a separate job, and a harder one, because stale context often fails quietly. In Write Once, Serve Everywhere: How Optiver Built the Context Layer for Agents, Optiver showed what that looks like. In one evaluation, an agent found documentation describing a known issue that had been fixed three days earlier, followed it correctly, and produced exactly the wrong answer.

Optiver’s answer is to run context like the rest of the platform: measured, owned, and kept current. It scores the layer continuously and runs two kinds of evals:

• Capability evals ask what agents still cannot do, so they start low on purpose
• Regression evals check that nothing already working has broken. They sit near 100%, so any dip sounds an alarm.

Every correction a person makes becomes a new eval, so the same mistakes don’t come back. On real researcher questions with expert-verified answers, governed context raised accuracy from 42% to 74%.

The same thinking applies to the data underneath. In Putting Observability on Auto-pilot: Introduction to AI Anomaly Detection, Adrian Machado, Software Engineer at DataHub, showed AI anomaly detection in DataHub Cloud Observe that learns what normal looks like from the history of your data, so you stop setting thresholds by hand.

In From a Failed Data Check to the On-Call Phone, Nikola Kljajo, Senior Engineering Manager at Super Technologies, showed what happens after an alert fires. Super routes failed data quality checks with three tags and three severity levels, from warning to critical, so the right team hears about it at the right volume. For the full setup, read the Super Technologies case study.

How do you scale from one agent to the next?

Many enterprises start the same way. A team picks a use case and builds an agent, then another team builds its own on a different stack. Some of those agents tap the same systems and data, but each may calculate a metric in its own way. In From Point Agents to Organizational Brains, Lestan D’Souza, Co-Founder and CTO at ReKnew, said that approach does not scale when the opportunity runs to 300 or 3,000 agents.

His alternative is what he calls an organizational brain: one governed context layer, contributed to by the whole enterprise, that many agents draw on. He sees organizations heading toward it now. It also calls for new roles, such as the context architect or knowledge steward, who manage what an agent does and the quality of the context it has access to.

A shared layer needs upkeep, and agents can do some of it. In Agents Don’t Mind Doing the Data Work: Scaling AI Readiness in DataHub, Stephen Goldbaum, Field CTO at DataHub, and Nick Adams, Software Engineer at DataHub, showed how. In their demo, one agent audits ownership gaps every week and another scans daily for duplicate tables. Neither changes metadata directly. Both create proposals for a human review queue, and every run records its steps for an admin to audit. To see how agents like these could keep your own context current, book a demo of DataHub Cloud Context.

“One of the effective ways of achieving enterprise scale is to put agents to use for managing that context.”

Stephen GoldbaumField CTO, DataHub

Learn from the builders

Every vendor has a context story right now. Most of them are pitches: a clean diagram, a confident promise, a demo that works once. A pitch shows you the finish line. To make this work at your own org, you need the full route, wrong turns included.

That is what the CONTEXT 2026 speakers brought. Optiver showed nearly 2,000 datasets documented independently before it built its context layer. Miro showed the 40% before the 90% analytics agent accuracy. Our Co-founder and CTO showed the agent that filed 12 issues into the wrong project. Nobody hid the mess, and the sessions are better for it. You can see where each team started, what broke, and what they would do again.

Context management is hard and changing fast. The best way to learn it is from people a few steps ahead of you. We will keep sharing what we learn in the open, and we hope you will too.

Every session is on demand, and the keynote is the best place to start. Take what’s useful, and bring your own lessons to the DataHub Community on Slack.

If you’re working through the same questions these teams were, DataHub Cloud Context is what we built to answer them. It gives every agent one trusted source of technical, semantic, and knowledge context, with built-in evals that measure how every context change affects agent accuracy. The quickest way to see if it fits is to test it on your own problem. Book a personalized demo, tell us what you’re working on, and we’ll show how DataHub would support it with the stack you already have.