Skip to main content
graphwiz.ai
← Back to AI

The Agent Client Protocol Is the LSP Moment for AI Coding Agents

AI
acpai-agentsopencodedevtoolsprotocol

Every editor ships its own agent integration. Every agent builds editor-specific glue code. The result: N×M integration surfaces, each slightly broken in its own way. The Agent Client Protocol (ACP) ends this by standardising the communication layer — the same trick LSP pulled off for language servers in 2016.

What ACP Actually Is

ACP defines a JSON-RPC protocol between a client (your editor, CLI, or app) and an agent (Claude, Codex, Gemini, OpenCode, or any of the 30+ compatible implementations). The agent runs as a subprocess communicating over stdio, or remotely over HTTP/WebSocket.

The lifecycle is straightforward:

client → spawn agent subprocess → initialise → create session → send prompt → stream response → cleanup

The protocol handles the hard parts: permission requests for tool calls, streaming partial output, session management, terminal access, and file system operations. It re-uses MCP (Model Context Protocol) types where possible so you're not learning yet another schema.

Who Supports It

The ecosystem is moving fast. As of April 2026:

Agent Editor/Client Status
Claude Code Zed, VS Code, neovim, JetBrains Stable
Codex CLI Zed, acpx Stable
Gemini CLI Zed, JetBrains Stable
OpenCode Zed, neovim, CLI Stable
Cursor VS Code extension Stable
GitHub Copilot CLI (public preview) Preview
Goose Zed, JetBrains Stable
Cline Zed, VS Code Stable
Qwen Code Zed, CLI Stable
Kimi CLI CLI Stable

On the client side, there are 40+ implementations: Zed, VS Code, JetBrains, neovim (three separate plugins), Emacs, Obsidian, Unity, Chrome, mobile apps (iOS/Android), and messaging bridges (Discord, Telegram, Slack, WeChat).

The plugin ecosystem around ACP-compatible agents is growing rapidly. A notable example: the opencode-saia-plugin automatically fetches the latest model catalogue from GWDG's SAIA (academic cloud) API and generates OpenCode configuration on startup — so every new SAIA model appears in your ACP agent without manual config edits.

The Meta-Orchestrator Pattern

Here's where it gets interesting. Because every ACP agent speaks the same protocol, you can write a single orchestrator that drives any of them — across any number of projects.

I built the ACP Orchestrator to do exactly this. It registers projects in a YAML file with tags, then runs prompts across them in parallel:

# config/projects.yaml
projects:
  - name: next-graphwiz-ai
    path: ~/git/next-graphwiz-ai
    tags: [typescript, nextjs, ai, docker]

  - name: mcp-neo4j
    path: ~/git/mcp-neo4j
    tags: [python, mcp, graph]

defaults:
  agent: opencode
  max_concurrent: 5
  timeout: 600

Then:

# Run a prompt across all Python projects
acp run "check for outdated dependencies" --tags=python

# Run a prompt on specific projects
acp run "add error logging" --project=next-graphwiz-ai,mcp-neo4j

# Verify all project paths exist
acp check

The batch runner spawns ACP agent subprocesses with bounded concurrency (asyncio semaphore), collects streaming results, and reports per-project status. Each agent gets full filesystem access to its target project via the ACP protocol's file system capabilities.

The Dev Loop: Autonomous Improvement at Scale

The acp loop command runs a continuous develop/optimize/review/commit cycle:

ANALYZE → IMPLEMENT → VERIFY → COMMIT → repeat

Each iteration follows a strict priority order:

  1. Bugs — unhandled errors, race conditions, crashes
  2. Security — hardcoded secrets, injection vectors, missing auth
  3. Tests — missing coverage, flaky tests, untested error branches
  4. Type safety — any casts, missing return types
  5. Performance — N+1 queries, memory leaks, unnecessary re-renders
  6. Error handling — empty catch blocks, swallowed errors
  7. Code quality — dead code, duplication, poor naming
  8. DX — missing README sections, confusing APIs
# Run 100 iterations with session rotation every 25
acp loop next-graphwiz-ai --max-iter 100 --rotate 25

# Focus on a specific area
acp loop next-graphwiz-ai --focus "test coverage"

Session rotation is the critical design decision. ACP agents accumulate context with each turn, and after 20-30 iterations the context window fills with stale information. The orchestrator kills the session, spawns a fresh one, and tells the new agent to run git log --oneline -20 to understand what was already done.

The implementation uses the official agent-client-protocol Python SDK. Each agent session follows the full ACP lifecycle:

async with spawn_stdio_transport(*agent_command, limit=10*1024*1024, cwd=project_path) as (reader, writer, process):
    conn = ClientSideConnection(client, writer, reader)
    await conn.initialize(
        protocol_version=PROTOCOL_VERSION,
        client_capabilities=ClientCapabilities(
            fs=FileSystemCapabilities(read_text_file=True, write_text_file=True),
            terminal=True,
        ),
        client_info=Implementation(name="acp-loop", title="ACP Dev Loop", version="0.1.0"),
    )
    session = await conn.new_session(cwd=project_path, mcp_servers=[])
    response = await conn.prompt(session_id=session.session_id, prompt=[text_block(prompt_text)])

Tool calls are auto-approved by the orchestrator (configurable), so the loop runs without human intervention.

Use Cases Beyond Single-Project Loops

The standard ACP use case is "editor talks to one agent." But the protocol enables several patterns that most people haven't explored yet:

Batch hygiene sweeps. Run acp run "audit for hardcoded secrets and TODO comments" --all across 90 repositories. Get a report in minutes, not days.

Multi-agent fleets. The orchestrator's agent field is per-project. Run Claude Code on your Python services, Gemini CLI on your Go microservices, and Codex on your TypeScript frontend — all from the same command.

CI/CD integration. Wire acp run "run tests and report failures" --tags=critical into your pipeline. The orchestrator spawns agents, collects results, and exits non-zero if anything failed.

Cross-project refactoring. When an API changes in a shared library, run the migration prompt across every dependent service simultaneously.

Remote orchestration. ACP supports HTTP transport for remote agents. You can run the orchestrator on a beefy server and drive agents on developer machines, or vice versa.

The Trade-offs

Auto-approving tool calls in an infinite loop is dangerous. The orchestrator provides --no-approve mode, but that requires human interaction — defeating the purpose of autonomous operation. The practical solution is running against git-managed repos where you can git reset --hard if the agent goes off the rails.

Session rotation means the agent loses conversational context. The mitigations are: (1) the git log check prevents repeated work, (2) the structured priority system means each iteration is self-contained, and (3) the system context prompt is re-injected on every new session.

The 10-minute default timeout per turn is generous for simple tasks but may be too short for large codebases. The --analyze-timeout, --implement-timeout, and --verify-timeout flags let you tune per-phase.

Getting Started

pip install agent-client-protocol
pip install -e ".[dev]"  # from the ACP Orchestrator repo

Register your projects in config/projects.yaml, then:

acp list                     # see what's registered
acp check                    # verify paths exist
acp run "your prompt" --all  # run across everything
acp loop my-project          # start the improvement cycle

ACP is the infrastructure layer that makes the "AI writes code" paradigm actually composable. One protocol, any agent, any editor, any number of projects. The orchestrator pattern shows what becomes possible when you stop treating agents as isolated tools and start treating them as a fleet.