Alex Hancock

Alex Hancock is a software engineer and maintainer of Goose and the MCP Rust SDK. His work focuses on the interfaces that let independently developed applications, agents, tools, and models work together. At Block, his career included Square and Cash App products and a shared GraphQL platform before he moved into open-source AI infrastructure.

Hancock’s earlier platform work included helping unify two separate GraphQL implementations into one graph, giving applications a shared interface to data from different services. In March 2025, he described eight and a half years at Block, including four years working on its GraphQL platform. His account of growing that platform emphasizes the work required to make adoption practical: data producers need an easy way to contribute, or they will find another route to applications and leave client developers managing incompatible APIs. A shared interface succeeds when contributing to it is easier than working around it.

He joined Goose in November 2024 to help with a particular workstream, then made it his full-time focus after seeing what the agent could do. Goose began as an internal Block project, became open source, and was subsequently donated to the Agentic AI Foundation. Hancock’s work expanded into maintaining the MCP Rust SDK and contributing to the Agent Client Protocol, or ACP. In his recorded ACP talk, he identified himself as a software engineer at Block; that affiliation describes his role at the time of the talk.

Hancock sees Goose as both a product that must remain stable and an open proving ground for agent infrastructure. Maintainers can test protocol ideas with users while building implementations that work across model providers and open standards. He favors governance beyond a single company’s proprietary product, allowing this shared infrastructure to develop through participation from multiple organizations.

One agent, many clients

Goose’s original terminal interface and its later Electron desktop application used different paths to reach the agent. Session management, extension loading, and streaming therefore required work in both places, while outside developers lacked a standard way to connect. Hancock’s Goose 2.0 architecture account explains the move toward ACP as a common interface for terminal applications, desktop clients, and editors. In April 2026, the ACP server was ready, a new TypeScript terminal interface was in beta, and the desktop rewrite remained underway. The goal was one agent core that clients could use without reverse-engineering its internals.

His ACP talk explains the distinction between the two protocols he works with: MCP connects agents to tools and data; ACP lets client applications assign tasks to agents and receive their responses and progress. ACP originated with Zed and JetBrains. Hancock and the Goose team saw uses beyond editors because the protocol contains relatively few editor-specific assumptions.

ACP uses JSON-RPC messages to establish connections with agreed capabilities and create sessions. Within a session, clients send user messages; agents return text or other media, report tool activity, and request permission for actions. Custom methods allow developers to experiment beyond the standard. Hancock argues that recurring extensions across clients and harnesses could reveal which capabilities belong in the protocol itself, letting practical use guide standardization.

He demonstrated Zed and a Poolside AI terminal client asking Goose to explain the same single-file HTML project. Both received text and tool-call information through Goose’s ACP implementation. The example makes the architectural benefit concrete: supporting another client does not require another integration inside the agent.

The Goose team also specified an HTTP transport with a WebSocket upgrade to carry the same messages and protocol semantics over a network. Hancock demonstrated a small client sending instructions to Goose over a network connection on his own machine. The demonstration showed remote transport working locally; cloud deployment was a possible use, rather than what the demonstration established.

Remote ACP gives developers more freedom to place the four parts of an agent system: the client, the harness that runs the tool-calling loop, the tools, and the model. Combined with remote MCP tools and model endpoints, it allows those components to run together or on separate machines. Hancock’s ambition is a wider client ecosystem, including personal interfaces, domain-specific applications, and company-customized clients that can control different harnesses. He argues that users’ ability to switch clients would encourage developers to compete on the quality of the experience.

Making tool orchestration and agent behavior programmable

Hancock collaborated with Mic Neale on Goose’s Code Mode implementation, building on approaches advanced by Cloudflare and Anthropic. Code Mode exposes connected MCP tools through a generated JavaScript interface and runs model-written code in the embedded Boa engine. Calls are routed back to Rust and the underlying MCP servers.

This changes how an agent handles a sequence of tool operations. A program can call a tool, process its result, and pass selected information into another call without returning every intermediate result to the model. Tools can also be discovered progressively instead of placing all their definitions in the initial context. Hancock presents Code Mode as an experiment to evaluate, with potential benefits for token use, large tool collections, and reducing unnecessary exposure of sensitive intermediate data.

His lifecycle-hooks guide gives users another way to shape the agent loop: ordinary shell scripts triggered by lifecycle events. Examples include formatting edited files automatically, announcing a failed tool call, and making a desk light indicate that the agent is working. These mechanisms connect agent activity to existing workflows and give people signals about when their attention is needed.

His February 2026 MCP Apps sampling draft explores interaction inside embedded application views. It proposes allowing those views to request model completions from their host, supporting specialized chat interfaces and AI-assisted forms. The proposal includes host-controlled permissions and limits; it should be understood as a draft, rather than an established capability.

Hancock also emphasizes human attention when several agents run concurrently. People need to know which agent requires input while leaving the others to continue working. That concern gives his infrastructure work a practical purpose: shared protocols let developers choose and build interfaces, while progress reporting, permission requests, and programmable hooks help users understand and direct what their agents are doing.