AI Engineer World's Fair 2026
Building agents is trivial now, context is the next frontier
Read the talk
Building an agent is easy. Giving it the missing history is harder.
A Linear enrichment agent finds a plausible fix in the code—and recommends repeating an outage. The missing input is the organization’s memory of why that code was disabled.
From a talk by Jeff Ng
Before you start: Familiarity with tool-using agents, issue trackers, and code repositories will help; the TypeScript example illustrates how context enters an agent’s planning step.
Why an easy-to-build agent can still be confidently wrong
What remains difficult when building an agent becomes easy, but its answers are still confidently wrong? Jeff Ng, a founding engineer at Unblocked, starts with that mismatch. He recalls that six months earlier, building a production agent could occupy a team for roughly a quarter. Selecting a model and attaching tools was only part of the work; the surrounding production systems could each amount to a company or a substantial engineering function.
Durable state is one of those requirements. Agent runs are long-lived and stateful, while the infrastructure executing them can disappear. A useful checkpoint must preserve message history, tool calls, and the current position in the agent loop. Without those, a crash leaves the service unable to resume the session.
Restarting is not equivalent to resuming. It repeats token expenditure and makes the user wait through work already performed. It can also repeat side effects: an action taken before the crash may happen again when the run starts over. Persistence therefore protects more than the conversation transcript; it preserves the execution history needed to continue responsibly.
Two other requirements sit alongside persistence:
- Sandbox isolation: Agent-generated and third-party code execute on the operator’s infrastructure. Isolated sandboxes help restrict access to environment secrets and unnecessary network destinations, while protecting the shared host.
- Observability: When something fails, logs and traces must make it possible to locate the failure across the systems involved.
These are necessary production capabilities, but none gives the agent better knowledge of the task. They are the cost of getting an agent into service.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Infrastructure primitives shrink the agent definition
Cloud infrastructure providers such as Cloudflare, Vercel, and AWS increasingly supply the underlying primitives, while frameworks such as Flue, Vercel’s eve, and Mastra assemble them into an agent runtime. That moves effort away from supporting infrastructure and toward the logic that serves a team or customer.
Ng’s example combines Flue with Cloudflare. Once the runtime handles the supporting systems, defining an agent becomes a small set of choices:
| Choice | What it determines |
|---|---|
| Model | Which model performs the reasoning |
| Instructions | The agent’s task and system prompt |
| Tools | The operations it can invoke |
| Skills | The capabilities available for its work |
| Sandbox | Where execution takes place |
The compact configuration is meaningful because the runtime supplies the machinery behind it. It does not, by itself, supply the facts the agent needs to make a correct decision.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The code suggests a fix that repeats an outage
The demonstration is a Linear issue enrichment agent with access to a code repository. Its workflow is straightforward:
- Fetch the Linear ticket.
- Determine whether it describes a feature or a bug.
- Search the repository for relevant code.
- Pass the findings to the agent.
- Produce a plan of next steps.
This is a useful background task: turn a short issue report into something an engineer can act on.
The input is a support engineer’s report about degraded responsiveness in the internal agentic QA pipeline. Ng reports time to first character of three to four seconds, against an expected hundreds of milliseconds. That is the incident’s reported symptom, not a measured comparison between agent frameworks.
The agent fetches the ticket, uses its code retrieval and search capabilities, reasons over the results, and writes a recommendation back to Linear: re-enable async dispatch. The reasoning sounds sensible. Async dispatch allows more QA pipeline work to run in parallel on a single machine, so enabling it appears to address the latency problem.
But async dispatch had caused an outage a few days earlier. A support engineer had explicitly disabled it before this ticket was presented. The agent has successfully completed its workflow and updated the issue, yet its proposed fix would reverse an intentional operational decision. A plausible explanation of the code is not enough to establish that a change is safe.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The missing input was the team’s history
The missing evidence lived outside the repository and the current ticket. Engineers had discussed the outage in Slack: what went wrong, what fixed it, and what should happen next. That discussion also produced a Linear postmortem ticket. Neither source was part of the enrichment agent’s input. The agent could inspect the implementation without seeing the explanation for its current state.
This becomes especially dangerous in a background agent. There may be nobody watching the recommendation appear, so missing organizational knowledge becomes a silent failure. The resulting ticket can misinform teammates and potentially other agents that later treat it as context.
Interactive coding sessions often conceal this dependency because the engineer supplies the missing context turn by turn. The person asks questions, catches errors, adds facts, and steers. They know why the code looks the way it does, what broke previously, and what the team decided afterward. The agent has only its instructions, its supplied tools and skills, the code, and the ticket in front of it.
Removing the human from the loop also removes that source of history and intent. Easier deployment makes unattended agents more common, but it does not replace the knowledge their users were quietly contributing. Something else has to carry that responsibility.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From connected sources to actionable context
Ng calls the replacement a context engine: a system that provides task-relevant information, accounts for the identity and access roles of the person or agent asking, and reconciles conflicting sources. Its output should be a synthesized understanding the agent can act on, rather than a list of documents it must independently interpret.
The inputs extend beyond source code because engineering work does too. Slack contains decisions; documentation contains best practices; tickets record problems and follow-up work. The context engine connects documentation, code, tickets, and conversations, then builds a model of how the organization and its systems fit together. For a particular task, it returns a slice of that model that has been reconciled, ranked, and scoped to permissions. The intended transformation is from scattered information to grounded context.
Why not simply connect Slack, Linear, and GitHub through MCP? Those connectors make the sources accessible, but separate source results still leave the agent responsible for deciding what to believe. The distinction is between retrieving information and preparing it for a decision:
| Responsibility | Separate source connectors | Context engine |
|---|---|---|
| Retrieval | Return source results | Gather relevant evidence |
| Relevance | Agent filters the results | Return a ranked task-specific slice |
| Conflicts | Agent reconciles sources | Reconcile before delivery |
| Output | Results to interpret | Synthesized understanding |
In Ng’s account, irrelevant results consume context-window space and increase context costs. When Slack and Linear disagree, the local agent must resolve that disagreement ad hoc.
This is a distinction between system responsibilities, not a restriction of MCP: Unblocked itself serves synthesized context through MCP. Two implementation boundaries matter. Its later architecture explanation allows unresolved disagreements to be surfaced rather than silently settled. Permission scoping also depends on authentication and configuration: current installation guidance warns that a token-based connection can expose team-source documents, including private Slack content. A connector alone therefore guarantees neither reconciliation nor the intended access boundary.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Repeat the task with the outage history included
Ng returns to the same file and the same agent, now with the context engine connected. The additional step asks Unblocked to research the Linear ticket before the agent completes its reasoning. During the repeated run, the context engine finds the relevant Linear postmortem and the Slack conversation containing the engineering discussion. It returns a synthesized summary to the agent, so the agent no longer has to reconstruct that history from the source documents itself.
The integration boundary can be expressed in TypeScript as a function that assembles the inputs to planning. Here, researchContext represents the context service and proposeNextSteps represents the agent; neither is a particular SDK method. The important dependency is that planning receives organizational context alongside the ticket and code findings:
typescript
type Ticket = {
id: string;
description: string;
};
type EnrichmentServices = {
fetchTicket(id: string): Promise<Ticket>;
searchCode(ticket: Ticket): Promise<string>;
researchContext(ticket: Ticket): Promise<string>;
proposeNextSteps(input: {
ticket: Ticket;
codeFindings: string;
organizationalContext: string;
}): Promise<string>;
};
async function proposeIssueEnrichment(
ticketId: string,
services: EnrichmentServices,
): Promise<string> {
const ticket = await services.fetchTicket(ticketId);
const [codeFindings, organizationalContext] = await Promise.all([
services.searchCode(ticket),
services.researchContext(ticket),
]);
return services.proposeNextSteps({
ticket,
codeFindings,
organizationalContext,
});
}
For the async-dispatch ticket, the additional input carries the outage discussion and postmortem that were missing from the first run. This function returns a proposal; publishing it to Linear is a separate operation.
The demonstrated recommendation then changes. Ng describes the revised advice as preventing another outage instead of causing one. The demonstrated result is a changed recommendation, not a production fix with a measured outcome. What changes the decision is the newly available history of the system, rather than a different model or a different repository.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Institutional knowledge beyond ticket enrichment
Ticket enrichment is one application of the same underlying requirement. Ng extends it to several other workflows:
- Coding plans: Supply organizational context to Claude Code or Codex before the agent proceeds with its plan. Ng claims this can save context and tokens, without providing measurements.
- Code review: Give the reviewer the history and intent that would inform an experienced teammate’s review.
- Customer success and sales: Surface answers grounded in the organization’s knowledge for people responding to customers.
The application slide also includes code generation, triage operations, and incident management. Across these uses, the shared input is institutional knowledge that is difficult to recover from the immediate task alone.
An agent can have the tools to inspect a system and still lack the reason that system was built—or deliberately changed—that way. As deployment becomes easier, supplying that reason becomes a larger part of making unattended agents useful. Ng closes with the distinction his demonstration makes concrete: “The gap isn't intelligence, it's context.”
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Vercel's introduction to its agent framework, covering durable sessions, isolated execution and human approvals.
Official starting point for building agents with Mastra.
Further reading
Explains how Flue combines declarative agent definitions with Cloudflare's execution and storage primitives.
Updates since the talk
Deployment walkthrough covering Workers, Durable Object sessions and sandbox configuration; updated July 2026.
Installation guidance and the current tools for retrieving organizational context and synthesized answers with citations.
A later technical explanation of retrieval scoping, expertise signals, conflicting sources and permission enforcement.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hi, all. Uh, my name is Jeff.
- 0:15
I'm a founding engineer at Unblocked, and I'm here to talk to you about how building agents has actually gotten pretty easy. But unfortunately, they still get things confidently wrong.
- 0:27
So six months ago, it required a team's effort and basically a quarter to build out an agent. Um, an agent is more than just models and tools. It's the models, the tools, and everything required to build out a production service.
- 0:42
Uh, here are some examples of the different systems were necessary in order to build something out. Each one of these was basically its own company or at least a company function.
- 0:54
Not gonna go through each one of these, but, you know, a few that stood out to me.
- 0:59
First one, checkpoint and state persistence. Agent runs, they're typically long-lived and stateful. Um, unfortunately, uh, infrastructure itself though, those-- that's ephemeral. Crashing without durability can actually lead to a lot of state loss, and that state kind of includes things like message history, tool calls, as well as, you
- 1:24
know, where you are in the loop. Without these things, you can't resume the session. Uh, one option is, you know, maybe you wanna restart the session. Unfortunately, that's actually quite expensive as well.
- 1:36
Uh, you lose out on all the tokens that you'd originally used, uh, as well as, you know, latency. Uh, from a user experience standpoint, you've already triggered that session.
- 1:47
Now you have to wait for the whole thing to go again. And lastly, side effects. Your agent might have performed some side effects, and now there's a chance of those doubling up.
- 1:58
So next thing, sandbox infrastructure, right? So as we all know, we're running more and more agent-generated code as well as third-party code. This gets all run on your infrastructure, and due to that, there are some complexities.
- 2:13
Uh, because of that, we want to introduce isolated sandboxes, which help prevent, uh, unnecessary reads of environment secrets, unnecessary network access. You know, just in general, we don't wanna take down the shared host.
- 2:30
And then observability. How do we answer the question: where did this fail? Typically, this includes tracking logs and traces from across half a dozen systems.
- 2:43
Everything I've mentioned here, none of this actually improves an agent's capabilities. They're all taxes one has to pay in order to get an agent out there to play the game.
- 2:56
Thankfully, things have changed quite a bit. Uh, the whole ecosystem has matured quite a bit, and cloud infrastructure players such as Cloudflare, uh, Vercel, AWS, they've gone and taken some of that complexity away and built primitives that these frameworks, Flu, Vercel Eve, Mastra,
- 3:18
with these together, you know, they've taken a lot of the complexity away, and you can focus more on building the actual agent itself, the core logic that actually helps you and your team and your customers.
- 3:33
So here's an example of one. Uh, I've played around with Flu and Cloudflare, and as you can see on the left-hand side,
- 3:42
you know, we basically handle everything as mentioned before. So the primitives plus a framework lead to a situation where it's actually not that much code to define an agent, uh, one of the things I was shocked at when I first took a look at the documentation.
- 3:57
To get in the details, all you really have to do when defining an agent is, A, deciding which model you wanna use, B, the instructions or, you know, the system prompt, C, the tools that you want the ax-- the agent to have access to, skills, the things that it can do, as well as the sandbox location, where
- 4:17
things are being run. So, uh, to give you an example of this,
- 4:25
I've actually gone and built out a issue enrichment system specifically for Linear. So what this does is, given a Linear ticket and access to your code repository, it'll go out, you know, fetch a Linear ticket, determine whether or not it's a feature or a bug.
- 4:43
From there, it'll do some code searching, provide all that context to the agent, and then come up with a plan of next steps.
- 4:51
On the left-hand side here, this is a issue that one of my colleagues, a support engineer, had posted, I think, a month ago. Uh, to summarize it, what had happened was we had some pretty serious degradation in our agentic QA pipeline, time to first character was taking three to four seconds when it should realistically be in the
- 5:11
hundreds of milliseconds. So let's see what happens when, you know, we put this through the system.
- 5:20
So as you'll see here, I've set up the agent to go fetch a agent. I've given it the skills and tools to actually go and fetch a code, search a code, and query against that.
- 5:31
That's being passed back to the agent, which is doing some reasoning against that right now.
- 5:36
And then just wait a little bit. At this point, we've updated the Linear issue ticket. The recommendation here is to re-enable our async dispatch, which makes sense. It allows us to run a lot more of our QA pipeline in parallel on a single machine.
- 5:52
Sounds great, right? Unfortunately, um, this is wrong. This had actually caused an outage a few days ago, and one of our, uh, support engineers had explicitly disabled this, uh, before this ticket was, uh, shown.
- 6:07
So-
- 6:10
Where did things go wrong? Why was the con-- uh, you know, why did I get it wrong? The agent I had written, it didn't have a full picture. It was missing the context from the Slack discussion that happened after the issue where the engineers came together, uh, went through the actual outage, what went wrong, what was the
- 6:28
fix, and the next steps. It also was missing the postmortem, uh, Linear ticket, which came as a result of that. In general, it had a narrow understanding of the problem.
- 6:41
This concept of missing knowledge and intent that's stored across an organization and different systems is something that comes back in the back again. And since this was deployed as a background agent, this is gonna make that mistake silently in the background, misinforming both my teammates and potentially other agents.
- 7:00
So I guess the next question is, why don't we run into this locally? You know, we all use agents locally. We don't necessarily run into these issues. Well, you, the human, the engineers, we currently act as that context layer.
- 7:14
When working with an agent, you know, you're there to ask questions, catch any errors, and supply the missing facts on every single turn.
- 7:23
A person knew why the code is the way it is, what broke last time, and what we've decided to do about it. The agent though, it only has what's on the right-hand side, right?
- 7:33
It has instructions, the tools and skills we specifically gave it, the code, as well as the ticket in front of it. When a agent is in the loop-- oh, sorry, when a human is in the loop with the agent, we're there to catch, to steer.
- 7:47
Ultimately, we're there to babysit the agent. But as agents have gotten trivially easy to deploy, as I've shown earlier with Flu and Cloudflare,
- 7:57
the-- without the human in the loop, this issue becomes more and more prevalent. This missing context becomes a silent failure. You know,
- 8:06
all that intuition and knowledge that we've had as humans needs to be replaced. Something needs to carry the load.
- 8:14
So that thing, that's a context engine. A context engine is a system that provides task-relevant information based on who you are and what matters. It also resolves all the conflicts across multiple data sets.
- 8:29
It understands your access roles or the agent's access roles, and only, uh, respects that, and only provides information that's relevant. And most importantly, it delivers a synthesized understanding that an agent can act on, not just a list of documents that it has to reason upon itself.
- 8:47
So how does this context engine work? Well, let's take a step back. What does an agent actually need? An agent needs-- Clearly, it needs context outside of just your source code.
- 9:00
Think about everything that you need to work day to day. It's not just the code. It's, you know, the Slack discussions where decisions are made, the documentation where we show all the best practices.
- 9:13
All that is important to your day-to-day process, and that's true for your agent as well. So what we do here is we connect everything, your docs, code, tickets, conversations.
- 9:24
We then build a model of your organization, of your system, and we piece how all of these things work together and make it generally available to your agents. From that model, the agents are only provided a slice of that data which has been reconciled, ranked, and scoped to your permissions.
- 9:40
Scattered context comes in, grounded context comes out.
- 9:46
The obvious next question is, why can't we just do this with MCP, right? You could connect a Slack MCP, a Linear MCP, a GitHub MCP, and with that, all that data is accessible.
- 9:57
MCP is great at access, but access isn't understanding. A MCP hands the agent the raw results, and you know, you're now dependent on the agent to actually decide what to believe in.
- 10:10
You end up flooding the agent with irrelevant data, filling up the context window and, you know, overall context costs just go up. It also leaves a local agent to handle conflicts in data.
- 10:21
You know, your Linear MCP and your Slack MCP may come back with different results. You're just leaving the agent to make that decision somewhat ad hoc at this moment.
- 10:32
So back to the original problem I had earlier. This is the same file, same agent, but now we've connected the context agent. Uh, what we do here is, is we're currently prompting Unblocked to do some research on the ticket and provide that context to the agent.
- 10:49
So let's see that in action. Sorry about that.
- 11:02
So here we go. Uh, we're doing a very similar thing. We're fetching the Linear ticket, but you'll notice here that we're actually calling the Unblocked context engine. And what it's done here is actually it's found the relevant Linear postmortem, as well as a Slack conversation where we've had the entire discussion between the engineering teams.
- 11:19
And as part of that, we've returned a understanding, and that's now been provided to the agent as a summary. So the agent no longer has to actually reason from those documents.
- 11:31
And at this point, you'll notice here, the agent now has been updated.
- 11:41
Uh, the recommendation has gone from breaking and causing another issue to actually preventing a- another outage.
- 11:53
So the example I've shown here is issue ticket enrichment, but this context layer can actually go a lot further. Uh, for example, coding. Everyone here does, uh, coding with, uh, Cloud Code or Codex.
- 12:05
Using an Unblocked context engine to actually hydrate the agent plan goes a long way in terms of saving context and tokens. Uh, code review. It makes the PRs look as if they've been reviewed by an expert on your team.
- 12:19
Who doesn't like that? As well as surfacing the correct answers to your customer success team as well as sales.
- 12:27
In general, there are many instances where you might want an agent to have institutional and tribal knowledge of your organization.
- 12:37
Just wanted to leave you on this. I think this quote encapsulates what we're trying to solve at Unblocked. "The gap isn't intelligence, it's context."
- 12:46
So thank you. Uh, I'll be at Booth P16 along with the rest of my team if you guys have any questions.
- 12:53
There will be additional breakout sessions later tomorrow, I believe, that goes a lot more in depth about actually how the context engine works and, you know, how you can benefit from that.
- 13:03
Cheers. [applause] [outro jingle]