ACP Is the Bridge Between Knowledge Work and Build Work

TL;DR

• ACP (Agent Client Protocol) is an open JSON-RPC 2.0 standard that lets a knowledge agent delegate build tasks directly to a coding agent — eliminating the "human clipboard" between thinking and shipping.
• The result: ~25 minutes vs. ~40 minutes per research-to-build cycle, and zero context switches instead of three.
• ACP complements MCP — MCP connects agents to tools, ACP connects agents to other agents that have capabilities the first agent lacks.
• Multiple coding agents (Claude Code, Kiro, Cursor) support ACP simultaneously; route tasks based on what the work demands.
• If your workflow still requires you to copy context between a knowledge agent and a coding agent, ACP is the fix.

The hardest moment in any AI-assisted workflow is the handoff between thinking and building.

You research a problem. You draft a strategy. You design an architecture. Then you need to ship it — commit code, push to a repo, deploy infrastructure. That's where the workflow breaks. Your knowledge agent can't touch git. Your coding agent doesn't know the context that led to the decision. You become the human clipboard between two capable systems that can't talk to each other.

This is the fundamental tension: knowledge work and build work run on different agents with incompatible capabilities. And until recently, the only bridge was you.

The Two-Agent Architecture

Every AI-native workflow has two halves:

No single agent does both well. Knowledge agents — orchestrators that manage communication, research, and decision support — own your inbox, your CRM, your knowledge base. But they can't run git push. Coding agents — Claude Code, Cursor, Windsurf, Kiro, OpenHands, Aider — have full filesystem and terminal access. But they don't know your deal pipeline or what your stakeholder said in yesterday's thread.

The traditional workaround is the handoff file — you write a task description in a shared folder, switch contexts, and hope the other agent picks it up. It works. It's also slow, lossy, and breaks flow.

The Agent Client Protocol (ACP) eliminates that gap.

What ACP Is

Created by Zed Industries and released as an open standard in August 2025, ACP is a JSON-RPC 2.0 protocol modeled after LSP (Language Server Protocol) — the same architecture that standardized how editors talk to language tools. Where LSP said "write one language server, every editor speaks it," ACP says "write one coding agent, every orchestrator can delegate to it."

The standard is open and implementable by anyone. Zed Industries designed it; the broader ecosystem adopted it. Multiple editors and agent frameworks now support ACP-compliant agents, which means the protocol isn't tied to any single vendor. You pick your orchestrator. You pick your coding agent. ACP is the contract between them.

This is a deliberate architectural choice: separation of concerns at the protocol level. The knowledge agent retains the why — customer context, business requirements, strategic constraints. The coding agent handles the how — file edits, terminal commands, test execution, deployment. ACP is the interface that lets them coordinate without either system needing to understand the other's full stack.

How It Works in Practice

The protocol is deceptively simple. JSON-RPC 2.0 over stdin/stdout — the exact same transport layer as LSP. The practical flow:

1. You tell the knowledge agent what you need built. Context included: the problem statement, repo path, requirements, constraints from your research or conversations.
2. The orchestrator delegates to the coding agent via ACP. The message includes the working directory, the task, and any relevant context.
3. The coding agent executes. It reads files, writes code, runs tests, commits — whatever the task requires. Full terminal access, full filesystem access.
4. Results flow back to the orchestrator. The knowledge agent reports what was built, what changed, and what needs review.

Each task gets an isolated subprocess with independent conversation context. You can run multiple coding agents in parallel — frontend, backend, infrastructure — and collect results from all of them. You can follow up on any task with additional instructions using the same task identifier, and the agent retains the full context of what it already did.

The Before and After

Before ACP (handoff file pattern):

1. Research requirements across your communication tools → 15 minutes
2. Write a task file describing what to build → 5 minutes
3. Switch to terminal, open your coding agent → 2 minutes
4. Paste the task context (or hope it reads the file) → 3 minutes
5. Coding agent builds → 10 minutes
6. Switch back to knowledge agent, report results → 5 minutes

Total: ~40 minutes, 3 context switches, information loss at every boundary.

With ACP (direct delegation):

1. Research requirements across your communication tools → 15 minutes
2. "Build a health check endpoint for the MCP server" → orchestrator delegates via ACP
3. Coding agent builds → 10 minutes
4. Results surface in the same conversation → immediate

Total: ~25 minutes, zero context switches, full context preserved.

The time savings are real but secondary. The primary gain is flow preservation. You don't break the research-to-build thread. The knowledge agent knows why the endpoint matters (the user context, the deployment timeline, the architectural constraints) and can validate the result against those requirements — not just whether the code compiles.

The Protocol Stack

ACP doesn't replace MCP — it complements it. Each protocol was created by a different organization to solve a different problem. The full agent protocol stack for 2026:

MCP connects your agent to tools. ACP connects your agent to other agents that can use tools you can't. The distinction matters: an MCP server for git would give your knowledge agent read access to repos; ACP gives your knowledge agent a fully autonomous coding agent that can clone, branch, commit, test, and deploy.

The 2026 protocol ecosystem is converging on this layered model. MCP for tools, ACP for agent delegation, A2A for agent coordination. A complete agent stack will use all three.

Choosing Your Coding Agent

Multiple coding agents now support ACP, and the choice depends on the work:

The choice isn't either/or. Freeform agents are the fast-twitch muscle — exploration, prototyping, rapid iteration. Spec-driven agents are the structured builders — requirements before code, guardrails baked in. You can have multiple connected simultaneously and route tasks based on what the work demands.

Why This Matters Now

Three forces are converging:

1. The coding harness is commoditizing. Every AI coding agent is converging on the same capabilities: read project context, edit files, run commands, iterate on errors. The harness is not the moat. The orchestration layer that connects agents to work context is.

2. Knowledge work and build work are interleaved, not sequential. You don't spend the morning researching and the afternoon coding. You switch between modes dozens of times a day — sometimes within the same conversation. Any workflow that forces a clean context switch between "think mode" and "build mode" is fighting against how work actually happens.

3. The Agentic Development Environment is becoming the unit of competition. IDEs that add AI assistance are losing ground to environments that orchestrate multiple agents with different capabilities. ACP is the protocol that makes orchestration possible without vendor lock-in.

The Honest Edges

ACP is a protocol, not a product. The experience today has rough edges:

• Authentication is fragile. If the coding agent's session expires, the delegation fails silently. You discover this when the orchestrator reports "auth error" instead of results.
• No shared memory. The coding agent doesn't know what the knowledge agent discussed with you earlier — it only knows what the orchestrator includes in the delegation message. Context engineering matters.
• Parallel execution is powerful but hard to monitor. Running three agents simultaneously is great until one hangs and you can't tell which.
• The handoff file pattern isn't dead. For cross-session work (start today, finish tomorrow) or cross-machine work (laptop → CI), file-based handoffs remain the durable coordination mechanism. ACP is for real-time, same-session delegation.

These are solvable problems. The architecture is sound. The protocol is open. The implementations are improving weekly.

So What

ACP transforms the knowledge agent from a smart assistant into a team lead. It doesn't just help you think — it delegates the build work to agents that can ship. The human stays in the decision loop (what to build, why, for whom) while the agents handle execution on both sides of the knowledge-build divide.

The pattern: one conversation, two capabilities, zero context switches. Research flows into requirements. Requirements flow into code. Code flows back into the conversation that started it.

The bridge between knowledge work and build work isn't a feature. It's a protocol. And it's open.