A deep dive into Alex Hancock’s talk at MCP Dev Summit North America 2026
Alex Hancock opened his talk at MCP Dev Summit with a couple of questions for the audience.
“How many people in the room have an idea for how MCP or agents could work better?”
Nearly every hand went up.
“Of those, how many have a project they can contribute to, one with real users, where they could test that idea and ship something quickly?”
A lot of hands went down.
That gap, he said, is exactly what he came to talk about.
Hancock is a software engineer at Block, a core maintainer of Goose (Block’s open source AI agent, now under the Agentic AI Foundation), and a maintainer of MCP’s Rust SDK. His talk was a bit unusual for a tech conference: a genuine invitation:
“Come build your experimental MCP ideas here. We’ll ship them. Real users will try them. And we’ll all figure out together what actually works”.
Watch the full talk here.
Why a Permanent Agent Project Still Makes Sense
Before getting into features, Hancock addressed a question he said any honest agent team has to wrestle with: given that anyone can generate a working agent in minutes, why maintain one as a serious long-term project at all?
His answer came down to four things:
- Performance and stability: the core agent loop needs to be tight and predictable, and that takes sustained engineering effort.
- Interoperability: a genuine commitment to open protocols, not just the ones that happen to benefit its creator.
- Willingness to experiment: model capabilities are shifting month to month, and a maintainer group that questions its own assumptions and moves fast is a different kind of asset.
- Governance: Hancock was direct about this one. He doesn’t think it would be a good world if all high-quality agent implementations were locked inside proprietary products tied to single companies’ models. Open source implementations that work with any model and interoperate with any open standard serve a function nothing else can.
Goose, now donated to and governed by the Agentic AI Foundation, is Block’s attempt to fill a specific gap. There are tens of thousands of MCP servers, but very few complete open source hosts that bring a client, server connections, and all the interactions between them into one coherent project.
Code Mode: Using Code Instead of Neural Networks for Control Flow
The first feature Hancock walked through addresses one of the subtler inefficiencies in how agents currently use tools.
Take a prompt like: find database errors in log files from the last hour. In the traditional approach, the agent lists files, reads each one, passes the entire content to the model, and filters for relevant lines. If those files are large, you might send 50,000 lines through the model to get 240 lines back, burning tokens and using a neural network as a control flow primitive, one of the most expensive resources available, to do what a for loop does for free.
Code mode changes this without changing the underlying tools. The same MCP servers are connected, the same tools exist, but instead of making individual tool calls and passing intermediate results to the model, the agent generates a small TypeScript program that handles the logic itself. The program runs in a sandbox, loops over the files, filters for errors, and returns the result. The model only ever sees the final 240 lines.
ACP: Standardizing the Other Half of the Agent Interface
MCP standardizes how agents connect to external systems. But there’s a gap on the other side: the interface where clients tell the agent what to do. Every agent currently has its own proprietary API for this, and none of them interoperate.
Goose has adopted the Agent-Client Protocol (ACP) as its answer. Just as MCP created a standard for tool connections, ACP standardizes how clients connect to agents, meaning a diverse ecosystem of interfaces can emerge independently of any specific agent. Hancock demonstrated four different ACP clients driving the same Goose instance simultaneously: a new terminal interface, an open source terminal called Toad, a brand-new Goose desktop app, and the Zed code editor. In Zed, the integration streamed in real time, as the agent opened files, new tabs appeared in the editor.
The next step is HTTP support for ACP, which would let client and agent run on entirely separate machines. Combined with remote MCP servers, every piece of the stack could be positioned wherever makes sense, made possible by open protocols rather than proprietary APIs.
MCP Apps: Experimenting at the Edge of the Spec
Goose adopted MCPUI (the precursor to MCP apps) early and rough, because the team wanted to see what happened when you put visual interfaces inside an agent. That early usage helped the concept sharpen its implementation, and it eventually became a formal MCP extension partly because projects like Goose served as real-world test environments.
The most forward-looking demo was something Goose is incubating that isn’t yet in the official spec: sampling from the front end of an app itself. Standard MCP sampling lets a server request a model completion through the host. Goose has extended this so the app’s UI can do it directly: the app sends a sampling request through the bridge to the Goose host, which routes it to the model and returns the result. The app stops being a passive display layer and becomes an intelligent component in its own right. Hancock gestures at where this could go: multimodal apps that interpret images, audio, or video directly within the interface. Goose’s live implementation is already informing the conversations about whether to formalize this in the spec.
The Invitation
Goose’s value as a proving ground comes from one thing: real usage, at real scale. Ship an experimental MCP feature there, and people actually use it. When you go to the MCP core maintainers with a proposal, you’re not presenting a paper spec, you’re presenting a working implementation with real users behind it.
“That’s the offer. Come build something useful. We’ll ship it.”
Goose is open source and governed by the Agentic AI Foundation under the Linux Foundation. You can find it, contribute to it, and learn more at aaif.io.
