| title |
|---|
Rename ACP to IACP |
Author(s): @nikomatsakis
Rename the Agent Client Protocol from "ACP" to "IACP" (Interoperable Agent Client Protocol) to avoid confusion with OpenAI's Agentic Commerce Protocol, which launched in September 2025 with backing from Stripe, PayPal, and Salesforce.
The Agent Client Protocol uses the acronym "ACP." Three months later, OpenAI's Agentic Commerce Protocol also launched using "ACP," for e-commerce transactions via AI agents, backed by Stripe, PayPal, and Salesforce.
IBM's Agent Communication Protocol previously also used "ACP" but has merged into Google's A2A protocol, eliminating that conflict.
Rename to IACP — Interoperable Agent Client Protocol.
"IACP" retains "ACP" within it, preserving name recognition while adding disambiguation. "Interoperable" accurately describes the core value: any agent works with any editor.
- Searching "IACP" returns only our protocol
- Marketing materials don't require disambiguation footnotes
- Conference talks at OpenAI don't need "not the OpenAI one" clarifications
- The name itself communicates the value proposition (interoperability)
| Registry | Current | New |
|---|---|---|
| npm | @agentclientprotocol/sdk + 4 related packages | @iacp/sdk |
| PyPI | agent-client-protocol | iacp |
| crates.io | agent-client-protocol + 5 dependent crates | iacp |
| crates.io | agent-client-protocol-schema | iacp-schema |
| Maven | com.agentclientprotocol:* (20 artifacts) | com.iacp:* |
| pub.dev | acp_dart | iacp_dart |
| hex.pm | acpex | iacpex |
| Go | github.com/coder/acp-go-sdk | github.com/coder/iacp-go-sdk |
| Swift | acp-swift-sdk | iacp-swift-sdk |
| NuGet | AgentClientProtocol | IACP |
| Asset | Current | New |
|---|---|---|
| Domain | agentclientprotocol.com | iacp.dev |
| GitHub org | agentclientprotocol | iacp-protocol |
| Zulip | agentclientprotocol.zulipchat.com | iacp.zulipchat.com |
64 projects maintained by 59 individuals who would need to do work:
Beyond code, a rename invalidates existing educational content. Authors would need to update or their content becomes outdated/confusing:
Official documentation:
- agentclientprotocol.com — official protocol docs
- JetBrains AI Assistant docs — integration documentation
- Zed external agents docs — editor documentation
- OpenHands IDE integration docs — CLI ACP integration
- Docker cagent docs — cagent ACP integration
- Vercel AI SDK provider — community provider docs
Blog posts:
- Bring Your Own Agent to Zed — Nathan Sobo
- JetBrains × Zed: Open Interoperability
- Intro to ACP — Rizel Scarlett
- Use AI Agents in Your Favorite Editor through ACP — Graham Neubig
- Agent Client Protocol: The LSP for AI Coding Agents
- Making Agentic Editing Portable — Joshua Berkowitz
- Breaking the IDE Prison — Slava Kurilyak
- ACP Explained
- Open Agent Client Protocol — Shubham Saboo
- Google, Zed fight VS Code lock-in — Tim Anderson
- From Autocomplete to Autonomous — Saeed Zarinfam
- ACP and the Future of AI-Powered IDEs — Ashvit
- ACP101 — Roshan Ravani
Video tutorials:
- Building an AI Agent for Zed in 15 Lines — Chris Hay
- Vibe Code with goose: Intro to ACP — Rizel Scarlett
These authors invested time creating content referencing "ACP" and "Agent Client Protocol." A rename means their work becomes stale or requires updates they may never make.
Phase 1: Reserve new package names, register iacp.dev, rename GitHub org
Phase 2: Publish SDKs under new names, add deprecation notices to old packages (which will exist forever)
Phase 3: Redirect domain, update docs, support community migration
Preemptive brand protection. Despite our repository existing three months before theirs and having orders of magnitude more adoption, some believe OpenAI's backing from Stripe, PayPal, and Salesforce creates confusion risk. If true, acting now costs less than acting later.
Do nothing. OpenAI's Agentic Commerce Protocol targets e-commerce vendors integrating with ChatGPT. Our ACP targets coding tool developers. These audiences do not overlap. A developer searching for "ACP coding agent" will not find payment processing docs. A merchant searching for "ACP Stripe integration" will not find editor protocols.
The protocols serve completely different purposes:
- Ours: editor ↔ agent communication for software development
- Theirs: payment ↔ agent communication for e-commerce
npm download data: @agentclientprotocol/sdk has 278,000 downloads/month; agentic-commerce-protocol has 30.
There is no legal conflict. There is no proven user confusion. There is no trademark dispute. IBM's "ACP" already merged into Google A2A without requiring us to change. We had the name first. Our ACP repository existed three months before OpenAI created theirs.
Renaming would force 59 individuals to do unpaid work across 64 projects, mass-deprecate packages on 9 registries, and invalidate educational content from independent authors who receive nothing in return.
If this protocol becomes the dominant standard for editor-agent communication, "ACP" becomes synonymous with us through usage. "USB" means one thing despite other acronym collisions. OpenAI can differentiate as "Agentic Commerce Protocol" while we remain "Agent Client Protocol."
The burden of proof should be on renaming, not on keeping the name.
IACP is an arbitrary choice. "Interoperable" is redundant; every protocol is interoperable by definition.
The only argument for IACP over a completely new name is that "which ACP? IACP" might work in conversation for people already familiar with the protocol. This is weak.
Other names considered (PAP, CAP, C2A) collide with existing terms, but a completely new name unrelated to "ACP" would work just as well and might be cleaner.
Every maintainer listed above must: rename repos, update package names, change imports, update documentation, publish new packages, and field questions from confused users. Some won't bother and their projects will rot with the old name forever. Tutorials and blog posts become outdated. Search results split between old and new names. Newcomers encounter confusing history.
Yes. People who followed the first deprecation to @agentclientprotocol/sdk will see another deprecation pointing elsewhere. This is annoying and erodes trust.