06-reference

josharosen acp emerging interface

2026-09-29·reference·source: X (article)·by Josh Rosen (@JoshARosen)
acpagent-client-protocolagent-infrastructuremulti-agentorchestrationobservabilitygovernanceobsidianharness-engineering

ACP: The Emerging Interface Between Agents and Everything Else (Josh Rosen)

Which ACP: this is Zed's Agent Client Protocol (editor/app ↔ coding agent). It is not IBM's Agent Communication Protocol (agent-to-agent messaging), and it is not the Agentic Commerce Protocol (OpenAI + Stripe) that this vault's commerce notes call "ACP" ([[2026-08-29-agent-purchasing-rails-link-mpp-state]]). Rosen doesn't mention either collision.

Why this is in the vault

The founder asked for it to be filed on 2026-09-30, the day after the article was posted on 2026-09-29. It's a survey of 100+ projects built on ACP, and it argues ACP is spreading beyond editors to become a general control surface for agents. That matters for three RDCO threads: how the studio fleet dispatches workers, whether to tool the Obsidian vault, and the agent-governance angle in the founder's credibility lane. It also updates the July judgement that ACP is a worse bet than MCP (Model Context Protocol) for us ([[2026-07-25-multi-agent-claude-codex-grok-composition-patterns]]).

The core argument

ACP began as an editor protocol, and Rosen compares it to the Language Server Protocol (LSP): one protocol in place of an N×M set of editor-by-agent integrations. It covers session setup, prompt and update exchange, permission handling and execution control, normally over local stdio (standard input/output). Zed started it with Google around Gemini CLI, and Rosen reports adoption by JetBrains and Apple (he hyperlinks Apple's Xcode 26.6 release notes on that phrase). An ACP Registry lets an agent register once and be discoverable by every client.

Rosen's claim is that the IDE (integrated development environment) is no longer the common thread. Across the projects he reviewed, ACP increasingly works as a generic way to drive an agent from any host: an app, an orchestrator, a workflow engine or another agent. He identifies six patterns:

  1. IDE ↔ agent (canonical). Still the most common setup. The editor is the client and the whole agent is the swappable unit: planning, tools, model routing, auth and runtime, not just the model. Adapters (codex-acp, claude-agent-acp) wrap the Codex and Claude runtimes, and multi-agent clients such as a VS Code ACP extension reach Claude, Codex, Gemini, Copilot, Kiro, OpenCode and others.
  2. Application interface. Non-editor apps become clients. Examples are the Obsidian Agent Client (the vault drives Claude Code, Codex or Gemini on notes), Unity, a JupyterLab client, and hash, a shell whose grammar dispatches to agents.
  3. Persistent session. The session outlives any one client, so clients attach and detach. ACP UI bridges stdio to WebSockets for web and mobile, and hydra-acp owns the agent process so that a terminal, editor, browser or Slack client can all join the same live session.
  4. Worker API for factories. Orchestrators need to start, assign, observe, steer, cancel and collect from workers, which is roughly what an IDE needs. ACP spares them one integration per harness. Examples: Helix (Kanban spec → isolated coding workers → pull requests), Open Multi Agent (a task DAG, or directed acyclic graph), Zenith (a replanning orchestrator).
  5. Workflow / event primitive. Agents become callable units inside deterministic or event-driven systems, and the host doesn't own the agent loop. Examples: n8n nodes; acpx, a headless client that mixes agent turns with deterministic steps and checkpoints; OpenTag, where Slack/GitHub/GitLab/Linear/Lark events trigger a local agent that replies in the originating thread.
  6. Cross-vendor delegation. One agent delegates to other vendors' agents through a single interface. MCACP exposes ACP workers as an MCP server, so Claude Code can spawn Codex or Gemini sessions for write/review/test pipelines. OpenClaw works in both directions over acpx: coding agents reach an OpenClaw bot through it, and OpenClaw launches Codex or Claude Code through it. Rosen asks wryly whether the world needed yet another agent-to-agent mechanism.

Closing move: if ACP becomes the glue, then security, observability, identity, policy and audit tooling all have to understand it. A shared worker interface means that tooling gets built once instead of separately for each harness. In his words, ACP "could become a natural place to observe and govern agent work."

⚠️ Bias / stake

Mapping against Ray Data Co

  1. The sw- studio fleet is pattern #4, but we don't need ACP.* sw-builder / sw-critic and the brigade stations are workers that an orchestrator spawns, steers and collects from. That's Rosen's worker API. We do it through the harness's native Agent/SendMessage primitives on a single vendor, so there's no N×M integration problem for ACP to solve. Pattern #6 (cross-vendor delegation) is the only thing that would change that, and our own evidence says it isn't worth it yet: the July seeded-defect benchmark found zero defects caught by Codex or Grok that Claude missed, so external critics were not wired in ([[2026-07-28-seeded-defect-benchmark-results]], [[2026-07-28-external-model-delegation-codex-grok]]). Revisit only if a future benchmark flips that result.
  2. Obsidian Agent Client matters for the founder's vault. rdco-vault is an Obsidian vault. Pattern #2 would let the founder run Claude Code against notes from inside Obsidian, without a terminal. It's a third-party plugin that would give an agent write access to the whole vault (including the state and ops files that crons and agents write to). Treat it as something to evaluate, not install: review the plugin's permission model and how it interacts with concurrent fleet writes first.
  3. Snowflake Cortex Code already speaks ACP. Cortex Code (CoCo) lists MCP and Agent Client Protocol interop ([[2026-07-05-brigade-skills-snowflake-cortex-code]]), and the CoCo CLI marks ACP as Preview ([[2026-09-13-cortex-code-client-deployable-surface-p3-p4]]). So Rosen's patterns #4–#6 are a live option on Snowflake itself: CoCo could act as an ACP worker, or as a client calling the Brigade, instead of re-hosting it. That's the concrete bridge between this article and the Brigade P3/P4 work. Confirm the ACP surface is still Preview before building on it.
  4. Agent-session observability/governance fits the founder's credibility lane. His Nov-30 targets include published buyer-facing pieces on AI agents on Snowflake ([[2026-09-29-nov30-credibility-targets]]), and the recommended Tampa pitch is an "agents in production on Snowflake" talk ([[2026-09-29-tampa-user-groups]]). Rosen's closing question (where do you observe and govern agent work once agents are driven from everywhere?) is sharpest on Snowflake, where CoCo is both a governed agent and an ACP endpoint. Identity and audit framing: [[2026-07-25-agent-first-class-identity]]. This note is reference material for that lane only. The founder's instruction relayed with this dispatch (2026-09-30) was that nothing goes into personal-brand drafts.

Related

Provenance: xmcp was unavailable in the ingest-agent session (connect timeout, no 1Password token). The article body came from the public api.fxtwitter.com mirror of post 2104923180628381813. The title, author and timestamp (2026-09-29 13:16 UTC) match the canonical post. Extraction was done by a subagent and paraphrased here.