The following is an interim governance model to provide clearer roles and
responsibilities between the various parties collaborating on ACP.
ACP is jointly governed by Zed and JetBrains, who collaborate to ensure the
protocol serves the broader ecosystem. We aim to operate transparently and
make decisions in the best interests of ACP and its community, while working
toward transitioning to an independent foundation.
This document describes the governance model for the Agent Client Protocol (ACP). It defines the roles, responsibilities, and processes that guide how the project operates and makes decisions.
## Principles
We aim to operate transparently and make decisions in the best interests of ACP and its community.
## Technical Governance
The ACP project adopts a hierarchical structure, similar to MCP, Rust Foundation projects, and other open source projects:
* A community of **contributors** who file issues, make pull requests, and contribute to the project.
* A small set of **maintainers** drive components within the ACP project, such as SDKs, documentation, and others.
* Contributors and maintainers are overseen by **core maintainers**, who drive the overall project direction.
* The core maintainers have two **lead core maintainers** who are the catch-all decision makers.
* Maintainers, core maintainers, and lead core maintainers form the **ACP steering group**.
All maintainers are expected to have a strong bias towards ACP's design philosophy.
### Channels
Technical Governance is facilitated through shared [communication channels](/community/communication) of all **maintainers, core maintainers** and **lead maintainers**. Each maintainer group can choose additional communication channels, but all decisions and their supporting discussions must be recorded and made transparently available in one of the main communication channels.
### Contributors
Anyone who submits code, documentation or other improvements is counted as a contributor. Contributors do not have formal decision-making power, but are encouraged to participate in discussions about project direction and propose changes.
### Maintainers
Maintainers are responsible for [Working or Interest Groups](/community/working-interest-groups) within the ACP project. These generally are independent repositories such as language-specific SDKs, but can also extend to subdirectories of a repository, such as the ACP documentation. Maintainers may adopt their own rules and procedures for making decisions. Maintainers are expected to make decisions for their respective projects independently, but can defer or escalate to the core maintainers when needed.
Maintainers are responsible for the:
* Thoughtful and productive engagement with community contributors,
* Maintaining and improving their respective area of the ACP project,
* Supporting documentation, roadmaps and other adjacent parts of the ACP project,
* Present ideas from community to core.
New maintainers are added by a consensus or majority vote of the current core maintainers, based on sustained and high-quality contributions to the project, alignment with its goals, and a demonstrated commitment to community standards. Prospective maintainers should have a track record of participation in discussions, issue triage, and code or documentation improvements.
Maintainers have write and/or admin access to their respective repositories.
A maintainer may step down at any time by notifying the other maintainers. In rare cases, a maintainer may be removed by a consensus or a two-thirds supermajority vote of the other maintainers if they are inactive for an extended period, violate the Code of Conduct, or act against the project’s interests. Maintainers can be removed by core maintainers or lead core maintainers at any time and without reason.
### Core Maintainers
Core maintainers are contributors who have write access to ACP’s source code. They review and merge contributions, participate in project decision-making, and help to onboard and mentor new contributors. The core maintainers are expected to have a deep understanding of the Agent Client Protocol and its specification. Their responsibilities include:
* Designing, reviewing and steering the evolution of the ACP specification, as well as all other parts of the ACP project, such as documentation,
* Articulating a cohesive long-term vision for the project,
* Mediating and resolving contentious issues with fairness and transparency, seeking consensus where possible while making decisive choices when necessary,
* Appoint or remove maintainers,
* Stewardship of the ACP project in the best interest of ACP.
The core maintainers as a group have the power to veto any decisions made by maintainers by majority vote. The core maintainers have power to resolve disputes as they see fit. The core maintainers should publicly articulate their decision-making. The core group is responsible for adopting their own procedures for making decisions.
New core maintainers are added by a consensus or majority vote of the current core and lead maintainers, based on sustained and high-quality contributions to the project, alignment with its goals, and a demonstrated commitment to community standards. Prospective maintainers should have a track record of participation in discussions, issue triage, and code or documentation improvements.
Core maintainers generally have write and admin access to all ACP repositories, but should use the same contribution (usually pull-requests) mechanism as outside contributors. Exceptions can be made based on security considerations.
A core maintainer may step down at any time by notifying the other core maintainers. In rare cases, a core maintainer may be removed by a consensus or a two-thirds supermajority vote of the other core maintainers if they are inactive for an extended period, violate the Code of Conduct, or act against the project’s interests.
### Lead Maintainers (BDFL)
ACP has two lead maintainers: Ben Brandt (Zed Industries) and Sergey Ignatov (JetBrains). Lead Maintainers can veto any decision by core maintainers or maintainers. This model is also commonly known as Benevolent Dictator for Life (BDFL) in the open source community. The Lead Maintainers should publicly articulate their decision-making and give clear reasoning for their decisions. Lead maintainers are part of the core maintainer group.
Lead Maintainers are administrators on all infrastructure for the ACP project where possible. This includes but is not restricted to all communication channels, GitHub organizations and repositories.
The Lead Maintainers are the primary contacts, and responsible for:
* Representing ACP in official matters.
* Coordinating major decisions about project direction.
* Signing off project expenses.
A lead maintainer may step down by notifying the other lead maintainer(s). They may recommend a replacement, but it is the remaining lead maintainer(s) responsibility to select a replacement.
If all lead maintainers step down, the core maintainers will select new lead maintainers by consensus or majority vote.
### Decision Process
The core maintainer group meets every two weeks to discuss and vote on proposals, as well as discuss any topics needed. The [ACP RFD process](https://agentclientprotocol.com/rfds/about) and Zulip chat can be used to discuss and vote on smaller proposals as needed.
## Processes
Core and lead maintainers are responsible for all aspects of Agent Client Protocol, including documentation, issues, suggestions for content, and all other parts under the [ACP project](https://github.com/agentclientprotocol). Maintainers are responsible for documentation, issues, and suggestions of content for their area of the ACP project, but are encouraged to partake in general maintenance of the ACP projects. Maintainers, core maintainers, and lead maintainers should use the same contribution process as external contributors, rather than making direct changes to repos. This provides insight into intent and opportunity for discussion.
### Working and Interest Groups
ACP collaboration and contributions are organized around two structures: [Working Groups and Interest Groups](/community/working-interest-groups).
Interest Groups are responsible for identifying and articulating problems that ACP should address, primarily by facilitating open discussions within the community. In contrast, Working Groups focus on developing concrete solutions by collaboratively producing deliverables, such as RFDs or community-owned implementations of the specification. While input from Interest Groups can help justify the formation of a Working Group, it is not a strict requirement. Similarly, contributions from either Interest Groups or Working Groups are encouraged, but not mandatory, when submitting RFDs or other community proposals.
We strongly encourage all contributors interested in working on a specific RFD to first collaborate within an Interest Group. This collaborative process helps ensure that the proposed RFD aligns with protocol needs and is the right direction for its adopters.
### Governance Principles
All groups are self-governed while adhering to these core principles:
1. Clear contribution and decision-making processes
2. Open communication and transparent decisions
They must:
* Document their contribution process
* Maintain transparent communication
* Make decisions publicly (groups must publish meeting notes and proposals)
Projects and working groups without specified processes default to:
* GitHub pull requests and issues for contributions
* A public channel in the official [ACP Contributor Zulip](/community/communication#zulip)
### Maintenance Responsibilities
Components without dedicated maintainers (such as documentation) fall under core maintainer responsibility. These follow standard contribution guidelines through pull requests, with maintainers handling reviews and escalating to core maintainer review for any significant changes.
Core maintainers and maintainers are encouraged to improve any part of the ACP project, regardless of formal maintenance assignments.
## Communication
### Core Maintainer Meetings
The core maintainer group meets on a bi-weekly basis to discuss proposals and the project. Notes on proposals should be made public. The meetings themselves are invite-only. If you have a topic for the Core Maintainers and want to be added to the agenda, let the core maintainers know what you want to discuss in advance in Zulip, and you will be invited to join the next meeting.
### Public Chat
The ACP project maintains a [public Zulip Chat](/community/communication#zulip) with open chats for different groups. The ACP project may have private channels for certain communications.
## Nominating, Confirming and Removing Maintainers
### The Principles
* Membership in module maintainer groups is given to individuals on merit basis after they demonstrated strong expertise of their area of work through contributions, reviews, and discussions and are aligned with the overall ACP direction.
* For membership in the maintainer group the individual has to demonstrate strong and continued alignment with the overall ACP principles.
* No term limits for module maintainers or core maintainers
* Light criteria of moving sub-project maintenance to 'emeritus' status if they don't actively participate over long periods of time. Each maintainer group may define the inactive period that's appropriate for their area.
### Nomination and Removal
* Core Maintainers are responsible for adding and removing maintainers. They will take the consideration of existing maintainers into account.
* The lead maintainers are responsible for adding and removing core maintainers.
#### Nomination Process
If a Maintainer (or Core / Lead Maintainer) wishes to propose a nomination for the Core / Lead Maintainers’ consideration, they should follow the following process:
1. Collect evidence for the nomination. This will generally come in the form of a history of merged PRs on the repositories for which maintainership is being considered.
2. Discuss among maintainers of the relevant group(s) as to whether they would be supportive of approving the nomination.
3. DM a Core Maintainer to create a private channel in Zulip, in the format `nomination-{name}-{group}`. Add all core maintainers, lead maintainers, and co-maintainers on the relevant group.
4. Provide context for the individual under nomination. See below for suggestions on what to include here.
5. Create a Zulip topic and ask Core / Lead Maintainers to vote Yes / No on the nomination. Reaching consensus is encouraged though not required.
6. After Core / Lead Maintainers discuss and/or vote, if the nomination is favorable, relevant members with permissions to update GitHub and Zulip roles will add the nominee to the appropriate groups. The nominator should announce the new maintainership in the relevant Zulip channel.
7. The temporary Zulip channel will be deleted a week later.
Suggestions for the kind of information to share with core maintainers when nominating someone:
* GitHub profile link, LinkedIn profile link, Zulip username
* For what group(s) are you nominating the individual for maintainership
* Whether the group(s) agree that this person should be elevated to maintainership
* Description of their contributions to date (including links to most substantial contributions)
* Description of expected contributions moving forward (e.g. Are they eager to be a maintainer? Will they have capacity to do so?)
* Other context about the individual (e.g. current employer, motivations behind ACP involvement)
* Anything else you think may be relevant to consider for the nomination
## Current Maintainers
Refer to [the maintainer list](https://github.com/agentclientprotocol/agent-client-protocol/blob/main/MAINTAINERS.md).
## Security Policy and Vulnerability Disclosure
* Zed will triage all potential security and vulnerability issues between the Zed team and other maintainers
* Reports can be submitted to [security@zed.dev](mailto:security@zed.dev)
## Legal, Licensing, and Contributor Terms
* All repositories in the ACP organization should be licensed under the Apache 2.0 License.
* This project does not require a Contributor License Agreement (CLA). Instead, contributions are accepted under the following terms:
> By contributing to this project, you agree that your contributions will be licensed under the [Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0). You affirm that you have the legal right to submit your work, that you are not including code you do not have rights to, and that you understand contributions are made without requiring a Contributor License Agreement (CLA).
# Working and Interest Groups
Source: https://agentclientprotocol.com/community/working-interest-groups
Learn about the two forms of collaborative groups within the Agent Client Protocol's governance structure - Working Groups and Interest Groups.
Within the ACP contributor community we maintain two types of collaboration formats - **Interest** and **Working** groups.
**Interest Groups** are responsible for identifying and articulating problems that ACP should address, primarily by facilitating open discussions within the community. In contrast, **Working Groups** focus on developing concrete solutions by collaboratively producing deliverables, such as RFDs or community-owned implementations of the specification.
While input from Interest Groups can help justify the formation of a Working Group, it is not a strict requirement. Similarly, contributions from either Interest Groups or Working Groups are encouraged, but not mandatory, when submitting RFDs or other community proposals.
We strongly encourage all contributors interested in working on a specific RFD to first collaborate within an Interest Group. This collaborative process helps ensure that the proposed RFD aligns with community needs and is the right direction for the protocol.
Long-term projects in the ACP ecosystem, such as SDKs or other components are maintained by dedicated Working Groups.
## Purpose
These groups exist to:
* **Facilitate high-signal spaces for focused discussions** - contributors who opt into notifications, expertise sharing, and regular meetings can engage with topics that are highly relevant to them, enabling meaningful contributions and opportunities to learn from others.
* **Establish clear expectations and leadership roles** - guide collaborative efforts and ensure steady progress toward concrete deliverables that advance ACP evolution and adoption.
## Mechanisms
## Meeting Calendar
All Interest Group and Working Group meetings are published on the public ACP community calendar (work in progress).
Facilitators are responsible for posting their meeting schedules to this calendar in advance to ensure discoverability and enable broader community participation.
### Interest Groups (IGs)
**Goal:** Facilitate discussion and knowledge-sharing among ACP contributors who share interests in a specific ACP sub-topic or context. The primary focus is on identifying and gathering problems that may be worth addressing through RFDs or other community artifacts, while encouraging open exploration of protocol issues and opportunities.
**Expectations**:
* Regular conversations in the Interest Group Zulip channel
* **AND/OR** a recurring live meeting regularly attended by Interest Group members
* Meeting dates and times published in advance on the ACP community calendar when applicable, and tagged with their primary topic and interest group Zulip channel name
* Notes publicly shared after meetings, and submitted to the [meetings repository](https://github.com/agentclientprotocol/meetings)
**Lifecycle**:
* Creation begins by proposing a new Interest Group to the core/lead maintainers with the template below
* Majority positive vote by core maintainers over a 72h period approves creation of the group.
* The creation of the group can be reversed at any time (e.g., after new information surfaces). Core and lead maintainers can veto.
* Facilitator(s) and Maintainer(s) responsible for organizing IG into meeting expectations
* Facilitator is an informal role responsible for shepherding or speaking for a group
* Maintainer is an official representative from the ACP steering group. A maintainer is not required for every group, but can help advocate for specific changes or initiatives.
* IG is retired only when Core or Lead Maintainers determine it's no longer active and/or needed
* Successful IGs do not have a time limit or expiration date - as long as they are active and maintained, they will remain available
**Creation Template**:
* Facilitator(s)
* Maintainer(s) (optional)
* IGs with potentially similar goals/discussions
* How this IG differentiates itself from the related IGs
* First topic you to discuss within the IG
Participation in an Interest Group (IG) is not required to start a Working Group (WG) or to create a RFD. However, building consensus within IGs can be valuable when justifying the formation of a WG. Likewise, referencing support from IGs or WGs can strengthen a RFD and its chances of success.
### Working Groups (WG)
**Goal:** Facilitate collaboration within the ACP community on a RFD, a themed series of RFDs, or an otherwise officially endorsed project.
**Expectations**:
* Meaningful progress towards at least one RFD or spec-related implementation **OR** hold maintenance responsibilities for a project (e.g., SDKs)
* Facilitators are responsible for keeping track of progress and communicating status when appropriate
* Meeting dates and times published in advance on the ACP community calendar when applicable, and tagged with their primary topic and working group Zulip channel name
* Notes publicly shared after meetings, and submitted to the [meetings repository](https://github.com/agentclientprotocol/meetings)
**Lifecycle**:
* Creation begins by proposing a new Interest Group to the core/lead maintainers with the template below
* Majority positive vote by core maintainers over a 72h period approves creation of the group.
* The creation of the group can be reversed at any time (e.g., after new information surfaces). Core and lead maintainers can veto.
* Facilitator(s) and Maintainer(s) responsible for organizing WG into meeting expectations
* Facilitator is an informal role responsible for shepherding or speaking for a group
* Maintainer is an official representative from the ACP steering group. A maintainer is not required for every group, but can help advocate for specific changes or initiatives
* WG is retired when either:
* Community moderators or Core and Lead Maintainers decide it is no longer active and/or needed
* The WG no longer has an active Issue/PR for a month or more, or has completed all Issues/PRs it intended to pursue.
**Creation Template**:
* Facilitator(s)
* Maintainer(s) (optional)
* Explanation of interest/use cases, ideally originating from an IG discussion; however that is not a requirement
* First Issue/PR/RFD that the WG will work on
## WG/IG Facilitators
A **Facilitator** role in a WG or IG does *not* result in a [maintainership role](https://github.com/agentclientprotocol/agent-client-protocol/blob/main/MAINTAINERS.md) across the ACP organization. It is an informal role into which anyone can self-nominate.
A Facilitator is responsible for helping shepherd discussions and collaboration within an Interest or Working Group.
Lead and Core Maintainers reserve the right to modify the list of Facilitators and Maintainers for any WG/IG at any time.
## FAQ
### How do I get involved contributing to ACP?
These IG and WG abstractions help provide an elegant on-ramp:
1. [Join the Zulip](/community/communication#zulip) and follow conversations in IGs relevant to you. Attend live calls. Participate.
2. Offer to facilitate calls. Contribute your use cases in RFD proposals and other work.
3. When you're comfortable contributing to deliverables, jump in to contribute to WG work.
4. Active and valuable contributors will be nominated by WG maintainers as new maintainers.
### Where can I find a list of all current WGs and IGs?
On the [ACP Zulip Chat](/community/communication#zulip) there is a section of channels for each Working and Interest Group.
# Agents
Source: https://agentclientprotocol.com/get-started/agents
Agents implementing the Agent Client Protocol.
The following agents can be used with an ACP Client:
* [AgentPool](https://phil65.github.io/agentpool/advanced/acp-integration/)
* [Augment Code](https://docs.augmentcode.com/cli/acp)
* [AutoDev](https://github.com/phodal/auto-dev)
* [Blackbox AI](https://docs.blackbox.ai/features/blackbox-cli/introduction)
* [Bub](https://github.com/bubbuild/bub) (via [bub-acp-server](https://github.com/bubbuild/bub-contrib/tree/main/packages/bub-acp-server))
* [Claude Agent](https://platform.claude.com/docs/en/agent-sdk/overview) (via [Zed's SDK adapter](https://github.com/zed-industries/claude-agent-acp))
* [Cline](https://cline.bot/)
* [Codex CLI](https://developers.openai.com/codex/cli) (via [Zed's adapter](https://github.com/zed-industries/codex-acp))
* [Code Assistant](https://github.com/stippi/code-assistant?tab=readme-ov-file#configuration)
* [crow-cli](https://crow-ai.dev)
* [Cursor](https://cursor.com/docs/cli/acp)
* [Docker's cagent](https://github.com/docker/cagent)
* [fast-agent](https://fast-agent.ai/acp)
* [Factory Droid](https://factory.ai/)
* [fount](https://github.com/steve02081504/fount)
* [Gemini CLI](https://github.com/google-gemini/gemini-cli)
* [GitHub Copilot](https://github.com/features/copilot) (in [public preview](https://github.blog/changelog/2026-01-28-acp-support-in-copilot-cli-is-now-in-public-preview/))
* [Goose](https://block.github.io/goose/docs/guides/acp-clients)
* [Hermes Agent](https://hermes-agent.nousresearch.com/docs/user-guide/features/acp)
* [Junie by JetBrains](https://junie.jetbrains.com/)
* [Kimi CLI](https://github.com/MoonshotAI/kimi-cli)
* [Kiro CLI](https://kiro.dev/docs/cli/acp/)
* [Minion Code](https://github.com/femto/minion-code)
* [Mistral Vibe](https://github.com/mistralai/mistral-vibe)
* [OpenClaw](https://docs.openclaw.ai/cli/acp)
* [OpenCode](https://github.com/sst/opencode)
* [OpenHands](https://docs.openhands.dev/openhands/usage/run-openhands/acp)
* [Pi](https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent) (via [pi-acp adapter](https://github.com/svkozak/pi-acp))
* [Poolside](https://github.com/poolsideai/pool)
* [Qoder CLI](https://docs.qoder.com/cli/acp)
* [Qwen Code](https://github.com/QwenLM/qwen-code)
* [siGit Code](https://github.com/getsigit/sigit)
* [Stakpak](https://github.com/stakpak/agent?tab=readme-ov-file#agent-client-protocol-acp)
* [stdio Bus](https://github.com/stdiobus/stdiobus)
* [VT Code](https://github.com/vinhnx/vtcode/blob/main/README.md#zed-ide-integration-agent-client-protocol)
# Architecture
Source: https://agentclientprotocol.com/get-started/architecture
Overview of the Agent Client Protocol architecture.
The Agent Client Protocol defines a standard interface for communication between AI agents and client applications. The architecture is designed to be flexible, extensible, and platform-agnostic.
## Design Philosophy
The protocol architecture follows several key principles:
1. **MCP-friendly**: The protocol is built on JSON-RPC, and re-uses MCP types where possible so that integrators don't need to build yet-another representation for common data types.
2. **UX-first**: It is designed to solve the UX challenges of interacting with AI agents; ensuring there's enough flexibility to render clearly the agents intent, but is no more abstract than it needs to be.
3. **Trusted**: ACP works when you're using a code editor to talk to a model you trust. You still have controls over the agent's tool calls, but the code editor gives the agent access to local files and MCP servers.
## Setup
When the user tries to connect to an agent, the editor boots the agent sub-process on demand, and all communication happens over stdin/stdout.
Each connection can support several concurrent sessions, so you can have multiple trains of thought going on at once.