AI Engineer

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

3188 summary words 14 min summary Watch video

Start with the signal

14 min read

Summary

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: Building an Agent Client Protocol (ACP)-compatible coding agent is straightforward and enables any client to work with any agent through a unified JSON-RPC interface, demonstrated by live-coding a minimal TypeScript agent in ~15 minutes that can read/write files, stream tokens, and execute terminal commands.
  • Why it matters: ACP addresses fragmentation in AI coding tools by providing an open protocol (similar to LSP/MCP) that lets users bring any agent to any editor, with 40+ clients and multiple agents already supporting it—critical for anyone building agent tooling or workflows.
  • Best use: Watch the live demo to understand ACP implementation patterns, then reference agentclientprotocol.com for building your own agents or integrating into clients; useful for agent infrastructure work and understanding protocol-driven interoperability.

Executive Summary

Bennet Fenner from Zed demonstrates Agent Client Protocol (ACP), an open-source JSON-RPC protocol designed to unify the fragmented landscape of AI coding agents. The motivation: every major model provider (Claude, Codex, Gemini) built their own CLI agent with incompatible interfaces. ACP solves this by letting any agent talk to any client through a standard protocol—similar to how LSP unified language servers or MCP unified model context. Already adopted by 40+ clients including JetBrains, Obsidian, and Open Claw, with agents like OpenCode and Cursor offering native ACP modes.

The live demo builds a minimal but functional TypeScript coding agent from scratch using Anthropic's API. Starting with basic read_file and edit_file tools, Bennet incrementally adds ACP compliance: implementing initialize, new_session, prompt, and cancel_session methods; streaming token chunks via session_update notifications; emitting tool_call progress updates with status and content; proxying file system calls through ACP (so the agent sees unsaved editor buffers); and adding terminal execution capability. The agent works immediately in Zed with no special client code—just a config pointing to the agent script.

Key technical details: ACP uses standard I/O for transport (remote transport coming soon); sessions represent conversation threads with unique IDs; agents emit session_update notifications (not request-response) for streaming and progress; content types include text, diff, and others; clients can advertise capabilities like file system proxying or terminal management. The protocol is stateless at the model API level but stateful at the session level, with agents maintaining conversation history and tool-calling loops internally.

The demo culminates in 'vibe coding' where the agent modifies its own source code to add terminal tool support, then successfully executes shell commands. Despite minor connection duplication bugs during the live session, the core workflow is clear: implement four minimal methods, emit appropriate session updates, and leverage client capabilities. The entire demo code is agent-generated and will be published (with warnings not to use in production). This is practical protocol design—minimal surface area, clear extension points, and immediate real-world adoption.

Key Takeaways

  • Claim: ACP addresses the fragmentation problem where every model provider built incompatible CLI agents (Claude Code, Codex, Gemini CLI) by providing a unified JSON-RPC protocol. | Evidence: Bennet states 'last year was the rise of the AI coding agent...with every major model provider building' their own, and Zed asked 'how can we let users bring their agent of choice to our tool...through a unified interface.' The protocol has already achieved 40+ client implementations including JetBrains, Obsidian, and Open Claw, plus agents like OpenCode and Cursor with native ACP modes. | Caveat: No mention of MCP interoperability or whether adapters can translate between ACP and other protocols automatically; adoption is growing but not yet universal across all major tools. | Implication: If you're building agents or clients, ACP provides a production-ready path to interoperability without vendor lock-in; for Ken's agent ops work, this means you can swap LLM backends or editors without rewriting integration code. | Timestamp: 00:00-01:20
  • Claim: Minimal ACP agent implementation requires only four core methods: initialize, new_session, prompt, and cancel_session. | Evidence: Bennet walks through the TypeScript SDK interface: initialize returns protocol version and capabilities; new_session generates a random ID and stores agent state; prompt takes session ID and content blocks, runs the tool-calling loop, returns output; cancel_session handles cancellation. The entire implementation fits in a single file demonstrated live. | Caveat: The demo shows a TypeScript SDK; implementation complexity may vary in other languages. Remote transport is 'coming soon' from JetBrains team but currently limited to standard I/O. | Implication: Building custom agents is accessible—this is lower-friction than building custom LSP servers; Ken can prototype domain-specific agents (e.g., for content workflows or investment research) without heavyweight infrastructure. | Timestamp: 02:15-04:30
  • Claim: Real-time streaming and progress updates use session_update notifications rather than request-response, enabling responsive UIs without blocking. | Evidence: Bennet implements streaming by calling 'connection.send_session_update' on each text chunk from Anthropic's SDK: 'every time we get a chunk, we send what ACP calls a session update...notifications to the client that are not a usual request response.' Tool calls emit initial 'tool_call' updates with status 'in_progress', then 'tool_call_update' with final status and content. The Zed UI shows streaming tokens and live tool execution. | Caveat: The demo experienced duplication bugs during the live session, suggesting connection handling may need debugging in edge cases; no discussion of backpressure or rate-limiting mechanisms. | Implication: For operator UIs, this notification model enables non-blocking progress indicators and streaming output; Ken's agent dashboards can show live tool execution and intermediate results without polling. | Timestamp: 06:45-10:30
  • Claim: ACP proxies file system calls so agents see unsaved editor buffers, not just on-disk state—critical for real-world coding workflows. | Evidence: Instead of calling native 'fs.readFile', the agent calls 'connection.read_text_file' over ACP: 'if I have unsaved changes in my buffer, they're not actually on the file system, but the agent should still see them.' Clients advertise file system capability; if present, agents can opt into proxying. | Caveat: No details on how file system capabilities are negotiated or what happens if the client doesn't support it; unclear if there's fallback behavior or error handling. | Implication: This is a subtle but powerful feature for agent reliability—agents working on partially-edited code won't miss recent changes; Ken should ensure any agent clients implement file system capability to avoid stale-read bugs. | Timestamp: 09:00-10:00
  • Claim: Clients can advertise terminal management capability, letting agents create and control terminals through the protocol rather than shelling out locally. | Evidence: Bennet adds terminal tool support live: 'the client can advertise that it supports creating terminal and managing terminals for the agent.' The agent calls terminal APIs over ACP, and Zed displays a terminal running 'sleep 5; ls' with live output. The demo shows this working end-to-end despite connection issues. | Caveat: Terminal capability is optional and depends on client support; no discussion of security model (can agents run arbitrary shell commands?) or sandboxing. | Implication: For agent systems that need to orchestrate shell commands (builds, tests, deployments), this provides controlled execution with client-side visibility; Ken's automation workflows can surface terminal output in dashboards without custom logging. | Timestamp: 12:30-14:00
  • Claim: The agent successfully modified its own source code to add terminal support during the demo ('vibe coding'), demonstrating self-modification capability. | Evidence: Bennet prompts the agent with a prepared message explaining ACP terminal APIs, and the agent writes a new tool description, implements the terminal tool, and adds it to the agent's own TypeScript source. After restarting, the agent uses the new tool to execute shell commands. Bennet comments 'I'm vibe coding basically this terminal tool.' | Caveat: The demo code is 'all agent generated...please don't use it in production,' suggesting reliability/safety concerns; no discussion of how to validate or review agent-modified code before execution. | Implication: Self-modifying agents are now practical with minimal scaffolding; for Ken's R&D work, this opens meta-agent patterns (agents that extend themselves), but requires careful guardrails around code execution and rollback. | Timestamp: 13:00-14:30

Detailed Brief

Protocol Design and Ecosystem Adoption

  • Claims: ACP is an open-source JSON-RPC protocol for agent-client communication, analogous to LSP (Language Server Protocol) or MCP (Model Context Protocol); 40+ clients already implement ACP including JetBrains, Obsidian, and Open Claw; agents like OpenCode and Cursor have native ACP support; Adapters exist to translate agents' native protocols into ACP, enabling gradual adoption without breaking existing agents
  • Evidence: Bennet states 'it's a JSON RPC based protocol...similar to MCP or LSP' and points to agentclientprotocol.com for documentation; List of implementations shown in slides: 40 clients, multiple agents via adapters or native support; Open Claw described as 'a client and a server, a client and an agent'—demonstrating dual-role capability
  • Caveats: No discussion of versioning strategy beyond 'latest protocol version' in the demo; Unclear how ACP relates to or interoperates with MCP, despite the similar naming; Remote transport is under development by JetBrains team but not yet available—currently standard I/O only
  • Implications: ACP is production-ready for new agent projects; Ken can adopt it without being an early adopter; The adapter pattern means Ken's existing agents can bridge to ACP without full rewrites; For client-side tooling (dashboards, editors), implementing ACP once unlocks access to the entire agent ecosystem

Core Implementation Patterns

  • Claims: Minimal agent requires four methods: initialize (protocol version/capabilities), new_session (ID generation and state setup), prompt (tool-calling loop), cancel_session (cleanup); Agents are stateful at the session level but interact with stateless model APIs by appending conversation history on each call; Tool calling loop follows standard pattern: call model API, handle end_turn or tool_call response, execute tool locally, send result back to model, repeat until end_turn
  • Evidence: TypeScript code shown implementing each method; initialize returns '{protocolVersion: "latest", capabilities: {}}'; new_session generates random ID and stores agent instance in map; Bennet explains 'model APIs are stateless...you attach some conversation up to this point...then we get a message from the model' in the tool-calling loop explanation; Demo shows read_file and edit_file tools with path/old_text/new_text parameters, standard tool call handling extracting arguments and returning results
  • Caveats: TypeScript SDK used in demo; other language SDKs may differ in API surface; Authentication is 'irrelevant' in this demo since it uses hardcoded API key—no coverage of multi-user or secure key management; Error handling not demonstrated during live coding; unclear what happens on malformed requests or tool failures
  • Implications: Building custom agents is low-ceremony—closer to writing a REST API than complex infrastructure; Session management is trivial (generate ID, store map), so Ken can run multiple concurrent agent sessions without heavyweight orchestration; The tool-calling loop is model-agnostic; switching from Anthropic to OpenAI or other providers requires only swapping the SDK call, not rewriting ACP logic

Streaming and Progress Updates

  • Claims: Streaming uses session_update notifications of type agent_message_chunk, sent on each token from the model; Tool execution emits two session_updates: initial tool_call (status: in_progress, title, metadata) and final tool_call_update (status: completed/failed, content); Notifications are asynchronous and do not require request-response pairing, enabling non-blocking UIs
  • Evidence: Code shown: 'stream.on("text", (chunk) => connection.send_session_update({sessionId, type: "agent_message_chunk", ...}))'; Tool call updates include 'title' (displayed in UI), 'status' (in_progress/completed), 'content' (tool output), and optional 'location' (file/line references); Zed UI shows live streaming tokens and separate UI elements for each tool call with progress indicators
  • Caveats: Demo experienced duplication bugs where tool calls appeared twice—Bennet notes 'something is going wrong with the connection' but doesn't debug live; No discussion of handling out-of-order updates or ensuring update consistency if network is unreliable; Metadata fields like 'title' are 'some metadata that Zed uses...for icons and stuff'—unclear if standardized or client-specific
  • Implications: For Ken's dashboards, this enables Slack-bot-style live updates without WebSocket complexity—just handle incoming notifications; Tool call progress is first-class in the protocol, so building agent observability UIs is straightforward; Non-blocking model means agents can stream to multiple clients simultaneously without coordination

File System Proxying and Capabilities

  • Claims: Clients can advertise file system capability; if present, agents call connection.read_text_file instead of native fs.readFile; Proxying ensures agents see unsaved buffer state, not just on-disk files—critical for editor integration; Content types in ACP include text, diff, and others; edit_file sends old_text and new_text, and client renders diff
  • Evidence: Bennet replaces 'fs.readFile' with 'connection.read_text_file' and explains 'if I have unsaved changes in my buffer, they're not actually on the file system, but the agent should still see them'; Zed UI shows diff view when agent calls edit_file, with old/new text highlighted; Q&A confirms 'the agent sends old text, new text, and then that does the diffing for you' on the client side
  • Caveats: No discussion of what happens if agent tries file system calls but client doesn't advertise capability—fallback behavior unclear; Capability negotiation happens in initialize but demo doesn't show bidirectional capability checks (agent checking client's advertised capabilities); Diff rendering is client-side; agents must provide both old and new text, so agents can't just send patches or edit instructions
  • Implications: For Ken's agent workflows, always implement file system capability in clients to avoid stale-read bugs—critical for correctness; Agents working on codebases can operate on in-memory state, enabling faster iteration without constant file writes; Diff content type means clients can render human-readable previews; Ken's review UIs can show side-by-side diffs before applying edits

Live Demo and Meta-Agent Patterns

  • Claims: The agent successfully modified its own source code to add terminal tool support, then used the new tool to execute shell commands; Terminal capability lets agents create/manage terminals through the client; agent calls terminal APIs over ACP and client displays output; All demo code was 'agent generated' and shown working end-to-end despite not being production-quality
  • Evidence: Bennet prompts agent with 'add a terminal tool to itself,' agent writes tool description and implementation, after restart the agent runs 'sleep 5; ls' in a terminal shown in Zed UI; Terminal execution shown working: agent sends terminal command, Zed displays terminal with 'sleeping five seconds' then directory listing; Bennet cautions 'please don't use it in production...it's all agent generated'—emphasizing the code is a demo, not production-ready
  • Caveats: Terminal capability security model not discussed—unclear if there are sandboxing or permission checks before executing arbitrary shell commands; Self-modification pattern shown is powerful but risky; no discussion of versioning, rollback, or validation before running modified agent code; Connection bugs during demo suggest edge cases in connection handling or session management not fully worked out
  • Implications: Meta-agent patterns (agents that extend themselves) are now practical with minimal scaffolding; Ken could build agents that learn new tools on-the-fly for evolving workflows; Terminal capability is useful for CI/CD agents, deployment scripts, or infrastructure automation—clients can display command output without custom logging; For production use, Ken should wrap agent-generated code in validation/review steps and implement rollback mechanisms; the protocol enables self-modification but doesn't enforce safety

Notable Concepts & Terms

  • Agent Client Protocol (ACP): Open-source JSON-RPC protocol for unified agent-client communication, analogous to LSP for language servers or MCP for model context; solves fragmentation across AI coding tools.
  • Session: A conversation thread with a unique ID in ACP; clients create sessions, agents maintain state per session, and all prompts/updates are scoped to a session ID.
  • Session Update (notification): Asynchronous, non-request-response messages from agent to client (e.g., agent_message_chunk for streaming tokens, tool_call for progress); enables real-time UI updates without polling.
  • Tool Call Update: Progress notifications for tool execution in ACP; agents emit initial tool_call (status: in_progress) then tool_call_update (status: completed, content: result) to show live progress.
  • File System Proxying: Client capability in ACP where agents call connection.read_text_file instead of native file system APIs; ensures agents see unsaved editor buffers, critical for editor integration.
  • Diff Content Type: ACP content type for file edits; agents send old_text and new_text, client renders diff; used in edit_file tool to show before/after changes in the UI.
  • Terminal Capability: Optional client feature in ACP where client manages terminal creation/execution for agent; agent calls terminal APIs over protocol, client displays output—useful for CI/CD agents.
  • Vibe Coding: Bennet's term for the agent modifying its own source code live during the demo; demonstrates self-modifying meta-agent patterns enabled by ACP's file editing and tool-calling.
  • Standard I/O Transport: Current ACP transport mechanism using stdin/stdout; remote transport (network-based) is under development by JetBrains team for distributed agent/client scenarios.
  • Capability Negotiation: Protocol handshake in initialize where agent and client advertise supported features (e.g., file system, terminal, authentication); determines which ACP features are available per session.

Operator Notes / Why Ken Should Care

  • ACP provides a production-ready interoperability layer for Ken's agent systems—implement once, swap agents/clients without rewriting integration code.
  • Minimal implementation surface (4 methods) means custom agents for domain-specific tasks (content workflows, investment research, GTM automation) are low-friction.
  • Session_update notification model enables real-time dashboards and progress UIs without WebSocket complexity; directly applicable to Ken's agent observability tooling.
  • File system proxying is critical for correctness in editor-integrated agents; ensure clients implement this capability to avoid stale-read bugs in code modification workflows.
  • Terminal capability useful for CI/CD and infrastructure agents; clients can surface command output in UIs without custom logging, but security model needs careful consideration.
  • Self-modifying meta-agent patterns (demonstrated in 'vibe coding') are now practical but require guardrails—validation, rollback, and review before executing agent-modified code.
  • TypeScript SDK shown; if Ken's agents are Python/Rust-based, verify language SDK availability or implement JSON-RPC client directly (protocol is simple enough).
  • Connection handling bugs during demo suggest edge cases; production deployments should include robust error handling and reconnection logic.
  • Adapter pattern (translating native protocols to ACP) means existing agents can bridge to ACP without full rewrites—useful if Ken has legacy agent code.
  • For Ken's content/business use cases, ACP enables editor-integrated agents that assist with writing, research, or analysis directly in the user's workflow with minimal friction.

Watch Map

  • 00:00: Introduction: Problem statement (agent fragmentation), ACP overview, ecosystem adoption (40+ clients, multiple agents)
  • 01:20: Live coding begins: Existing minimal coding agent (read_file, edit_file tools, Anthropic API integration, tool-calling loop)
  • 02:15: Adding ACP compliance: TypeScript SDK, implement initialize/new_session/prompt/cancel_session methods
  • 04:30: First test in Zed: Agent runs but no token streaming (missing session_update implementation)
  • 06:45: Adding streaming: Implement agent_message_chunk session_updates on text events from Anthropic SDK
  • 07:30: Streaming test: Tokens appear live in Zed UI
  • 08:00: Adding tool call updates: Emit tool_call (in_progress) and tool_call_update (completed) session_updates
  • 09:00: File system proxying: Replace fs.readFile with connection.read_text_file to see unsaved buffers
  • 10:00: Tool call test: Read_file shown in Zed UI with progress and output (duplication bug appears)
  • 10:30: Adding edit_file updates: Same pattern for edit_file tool, diff content type sent to client
  • 11:30: Edit_file test: Diff preview shown in Zed UI
  • 12:30: Adding terminal capability: Agent prompted to add terminal tool to its own source code
  • 13:00: Self-modification demo ('vibe coding'): Agent writes terminal tool implementation, modifies its own code
  • 14:00: Terminal test: Agent executes 'sleep 5; ls' in Zed terminal, output shown live
  • 15:00: Conclusion: Summary, resources (agentclientprotocol.com), Q&A on diff handling and transport
  • 16:30: Q&A: Connection transport (standard I/O, remote coming soon)

Source/Metadata

  • Title: Building an ACP-Compatible Agent Live — Bennet Fenner, Zed
  • Transcript words: 3802
  • Duration seconds: 1099
  • Timestamp note: Video duration provided (1099 seconds, ~18 minutes); approximate timestamps inferred from transcript structure and demo phases.
Full transcript 2606 words · 17 min read
0:14

SPEAKER_00

I'm Bennett, I work at Zedd and we built an AI code editor, all written in Rust. And last year was, as you probably all know, the rise of the AI coding agent and terminal user interfaces with every major model provider building Cloud Code, Codex, Gemini, CLI and so on. And so at Zedd we asked ourselves, how can we let users bring their agent of choice to our tool and enjoy a nice interface that is unified across all of them? And so that's why we decided we need some type of protocol called agent client protocol, which is similar to MCP or LSP. It's a JSON RPC based protocol. And the idea is that agents and clients can talk to each other through a unified interface.

0:46

SPEAKER_00

And it's online, it's open source, you can contribute if you want. At this point we have a wide variety of agents already supporting this either by an adapter that translates the agent's native language to the ACP one. And then we have, for example, open code and cursor having ACP mode built into their CLI agents. And we also have a bunch of clients at this point up to 40 that implement this, including open claw for example. Open claw itself is a client and a server, a client and an agent. And JetBrains and Obsidian and other people are supporting this. Great. So I'm going to do a live coding session. Let's see how well that goes.

1:34

SPEAKER_00

So, right. We have some pre-existing code. So this is Zed. Here I have some TypeScript code. Also bear with me. I'm a Rust developer. I have basically zero clue about TypeScript. So if you see anything that you don't do in TypeScript, tell me afterwards. But here's a very minimal coding agent that just doesn't support ACP, but it's the bare minimum you need to build a coding agent. So all it has is really two tools. One to read a file and one to edit an existing file. This is pretty basic. It provides the model has to provide a path and it has to provide an old text that is then just replaced with new text and that's everything.

2:03

SPEAKER_00

And then we have in this case, I'm using Anthropic. There's a way to prompt the agent with the user can prompt the agent, which is the function that we were going to call here. And then we enter the agent loop and that is the way all agents work is the model APIs are stateless. So you just attach some conversation up to this point. You call the endpoint. In this case, it's the Anthropic API. And then we get a message from the model and either it can be an end turn. That means the model decided to output some text and do nothing or it can call a tool. And in this case, it would be a read or a write tool call.

2:11

SPEAKER_00

And then in the case of a tool call, we run the, for example, the edit file tool call locally, collect the result and then send it up to the model again. That's where there's this loop. And then we call the API again with the conversation up to that point. And that's everything. And then we have this handle tool call function here, which handles read and write tool calls, which does what you expect. We get the paths. We read it from the file system and we return some result. Right. So now the question is how do we make this thing ACP compatible? And hopefully we can do it in 10 minutes. So let's see.

2:32

SPEAKER_00

So I have some boilerplate here. In this case, I'm using the TypeScript SDK, as I said. And the way this works, you implement the agent interface provided by this library. And then you have to, at minimum, implement these three, four functions. So the first one that we're looking at is this initialize here. All we really have to do here is respond with the protocol version we support, which in this case is just the latest. There's also some capabilities like client and the agent can itself advertise capabilities of stuff it supports. But we're building a mere minimal coding agent, so we don't support anything outside that's necessary.

2:59

SPEAKER_00

And then for us, authentication is irrelevant since it's just using my API key from an infar. And then there's this concept of sessions in ACP. So basically every time you start with Red and Z or in a different editor or client, you call a new session. And in a session, you can prompt. And then from there on, you can get your output. So all we really do here is we generate a random ID. Then we instantiate this coding agent with the current working directory, which we get from the client. And we store it in our internal map and then just return the ID to the client so that the client knows the ID. And that is then used inside prompt.

3:21

SPEAKER_00

Because what prompt does in this case, it prompts the prompt request, if we go to the definition here, all this is doing is it provides a prompt, which is an array of content blocks that can be text, images, whatever, the session ID for reference. And so all we have to do here is we look it up in our internal state. We get the relevant agent for that current session. And then I have a helper function here, which in this case ignores everything that's not text because we don't support images and stuff. And then we call this prompt function I showed earlier, which then runs the tool calling loop.

3:32

SPEAKER_00

And then as a nice to have feature, we also support cancellation. That's also pretty simple. So these are the four minimal things we have to implement. And I have this hooked up in Z just by there's no special code. All I have is I tell Z there's some ACP compatible agent, and you can run it with node and then my path to that agent.js file. So when I do that in here as well. So when I run, I'm going to build. I'm going to build, right? loop. And so then just as a nice to have feature, we also support cancellation. That's also pretty simple. So these are the four minimal things we have to implement.

4:02

SPEAKER_00

And I have this hooked up in Zed just by—there's no special code. All I have is I tell Zed there's some ACP compatible agent, and you can run it with node and then my path to that agent.js file. So when I, let's do that in here as well. So when I run, I'm going to build. I'm going to build, right? And then I'm going to restart, yeah, launch a new ACP demo agent. And you can see if I ask it for something, you can see weight indicator. And now it's done. So nothing. Which is what we expect, right? Because what we can see here, if I go over, oops, if I go over here, we have an ACP debug view in Zed, so to make it easier for us to develop.

4:37

SPEAKER_00

And you can see Zed sends a session new request. We respond with a session ID. And as soon as I type in something, we get prompt. And now we got a stop reason, right? So these red arrows come from the adapter that we are building from the agent. But it's not outputting tokens, right? Behind the scenes, it's obviously Anthropic is giving us tokens. But how do we make them show up in Zed? So that's the next thing that we want to focus on. So the first thing that we need to do, our coding agent itself needs to have a way to send something over the connection. So what we're going to do here is the coding agent is going to take the ACP connection and then also the session ID.

5:18

SPEAKER_00

And then inside here, we have to provide this connection and the ID. And then if we go, okay, I'm just going to close this, right? If we go back here, now inside of a prompt, this is the Anthropic SDK. So in this case, you can just use this stream on. That's the Anthropic SDK. You can react to a text event. So every time we get a chunk, we send what ACP calls a session update. As I said, a session is a single thread or a conversation. And then you can send updates, notifications to the client that are not a usual request response, right? It can happen at any time and the client reacts to it. And so here, we are associating the session update with a session ID.

6:13

SPEAKER_00

And then there's a type of session updates. There are multiple. We will see more in a second. But this agent message chunk is just, okay, hey, here's some new output from the model. And so if we build again, we go back to Zed. I'm going to have to restart the agent. I go here. And I say, hello. Hello, hello. Well, here's Opus talking, right? You can see we're streaming in these individual chunks, right? Right there we got from Anthropic. So far, so good. Let's hope the demo gods stay with us. Right. So that's one piece. The next thing, though, is I want to—it's a coding agent, right? It's supposed to edit code.

7:27

SPEAKER_00

So I can actually tell it already because we have tool support, right? I can tell it to read, for example, this helpers.ts file. And it's going to give me, if the Wi-Fi isn't too slow, a description of what this file actually contains. If you look here, that's basically the description of the file. But again, you don't see it in the UI, right? So now we need to emit more session updates, similar to what we did for text. So if we actually go towards the read file, what we need to do here is the way it works usually in ACP, you emit an initial tool call update, which I'm going to paste in here. So, yeah. Again, we're emitting a session update.

8:04

SPEAKER_00

In this case, it's a type of tool call. And then there are multiple properties we can specify, for example, the title, some metadata that Zed uses, for example, for yeah, using some icons and stuff like this. And then we indicate that the status is in progress. And you can also associate tool calls with actual locations. And so now we signaling over ACP that something is in progress, right? This tool call. But then we also want to, at the end, once the tool call has finished, at the bottom here, we want to send another update. And in this case, it's not tool call itself, but it's a tool call update.

8:34

SPEAKER_00

So you have to emit on the agent, you have to emit a tool call, a session update of type tool call. And then once the client knows about it, you can emit updates for that. And this is the way that we set the status. And we can also return the content. And then one additional thing that I'm going to do here is, instead of, you can see here, we're calling, I guess it's a bit hard to see, but here we're calling FSREADFile, right? So we're just using the native file system APIs. But ACP actually proxies the file system too. The client can provide a file system capability, and if it does, we can proxy those file system calls over ACP.

9:17

SPEAKER_00

And it makes sense, for example, for an editor, right? You want to—if I have unsaved changes in my buffer, they're not actually on the file system, but the agent should still see them. So that's why we call this read text file over ACP. And so, now if you go back here and hit npm run build, and then go back here, restart, and say read this file. Oops, not Rust. Then we should be seeing, yeah. So now we see two calls, right? OK. Something is going wrong because everything is duplicated. Yeah. But here, you can see the output of the actual file.

9:56

SPEAKER_00

You want to, if I have unsafe chains in my buffer, they're not actually on the file system, but the agent should still see them. So that's why we call this a retext file over ACP. And so, now if you go back here and hit npm run build, and then go back here, restart, and say read this file. Oops, not Rust. Then we should be seeing, yeah. So now we see two calls, right? OK. Something is going wrong because everything is duplicated. Yeah. But here, you can see the output of the actual file. And because I think I'm low on time, we're going to do the same for edit file. And I'm going to compile again. And if I, again, restart. And say, add a comment at the top of agent, source agent dot TypeScript, then you're going to see, hello world is good. Hopefully Opus is going to decide to add hello world at the top of the file. And we actually get a diff here because over ACP we send a diff of the file. OK.

9:57

SPEAKER_00

[SPEAKER_01] Is it obligating the first two tables? Yeah. I think there's something going wrong with the connection. Yeah. No time to debug right now. Sorry. Am I out of time or do I still have? [SPEAKER_02] Is that what? [SPEAKER_02] It's quite gone.

10:11

SPEAKER_00

OK. Maybe we can see. So now that, OK. Just another minute. Now that the coding agent supports reading and writing files, we can actually. Oh, great. OK. Then I don't need to rush. Now we can bootstrap the agent itself, right? The coding agent supports reading and writing files. I can just ask it. I prepared a prompt here to add a terminal tool to itself, right? Let's see how this works out with the duplication we're seeing. But basically, I'm telling it something about the ACP APIs. And there are some APIs in ACP, which also, that's another capability of the client, where the client can advertise that it supports creating terminal and managing terminals for the agent. The agent can also do it itself, of course. So we can do this. But it's a nice way for us to add some more interactivity. And so the agent here decided to add a new tool description. Now it, yeah. I'm vibe coding basically this terminal tool. And let's see if it actually builds. It does. Well, that's good. And then, again, I'm going to restart the agent. I'm going to run our demo agent. And I'm going to ask it to run sleep 5 ls. Let's see. There you go. You can see a terminal running. Sleeping five seconds. There is the output. And there's, yeah. And that's it, basically. Thank you. Yeah, so that's how you build an ACP compatible coding agent in 15 minutes or so. Yeah, if you want to check it out, just go to agentclientprotocol.com. In case anyone wants the demo code, but please don't use it in production. It's all agent generated. It's not uploaded yet, but it's an empty repository. I'm going to upload it in a second. Yeah, thank you for listening. Happy to answer questions. That's it. Yeah.

10:15

SPEAKER_00

[SPEAKER_01] How does it handle the diffs? Is it only on the client side? The diffs, yeah, we have, in ACP, there are multiple content types. And one content type is diff. And so the agent sends old text, new text, and then that does the diffing for you. Yeah. [SPEAKER_02] Okay, great. I'll show you. Yeah. Cool. Do I need to go? Or can I? One more. Okay, one more question. Yes? [SPEAKER_02] So the connection, is it all mobile hosts between that?

10:28

SPEAKER_00

Yeah, the connection works over standard I/O. There are some folks, I think, from the JetBrains people are working on, remote transport, which we're going to have soon, I think. So, yeah. But right now it works over standard I/O. Yeah. And it's going to give me, if the Wi-Fi isn't too slow, it's giving me a description of what this file actually contains. Like if you look here, that's basically the description of the file. But again, you don't see it in the UI, right? So now we need to emit more session updates, similar to like what we did for text. So if we actually go towards the read file, kind of what we need to do here is like the

11:05

SPEAKER_00

way it works usually in ACP, like you emit an initial tool call update, which I'm going to paste in here. So, yeah. Again, we're emitting a session update. In this case, it's a type of tool call. And then there are multiple properties we can specify, for example, like the title, kind of some kind of metadata that Zed uses, for example, for like, yeah, using some icons and stuff like this. And then we indicate that the status is in progress. And you can also like associate tool calls with like actual locations. And so now we signaling over ACP that something is in progress, right? This tool call.

11:48

SPEAKER_00

But then we also want to, at the end, like once the tool call has finished, like at the bottom here, we kind of want to send another update. And in this case, it's not tool call itself, but it's a tool call update. So, you have to emit on the agent, you have to emit like a tool call, like session update of type tool call. And then once the client knows about it, you can emit updates for that. And this is the way that we set the status. And we can also return the content. And then one additional thing that I'm going to do here is the, instead of like, you can see here, we're calling, I guess it's a bit hard to see, but like here we're calling FSREADFile, right?

12:31

SPEAKER_00

So, we're just using the native file system APIs. But ACP actually proxies the file system too. Like the client can provide a file system capability, and if it does, we can like proxy those file system two calls over ACP. And it kind of makes sense, for example, for an editor, right? You want to, if I have unsafe chains in my buffer, they're not actually on the file system, but the agent should still see them. So that's why we call this like a retext file over ACP. And so, now if you go back here and hit npm run build, and then go back here, restart, and say read this file. Oops, not Rust.

13:29

SPEAKER_00

Then we should be seeing, yeah. So now we see two calls, right? OK. Something is going wrong because everything is duplicated.

13:43

SPEAKER_00

Yeah. But like here, you can see the output of the actual file. And because I think I'm low on time, we're basically going to do the same for edit file.

13:57

SPEAKER_00

And I'm going to compile again. And if I, again, restart.

14:08

SPEAKER_00

And say, add a comment at the top of agent, source agent dot TypeScript, then you're going to see, hello world is good.

14:32

SPEAKER_00

Hopefully Opus is going to decide to add hello world at the top of the file. And we actually get a diff here because the over ACP we send like a diff of the file. OK.

14:40

SPEAKER_01

Is it obligating the first two tables? Yeah.

14:43

SPEAKER_00

I think there's something going wrong with the connection. I'm, yeah. Yeah. No time to debug right now. Sorry. Am I out of time or do I still have?

14:54

SPEAKER_02

Um. Is that what? It's quite gone.

15:00

SPEAKER_00

OK. Maybe like we can see. So now that, OK. Just another minute. Now that the coding agent supports reading and writing files, we can actually. Oh, great. OK. Then I don't need to rush. Now we can kind of bootstrap the agent itself, right? Like the coding agent supports reading and writing files. I can just ask it. I prepared a prompt here to add a terminal tool to itself, right? Let's see how this works out with like the duplication we're seeing. But basically, I'm telling it something about the ACP APIs. And there's some APIs in ACP, which also, that's another like capability of the client, where

15:42

SPEAKER_00

the client can advertise that it supports grading terminal and managing terminals for the agent. Like the agent can also do it itself, of course. So we can do this. But it's a nice way for us to add some more interactivity. And so the agent here decided to add a new tool description. Now it, yeah. I'm vibe coding basically this terminal tool. And let's see if it actually builds. It does. Well, that's good. And then, again, I'm going to restart the agent. I'm going to run our demo agent. And I'm going to ask it to run sleep5ls. Let's see. There you go. You can see a terminal running. Sleeping five seconds. There is the output. And there's, yeah. And that's it, basically.

16:41

SPEAKER_00

Thank you. Yeah, so that's how you kind of build an ACP compatible coding agent in 15 minutes or so. Yeah, if you want to check it out, just go to agentclientprotocol.com. In case anyone wants the demo code, but please don't use it in production. It's all agent generated. It's not uploaded yet, but it's an empty repository. I'm going to upload it in a second. Yeah, thank you for listening. Happy to answer questions. That's it. Yeah.

17:24

SPEAKER_01

How does it handle the diffs? Is it only on the client side?

17:28

SPEAKER_00

The diffs, yeah, we have, like, in ACP, there are multiple content types. And one content type is diff. And so the agent sends old text, new text, and then that does the diffing for you. Yeah.

17:38

SPEAKER_02

Okay, great. I'll show you.

17:39

SPEAKER_00

Yeah. Cool. Do I need to go? Or can I? One more. Okay, one more question. Yes?

17:47

SPEAKER_02

So the connection, is it all mobile hosts between that?

17:51

SPEAKER_00

Yeah, the connection works over standard I.O. There are some folks, I think, from the JetPrints people are working on, like, remote transport, which we're going to have soon, I think. So, yeah. But right now it works over standard I.O. Yeah.

18:17

namenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamenamename

Reading tools

Type to find a passage

Appearance
Ask this transcript

Add a note