Agent Client Protocol: The Missing Language Between Coding Agents and Editors
A coding agent is only useful where you can actually work with it. Today, that simple requirement can mean a surprising amount of integration code: one connection for an editor, another for a different agent, and another when either product changes its API.
Agent Client Protocol (ACP) proposes a common language between these two sides. The client is the application a developer uses; the agent handles the coding task. The ambition is straightforward: make it easier for clients and agents to talk without every pairing requiring a bespoke integration.
That does not make every agent interchangeable. It does make interoperability a much more interesting question than which model has the best demo.
Why this matters now
On November 3, GitHub announced that GitHub Copilot is available in JetBrains Air, JetBrains’ agent-oriented environment. Its integration uses ACP. GitHub describes cloud tasks running in isolated environments and notes limitations around usage analytics and spending controls for that integration.
This is a concrete example of an agent appearing in another company’s environment. It is not proof that every feature of every agent works identically everywhere. Authentication, available capabilities, user experience and deployment remain important details.
What the protocol actually does
The ACP introduction describes a structured exchange between an editor or application and an agent. An integration can create sessions, send prompts, receive progress and handle interactions such as permissions. That gives a client a common vocabulary for presenting an agent’s work to a developer.
The default local transport uses JSON-RPC over standard input and output. ACP’s documentation describes remote-agent support as work in progress; a specific cloud integration should not be confused with a guarantee that remote access is fully standardized across implementations.
The distinction matters. A protocol defines how participants communicate. It does not dictate a model’s reasoning quality, grant safe access to a repository, or magically align the features and commercial terms of different providers.
The developer experience is the real test
A shared protocol could reduce the cost of experimenting. A team might evaluate an agent inside an existing client rather than adopt an entirely new environment just to try it. Editor builders can focus more on the workflow; agent builders can reach compatible clients without starting every integration from zero.
Those are possibilities, not promises. Compatibility needs to be tested at the feature level. Before introducing an agent, I would check:
- Capabilities: Which session, file and tool interactions does this client actually support with this agent?
- Permissions: What can the agent read, run or change, and where does a human approve an action?
- Data and execution: Where does code go, where do commands run, and what logs are retained?
- Operations: How are authentication, cost, updates and failures handled?
The best interface is not simply the one with the fewest clicks. It makes the agent’s actions visible and gives developers useful control over them.
A standard is a starting point
The ACP specification and source are public, which makes the protocol something developers can inspect and discuss. Its value will depend on real implementations, clear capability handling and the willingness of projects to keep compatibility working as their products evolve.
The bigger shift is architectural. Coding agents are becoming components in a developer’s environment rather than entire environments unto themselves. If common interfaces make those components easier to replace, compare and govern, developers gain choices. If not, a protocol badge alone will not create them.
For another perspective on agent workflows, read Robin and Open SWE: two approaches to software engineering agents.
