中文
AI Engineer World's Fair

18 minutes from an empty file to an ACP agent that reads and writes files and opens a terminal

Building an ACP-Compatible Agent Live — Bennet Fenner, Zed · Bennet Fenner

18 min
AgentAI Coding

18 min total·Actually worth watching closely: ~9 min·3 must-watch clips

Orange = the 9 minutes worth watchingFor the rest, the guide is enough
Segment guide · 8 segments
  1. 0:14 2:40Listen

    Why an editor vendor is the one defining this protocol

    After the flood of command-line coding agents, the editor side needed one universal way to plug them in. The speaker likens ACP to a language server protocol for agents: an open JSON-RPC convention that lets any agent talk to any client.

    ACP isn't solving a model capability problem — it's solving the repeated work of rewriting an integration for every agent you add.

    Mostly the speaker standing and giving the background, with the screen parked on the title slide; nothing is lost listening to the audio on a commute.▶ Jump to 0:14
    Speaker · Bennet Fenner
  2. 2:40 4:42Listen

    Every coding agent is really the same loop

    The model interface has no memory of its own — each turn you resend the whole conversation. The model either replies with text and ends the turn or asks to call a tool; you run it locally and feed the result back to keep the loop going. The speaker stresses that a working agent needs just two tools: read a file, and edit a file by giving a path, the old text, and the new text that replaces it.

    It strips the mystique off the term 'coding agent' — it's one loop plus two tools; everything else is peripheral engineering.

    This is the conceptual skeleton; the screen only holds a short tool definition, so hearing how the loop turns is enough.▶ Jump to 2:40
    Speaker · Bennet Fenner
  3. 4:42 7:30Skim

    Four methods and your agent speaks ACP

    Switching to the official TypeScript library, the agent only has to do four things: answer the handshake with the protocol version it supports and its own capabilities, authenticate (skipped here), generate a session ID bound to the working directory when a new session starts, and take the prompt's content blocks and drive the tool loop — plus support for cancellation.

    Adoption costs far less than you'd expect — four methods, plus the convention that it can be interrupted.

    The screen shows method stubs getting filled in one after another; the structure matters more than the details. Skim each method name and the one thing it's responsible for, and follow the audio.▶ Jump to 4:42
    Speaker · Bennet Fenner
  4. 7:30 9:20Watch

    First run: messages arrive, but the UI is empty

    The debug view shows the client sending a new-session request, the agent answering with a session ID, and then the prompt coming in. Yet nothing shows in the UI, because the agent never pushes the model's output back. The fix: on the stream's text event, push out a message chunk with the session ID for every chunk received.

    Not a single character in the UI appears on its own — the agent has to push it to the client chunk by chunk.

    Raw protocol messages scroll on the left while the chat UI goes from blank to filled on the right; that before-and-after only works if you watch.▶ Jump to 7:30
    Speaker · Bennet Fenner
  5. 9:20 13:00Watch

    Report a tool call twice, and let the client compute the diff

    A tool call is two steps in the protocol: announce it at the start with a title, the metadata the UI uses for icons, an in-progress status, and the code locations involved; then send a second message writing the status and result back. File edits work the same way — the agent only sends the old text and the new text, and the client decides how to diff and render it.

    The agent doesn't build UI, it only describes what happened — everything about presentation belongs to the client.

    Code is written and the effect shows up in the UI immediately: tool call entries appear with icons, file edits render as a red/green diff. The mapping between code and presentation is the point of this stretch.▶ Jump to 9:20
    Speaker · Bennet Fenner
  6. 13:00 14:30Watch

    Read and write working, with a bug picked up along the way

    The file-read call already displays properly, but a connection issue makes the output show up duplicated. After debugging live, the same pattern is applied to write results back for edit file, and the agent finally inserts a comment into a file. One detail comes up here: reading through the protocol's file-read channel lets the agent see changes not yet saved in the editor.

    Reading files through the client rather than straight off disk is the only way to see what the user is editing right now but hasn't saved.

    Both the duplicated output and the correct behavior after the fix show up in the UI; skipping ahead means missing the symptom itself.▶ Jump to 13:00
    Speaker · Bennet Fenner
  7. 14:30 16:05Watch

    Having the agent install a terminal for itself, from the docs

    Since the agent can already read and write, it's asked to add a terminal tool to itself straight from the protocol docs — the generated code compiles, and a sleep command then runs with its output scrolling live in the editor's terminal panel. The terminal capability in the protocol is advertised by the client, which creates and manages terminals on the agent's behalf.

    Once read file and edit file are in place, the agent can extend itself; the capability mechanism lets the client take over heavyweight resources like terminals.

    From the request through code generation, compilation, and scrolling command output, the whole bootstrap is one continuous on-screen sequence — a text retelling loses it completely.▶ Jump to 14:30
    Speaker · Bennet Fenner
  8. 16:05 18:03Listen

    Q&A: the ecosystem today and how the transport works

    Today there are adapters that translate existing agents into ACP, and agents with ACP mode built natively into their command line; on the client side there are around forty implementations, covering mainstream IDEs and note-taking apps. Transport currently runs over standard input/output, with a remote transport being worked on by an outside team. The speaker also warns: the demo code is all agent-generated, so don't take it to production.

    There's a real ecosystem behind the protocol, but the cross-machine remote case isn't settled — for now it's local inter-process communication only.

    Pure Q&A with nothing to look at; if you care about ecosystem maturity and adoption risk, listen through this before deciding whether to integrate.▶ Jump to 16:05
    Speaker · Bennet Fenner