ACP gives coding agents and clients a shared JSON-RPC interface so users can bring different agents into tools such as Zed.
2
A minimal ACP agent needs to initialize, create sessions, handle prompts, and support cancellation.
3
Session updates let an agent stream model text, report tool-call progress, return file contents, send diffs, and manage terminals through the client.
Summary
Bennet Fenner builds a small TypeScript coding agent and connects it to Zed through the Agent Client Protocol. He first explains ACP as a JSON-RPC protocol between agents and clients, similar in purpose to MCP or LSP. The existing agent can read and edit files, and its model loop handles stateless API calls and tool results. Fenner then implements the minimum ACP interface: initialization, session creation, prompt handling, and cancellation. He adds session updates so streamed Anthropic output appears in Zed, then reports tool-call status and results for file reads. The client can proxy file-system operations, which lets an agent see unsaved editor buffers. Fenner later adds an ACP terminal tool and demonstrates a command running inside Zed. The live demo has duplicated output and an edit attempt that does not fully work, but the session shows the protocol messages and lifecycle needed to connect an agent to an editor.
Fenner says Zed wanted users to bring the agent of their choice into one editor interface. ACP is a JSON-RPC-based protocol, similar to MCP or LSP, through which agents and clients communicate using a shared interface. He describes it as open source and says agents can support it directly or through adapters that translate their native protocol. He names OpenCode and Cursor as examples with ACP modes, and says clients including JetBrains and Obsidian support it. The protocol is intended to let different coding agents work inside the same client without each client needing a separate integration.
The existing agent is a small model-and-tools loop
The starting code is a minimal TypeScript coding agent with two tools: reading a file and replacing old text with new text in an existing file. Fenner explains that model APIs are stateless, so each call includes the conversation so far. The model can either end its turn with text or request a tool such as read or write. The agent runs the requested tool locally, collects its result, adds that result to the conversation, and calls the model again. A handle-tool-call function gets the path, accesses the file system, and returns the result.
ACP sessions keep client conversations tied to agent state
The ACP implementation uses the TypeScript SDK and its agent interface. Initialization returns the protocol version and can advertise supported capabilities. Creating a session generates a random ID, creates the coding agent with the current working directory supplied by the client, stores it in an internal map, and returns the ID. Later prompt requests include that session ID and an array of content blocks, such as text or images. The agent looks up the matching state and passes supported text content to its existing prompt function. Fenner also adds cancellation as a simple optional feature.
Session updates make streamed model output visible in Zed
The first working agent could finish a prompt, but its output did not appear in Zed. Fenner passes the ACP connection and session ID into the coding agent. While reading the Anthropic stream, each text chunk becomes a session update associated with that session. ACP session updates are notifications that the client can receive outside a normal request-response exchange. The update type used here is an agent message chunk, which tells Zed that new model output is available. After rebuilding and restarting the agent, Fenner types 'Hello' and shows the response arriving as individual streamed chunks.
Fenner next reports file reads through ACP. Before running the read, the agent sends a session update of type tool call with a title, data that Zed can use for display, and an in-progress status. After the operation finishes, it sends a tool-call update that changes the status and includes the returned content. ACP can also proxy file-system operations through the client when the client advertises that capability. Fenner uses the client's read-text-file operation instead of the native file system API, because an editor may contain unsaved buffer changes that are not present on disk.
ACP can carry file diffs and client-managed terminals
For editing, Fenner applies the same pattern and sends a file diff through ACP. In the question period, he explains that ACP supports multiple content types, including diff content containing old and new text, with Zed performing the diffing. He then uses the agent's read and write abilities to add a terminal tool. The client can advertise APIs for creating and managing terminals, which gives the agent more interactive behavior. In the live demonstration, the agent runs 'sleep five ls'; Zed shows the terminal waiting, then displays the command output.
The demo does not work perfectly. Fenner sees duplicated output while testing the file read, and the edit demonstration runs into a connection problem that he does not debug during the session. He still gets the terminal example working and is explicit that the demo code is agent-generated and should not be used in production. His final transport note is that ACP currently works over standard input and output. He says JetBrains contributors are working on a remote transport.
"The client can provide a file system capability, and if it does, we can proxy those file system tool calls over ACP."12:25
Who should watch
You are building a coding agent and need to connect it to an editor without writing a separate integration for every client.
Your agent already has a model loop and tools, but you need to understand ACP initialization, sessions, prompts, and session updates.
You work on an editor or agent client and want to see how streamed text, tool progress, file diffs, and terminals travel across the protocol.
