Goose and the ACP Protocol: Why Agent-Editor Integration Is About to Change

By Prahlad Menon 5 min read

By now you’ve probably seen Goose. Block (Jack Dorsey’s company) open-sourced it in late 2024, it’s at 35K+ GitHub stars, and the viral posts about it have been circulating for months. If you want the feature overview, the documentation is excellent.

This post isn’t that. It’s about the less-covered thing Goose introduced: Agent Client Protocol (ACP) — and why it matters more than the agent itself.

The Problem ACP Solves

The Block engineering team described the problem directly in their blog post launching ACP:

“IDE-integrated agents like Cursor have an AI agent baked into the code editor. However, this creates vendor lock-in where you must use their specific agent with their specific editor. If I preferred VS Code as an editor and Claude Code as my agent, I’d be out of luck.”

The existing solutions all have fundamental limitations:

  • IDE-baked agents (Cursor, Windsurf) — powerful but you’re locked to their editor
  • Terminal CLI agents — work, but you lose rich UI and always-there context
  • IDE extensions/plugins — fragile; agent updates break them constantly. Goose ships twice weekly; maintaining a VS Code extension in sync with that pace is practically impossible

The result: developers who want to use their preferred editor and their preferred agent have to context-switch between three windows constantly — editor, agent, browser — breaking flow state.

What ACP Is

Agent Client Protocol is an open standard developed by Zed Industries that defines how any AI agent communicates with any supporting editor. Think of it as MCP but for agent-editor integration rather than agent-tool integration.

The key distinction from IDE plugins: ACP doesn’t require the agent to know anything about the editor’s internal APIs. The agent and editor communicate through a standardized protocol. The agent evolves at its own pace; the editor evolves at its own pace; neither breaks the other.

Agents that support ACP today:

  • Goose (Block)
  • Claude Code (Anthropic)
  • Codex CLI (OpenAI)
  • Gemini CLI (Google)
  • StackPack

Editors that support ACP today:

  • Zed
  • Neovim
  • Marimo (data science notebooks)

The practical result: you can run Claude Code inside Zed with the same depth of integration as if Anthropic had built a Zed plugin — without Anthropic maintaining a Zed plugin.

What This Means for Multi-Agent Workflows

This is where it gets interesting in the context of tools we’ve covered recently.

We wrote about SoulForge — a full AI coding environment with per-task model routing, where Opus handles planning, Sonnet handles coding, and Haiku handles cleanup. That’s a single-agent-orchestrates-sub-agents pattern.

ACP opens a different pattern: any orchestrator can dispatch work to any specialized coding agent. Goose could use Claude Code for Anthropic-optimized tasks, Codex for OpenAI-native tasks, and Gemini for multimodal reasoning — not through a proprietary API but through a standardized protocol that both sides implement independently.

The viral posts about Goose supporting ACP frame it as “you can use Claude Code and Codex as providers.” The more accurate framing is: ACP is creating a marketplace of interoperable coding agents, and Goose was the first to implement it.

The Linux Foundation Move

In December 2025, the Linux Foundation announced the Agentic AI Foundation (AAIF), anchored by three contributions: MCP (Anthropic), Goose (Block), and AGENTS.md (OpenAI).

The AGENTS.md contribution is particularly relevant here — it’s a simple standard that gives AI coding agents consistent project-specific guidance across different repositories and toolchains. It’s the agent-facing complement to ACP’s editor-facing integration.

Three major AI companies pooling their agent infrastructure standards into a neutral foundation is not a typical open source story. It’s an indicator that the interoperability layer for AI agents is being taken seriously at an industry level, and that Goose is positioned at the center of it.

Goose Itself: The Practical Details

For completeness, the agent is genuinely good:

  • 25+ LLM providers — Anthropic, OpenAI, Google, Groq, DeepSeek, Ollama, LM Studio, GitHub Copilot, Azure OpenAI, Bedrock, and more. Swap in one command.
  • MCP for extensions — file ops, web scraping, memory, browser automation via any MCP server
  • Multi-model configuration — use different models for different task types within a session
  • Context auto-trimming — keeps token costs manageable on long sessions
  • Desktop app + CLI — macOS, Linux, Windows
  • Custom distributions — build your own Goose with preconfigured providers, extensions, and branding via CUSTOM_DISTROS.md

One note from the docs: Goose “relies heavily on tool calling capabilities and currently works best with Claude 4 models.” The Berkeley Function-Calling Leaderboard is their recommended guide for model selection. This is honest and useful — not all 25 providers will perform equally for complex agentic tasks.

The Bigger Picture

MCP solved the agent-tool integration problem. ACP is solving the agent-editor integration problem. AGENTS.md is solving the agent-project-context problem. These three standards — all open, all being contributed to neutral foundations — are the plumbing for a world where AI coding agents are genuinely interoperable.

Goose is the agent that’s been most central to developing and advocating for this infrastructure. That’s the angle the viral posts are missing, and it’s the more interesting story than the feature list.

Apache 2.0. GitHub → | ACP Spec → | Docs →