ena pragma
·10 min read·ai-infrastructure · protocols · context-engineering

Two talks, two missing layers: how an AI agent gets its orders, and what it knows once it starts

A cited read of two AI Engineer talks: the ACP protocol for driving coding agents, and why agents fail on context, with one origin claim corrected and two numbers kept honest.

Contents

Two talks from the same conference, AI Engineer World's Fair in San Francisco this summer, describe two different gaps in how AI coding agents get used. One is about plumbing: how an editor or an app tells an agent what to do and hears back. The other is about knowledge: what the agent actually knows about your codebase and your company once it starts working. Neither speaker mentions the other's problem. Read together, checked against 21 written sources beyond the transcripts themselves, they describe the same shift from two angles: agents are becoming more autonomous faster than the tooling around them is becoming ready for it.

#Layer one: telling the agent what to do

The first talk is by Alex Hancock, an engineer at Block, the company behind Cash App and Square, and a maintainer of Goose, Block's open-source agent, and of the Rust SDK for the Model Context Protocol. His subject is ACP, the Agent Client Protocol.

The problem it solves is simple to state. Every code editor that wants to drive an AI agent builds a custom integration for that agent, and every agent implements each editor's private API. Hancock's version of the analogy is that it would be like needing a different browser for every website. The protocol's own site reaches for a more precise precedent, and it is the better one: the Language Server Protocol. Microsoft's 2016 standard let one language-analysis backend work with any editor, and it ended the era of every editor writing its own autocomplete for every language. ACP is explicitly modeled on that. It is not a new idea searching for an analogy; it is a known mechanism, proven once already in developer tooling, being applied one layer up.

Mechanically, ACP is JSON-RPC. For a local agent, the editor runs the agent as a subprocess and they talk over standard input and output. For a remote agent, there is an HTTP transport with a WebSocket upgrade, which the official documentation still describes as "a work in progress" as of this week, matching Hancock's own framing that it is "just landing now." The spec allows vendor-specific extensions under underscore-prefixed method names, so a feature one editor needs can be tried in the wild before it is proposed for the core.

Hancock describes the agentic stack as four movable parts: the client (your editor or app), the harness (the program running the tool-calling loop), the tools (usually reached through MCP), and the model. With ACP covering client to harness, MCP covering harness to tools, and models already served remotely, any of the four can run on a different machine from the others. That is the actual argument for the protocol: not convenience, but the freedom to move the expensive or sensitive parts of an agent somewhere else without rewriting the integration.

#One origin claim, corrected against the primary sources

The talk says ACP "came from the editor companies," that "the Zed folks and the JetBrains folks teamed up and proposed a standard." Checked against Zed's own site and blog, that overstates JetBrains' role at the start. Zed's ACP page reads "Created by Zed, grown by a community of editors and agents." Zed's own account of the JetBrains partnership says ACP launched with Google and the Gemini CLI, and that JetBrains joined later, announcing in October 2025 that it would co-develop the protocol going forward. The corrected timeline: created by Zed with Google's Gemini CLI, joined by JetBrains roughly ten months before this talk, and by now shipped across JetBrains' IDE line. Zed also maintains a public ACP registry of editors and agents; at the time of this check it lists Zed, JetBrains IDEs, VS Code, Emacs, Neovim, Obsidian and marimo on the editor side, and Claude Code, Cline, Amp and Augment Code among the agents. That list changes, so treat any count as a snapshot.

One more precision worth having. Hancock says Goose was "donated to the Linux Foundation." True in effect, more specific in fact: in December 2025 the Linux Foundation formed a sub-foundation, the Agentic AI Foundation, and Goose was a founding contribution to it alongside Anthropic's MCP and OpenAI's AGENTS.md, with platinum members including AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. The talk treats Goose and MCP as separately governed. Since December they share a foundation.

#How ACP sits next to MCP and A2A

Three protocols are in play and the boundaries are consistent across sources. MCP connects an agent to tools and data. ACP connects a client, meaning a human-facing app, to an agent. Google's A2A connects one agent to another, for delegation. The MCP project's own discussion thread on the subject, and an independent comparison, both describe A2A and MCP as different layers rather than competitors. The honest gap: Hancock's talk never mentions A2A at all, so that three-way map is built from the MCP ecosystem's sources, not from anything he said. Do not read it as his claim.

#Layer two: what the agent knows once it starts

The second talk is by Brandon Waselnuk of Unblocked, a company that sells a context engine for engineering teams. His framing is that an experienced engineer is valuable because of accumulated context: what shipped, what broke, who reviews what, the Slack decision that quietly overrode the document. A fresh agent session has none of that, and the cost compounds as agents move up an autonomy curve, from tab-complete, to supervised loops, to parallel agents that generate a review tax, to background agents that have to find their own context with nobody watching. His line: "The gap is not intelligence any longer. It's context."

The strongest claim in either talk is one Waselnuk borrows from radiology. "Satisfaction of search" is the documented tendency to stop looking once you have found one abnormality on an image, and so miss the second one. Unblocked has a separate written piece on it, and the lineage checks out independently of the vendor: a peer-reviewed 2010 study by Fleck and colleagues, extending the effect outside medicine to airport baggage screening, traces it to Tuddenham's 1962 work. That is a 64-year-old finding, not the "fifty-year-old" one Unblocked's own blog rounds it to. Applied to agents: an agent that finds one plausible answer stops. In retrieval systems specifically, similarity ranking rewards the first plausible chunk, not the most authoritative one, so the retrieval step itself can manufacture premature satisfaction.

A second, independent body of work converges on the same failure from a different direction. Information foraging theory, from Pirolli and Card at PARC in the 1990s, models how people navigate information by following the strongest local scent. An agent doing the same will stop at the nearest strong signal, which is not always the right one. Neither talk names it; it is worth knowing because it shows the borrowed radiology term is one member of a family of findings, not a clever one-off.

Two of Waselnuk's own labels need a flag. He calls the practice of hand-writing markdown context files for agents the "curated context trap," and describes an "MCP plateau" where wiring more tools to an agent stops helping. Neither phrase appears in Unblocked's published writing or anywhere else found in this research; they are the speaker's framing on stage, not established terms. The problems underneath them are real and documented under other names. Hand-maintained context rots like any other document, and Chroma Research's 2025 "Context Rot" study, testing 18 frontier models, showed reasoning degrading with input length well before the context window fills. Anthropic's own engineering guidance, from a company that does not sell a context engine, arrives at the compatible conclusion: treat context as a finite, degrading resource and aim for "the smallest possible set of high-signal tokens." More context is not the fix. The right context is.

#Two numbers, kept honest

Waselnuk reports a benchmark task consuming "about 21 million tokens" without a context engine and "10.8 million tokens with it," which he rounds to 50 percent fewer tokens, with faster triage and better answers. No published version of that figure exists on Unblocked's site or elsewhere, and the talk gives no methodology: which task, which model, how "without context" was set up. It is a single self-reported vendor result. It may well be true. It is reported here as exactly that, and not as "cuts tokens in half," which is how it will read if nobody keeps the attribution attached.

The talk's title does similar work. "You're absolutely right!" is the familiar sound of a coding agent agreeing with a correction before checking it. The talk uses the phrase as an opening and closing hook and never actually connects it to context. Independent writing on AI sycophancy treats it as a training-driven bias, models rewarded for agreeableness, rather than a context-availability problem. The title implies a link the content does not defend. The content is a solid argument about context engineering; the hook is marketing.

#Where the two talks meet, and where they do not

They agree without coordinating. Both describe coding agents moving from supervised, single-session tools toward longer-running, less-watched operation, and both argue the layer around the agent, protocol interoperability in one case and information supply in the other, has not kept pace. That is the whole overlap. ACP is about the control plane between you and the agent. Context engineering is about what the agent knows once it is running. In Hancock's four-part stack they are different seams, and neither speaker references the other. A synthesis beyond that is not in the sources, so it is not in this piece.

#Why this matters if you never open an editor

If you are choosing AI tooling for a team, the two talks give you two questions that cut through most vendor pitches. First: can this agent be driven from the tools we already use, or does it only live inside one company's app? A protocol like ACP is what makes the first answer possible, and it is real and shipping, with the caveat that its remote transport is still being finished. Second: what does this agent know about our work on day one, and how does that knowledge stay current without a person curating it by hand? Every vendor will say "we handle context." The satisfaction-of-search finding is the sharper test: ask how the tool avoids stopping at the first plausible answer, because a 64-year-old body of research says that is what searchers do by default.

We build and run agent infrastructure ourselves, and both seams described here are ones we work in. Nothing above is a claim about who is winning. It is a read of what two competent, interested speakers said, checked against what their own organizations and the underlying literature actually publish. The distance between the two was small this time, one overstated origin story and one unpublished benchmark, which is about as good as conference talks get.

#Sources

Keep reading