Overview
Alex Hancock argues that the agent ecosystem has strong runtimes but fragmented ways of controlling them. Many frameworks expose proprietary interfaces, and some work with only one client—an arrangement he compares to requiring a different browser for every website. MCP has already demonstrated how a widely adopted standard can create an ecosystem by giving agents a common way to invoke tools and access external resources. However, the reverse direction remains under-standardized: clients still lack a common protocol for assigning work to agents, receiving progress updates, reviewing tool activity, and handling permission requests. Hancock presents the Agent Client Protocol, or ACP, as that missing layer. Originally developed through collaboration between Zed and JetBrains, ACP uses JSON-RPC to connect clients with agent runtimes, organize interactions into sessions, exchange multimodal messages, and report execution events. Its extension mechanism allows implementations to experiment with custom methods that may later become shared standards. Demonstrations show different graphical and terminal clients controlling the same Goose runtime, while new HTTP and WebSocket transports extend the model beyond local standard I/O. Hancock concludes that interoperability across clients, harnesses, tools, and models could create a competitive client market, improve user experience, enable specialized interfaces, and make every component of the agent stack independently deployable.
Sections
Core Terms
The protocols and architectural components used in the argument.
- Model Context Protocol (MCP): a shared protocol through which agents invoke tools, take actions in external systems, and read resources or data.
- Agent Client Protocol (ACP): an open protocol that allows clients to assign work to agent runtimes, receive results and execution updates, observe file or tool activity, and mediate permissions.
- Harness: the software component that executes the agent's tool-calling loop.
- Session: an ACP interaction context in which clients send user messages and agents return content, updates, tool events, or requests.
- Transport: the communication mechanism carrying the protocol, including local standard I/O and remote HTTP with a WebSocket upgrade.
Strategic Implications
Higher-level conclusions implied by the protocol design and demonstrations.
- ACP and MCP form complementary control planes: ACP carries intent from clients toward agents, while MCP enables agents to act through tools and external systems.
- Standardizing the boundary between clients and runtimes can shift product differentiation away from proprietary integration and toward user experience, specialization, and trust.
- The custom-method mechanism treats fragmentation as an input to standardization: repeated proprietary extensions can reveal the next capabilities that belong in the shared protocol.
- Transport parity between local and remote operation reduces deployment topology to a configuration choice rather than an application-level redesign.
Key Comparisons
Contrasts that clarify ACP's role and the benefits of interoperability.
- MCP standardizes how agents interact with tools and resources; ACP standardizes how clients direct and observe agent runtimes.
- Proprietary interfaces bind a runtime to particular clients, while ACP allows one runtime implementation to serve many interchangeable clients.
- Standard I/O supports local agent communication, whereas HTTP and WebSocket transport extend the same protocol semantics to remote and cloud deployments.
Memorable Quotes
Verbatim statements that capture the speaker's central argument.
- وأقوى ميزة في MCP ليست في حد ذاته، بل في أن الجميع يستخدمونه.
- هذا لن ينجح ببساطة. لم تكن لم تكن لتملك شيئاً مثل الويب المفتوح لو كان هذا هو الواقع مع المتصفحات.
- تنفيذ واحد على جانب الحزمة ويمكنك الآن استخدام أي عميل، أليس كذلك؟
- إن التوافق على المعايير والتأكد من وجود طرق نقل جيدة هو ما سيسمح لنا بتحريك كل أجزاء حزمة الوكلاء هذه.
- سيبدأ الناس بالتنافس على جودة تجربة المستخدم.