> ## Documentation Index > Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt > Use this file to discover all available pages before exploring further. # Roadmap > AdCP protocol roadmap: RFCs, epics, and development milestones tracked on our public GitHub Project board. The AdCP roadmap is a public [GitHub Project board](https://github.com/orgs/adcontextprotocol/projects/1) tracking protocol RFCs and epics across all domains. It shows what we're exploring, what's accepted, what's in progress, and what's shipped. Live board with RFCs and epics across Creative, Media Buy, Signals, Governance, and more. *** ## Active release cycles ### 3.2 release-candidate readiness The final beta and RC preparation are focused on making the compact commercial lifecycle usable, verifiable, and legible—not adding another broad feature wave. | Workstream | Release outcome | | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Principal + reporting end-to-end cycle](https://github.com/adcontextprotocol/adcp/issues/7075) | Carry the experimental principal layer and tiered reporting from protocol through SDKs, reference implementations, docs, training, and implementation pilots. | | [Hosted verification reliability](https://github.com/adcontextprotocol/adcp/issues/7061) | External agents are not failed by runner discovery, capability-gating, credential, version, or timeout defects. | | [Enterprise protocol positioning](https://github.com/adcontextprotocol/adcp/issues/7062) | The docs explain why production adopters should use maintained SDKs and where the 3.2 commercial boundary sits. | | [Publish the elected AgenticAdvertising.org board](https://github.com/adcontextprotocol/adcp/issues/7055) | The post-AGM board and governance record replace incorporation-era interim information. | The exact candidate scope remains visible in the [3.2.0 milestone](https://github.com/adcontextprotocol/adcp/milestone/7). ### 3.3 working-group cycle 3.3 will deepen production operation around the lifecycle without forcing breaking changes that belong in 4.0. | Workstream | Questions to resolve | | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | [Acts-for authority and multi-agent delegation](https://github.com/adcontextprotocol/adcp/issues/7063) | Portable delegation, revocation, pure-buyer signing, and specialist-agent boundaries. | | [Post-acceptance commercial lifecycle](https://github.com/adcontextprotocol/adcp/issues/7064) | Payment terms, FX, fees, settlement, disputes, credits, and makegoods. | | [Cross-channel maturity and offline depth](https://github.com/adcontextprotocol/adcp/issues/7065) | Channel-by-lifecycle evidence and the highest-value print, broadcast, OOH, and audio gaps. | | [Production security profile](https://github.com/adcontextprotocol/adcp/issues/7066) | A stronger testable 3.x deployment floor and migration path to mandatory 4.0 controls. | | [Capability and routing ergonomics](https://github.com/adcontextprotocol/adcp/issues/7067) | Role-oriented views and precise claims for partial lifecycle implementations. | | [Production evidence program](https://github.com/adcontextprotocol/adcp/issues/7068) | Consent-based, machine-observed evidence of exact versions, tasks, environments, and lifecycle stages. | Each issue starts in exploration and carries `needs-wg-review`. Working groups will select bounded 3.3 slices from adopter evidence; incompatible identity, account, or security changes move to the 4.0 accumulation window. ## Where contributions are needed now AdCP is actively seeking implementations and domain expertise—not only schema suggestions—in these areas: | Area | Useful contribution | | --------------------- | ---------------------------------------------------------------------------------------------------------------- | | Verification | Run the RC profile against an independently operated agent and contribute reproducible runner failures or fixes. | | Authorization | Bring real buyer, agency, delegated-operator, and specialist-agent topologies with revocation requirements. | | Commercial operations | Bring finance and ad-operations workflows for invoicing, FX, disputes, credits, and makegoods. | | Offline channels | Bring print, broadcast, OOH, and place-based-audio examples through delivery evidence and reconciliation. | | Security | Review the production profile, threat model, key lifecycle, SSRF boundaries, and compromised-agent controls. | | Production evidence | Contribute opt-in, redacted observations that distinguish sandbox, transaction, delivery, and reconciliation. | Join the relevant [working group](/dist/docs/3.2.0-beta.10/community/working-group), comment on the linked issue, or bring a runnable implementation and test fixture. Evidence from production behavior carries more weight than a hypothetical object model. *** ## How the Roadmap Works The board has four columns representing the lifecycle of a roadmap item: | Status | Meaning | | --------------- | ----------------------------------------- | | **Exploring** | Under discussion, community input welcome | | **Accepted** | Committed and scoped, not yet started | | **In Progress** | Active work | | **Shipped** | Released and available | Each item has two fields: * **Protocol** — which area of the protocol it affects (Creative, Media Buy, Signals, Brand Protocol, Governance, SI, TMP, Platform, Website, Addie, Certification) * **Kind** — whether it's an **RFC** (protocol change needing community input) or an **Epic** (major deliverable spanning multiple PRs) *** ## What Belongs on the Roadmap Not every issue or PR belongs here. Roadmap items are protocol-level changes, new capabilities, and strategic initiatives that affect adopters. An issue qualifies if it meets at least two of: 1. **Protocol surface** — changes what agents or platforms interact with 2. **Audience impact** — would influence a prospective member's or builder's decision 3. **Multi-issue scope** — spans more than one PR Bug fixes, minor improvements, and internal tooling stay in the [issue tracker](https://github.com/adcontextprotocol/adcp/issues). *** ## Adding Items to the Roadmap Any issue labeled `rfc` or `epic` is automatically added to the board. To propose a roadmap item: 1. **Open a GitHub issue** describing the proposal 2. **Add the `rfc` or `epic` label** (maintainers can also do this during triage) 3. The issue appears in the **Exploring** column 4. A maintainer sets the **Protocol** and **Kind** fields on the board *** ## Triage and working-group review Maintainers triage new roadmap candidates into the relevant working group. Items carrying `needs-wg-review` are explicit agenda candidates: the group must validate the adopter problem, choose the smallest interoperable slice, identify an implementation owner, and decide whether the work is additive in 3.3 or belongs in the 4.0 breaking-change window. The board is reviewed monthly for stale status, missing owners, and roadmap items that lack implementation evidence. To lead or contribute to a cycle, comment on its issue and join the relevant working-group channel on Slack. *** ## Version Milestones Named milestones group roadmap items that will ship together in a future major version. Each milestone lists accepted RFCs — exploratory items (community input open) remain on the main board until maintainers decide to land them. ### v4.0 — target early 2027 v4.0 is the next **breaking-changes accumulation window**, targeted for early 2027 under the [release cadence policy](/dist/docs/3.2.0-beta.10/reference/versioning#release-cadence). Breaking changes are gathered here so the ecosystem can plan a single migration window rather than chase per-minor deprecations. Items listed below are committed floor requirements for v4.0; additional items will be added here as RFCs are accepted. | Area | Item | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Security (floor) | [Mandatory request signing for spend-committing operations (RFC 9421)](https://github.com/adcontextprotocol/adcp/issues/2307) — the 3.0 optional profile in `security.mdx` becomes required. Agents MUST sign spend-committing operations; sellers MUST verify. | | Canonical formats | Remove every exact `format_ids` field. Products use `format_options`; package selection uses `format_option_refs` or direct canonical selectors; filters and registry payloads use their canonical-format equivalents. The deprecated fields remain accepted only through 3.x. | This milestone is intentionally not a "security release." It is the version where accumulated breaking changes across protocol surfaces land together. Request signing is the current floor requirement; other accepted RFCs carrying breaking changes will be added here as they progress through the `rfc` label lifecycle on the main board. *** ## Release History For detailed release notes and version history, see: * **[Release Notes](./release-notes)** — per-version feature summaries * **[CHANGELOG.md](https://github.com/adcontextprotocol/adcp/blob/main/CHANGELOG.md)** — technical changelog * **[GitHub Releases](https://github.com/adcontextprotocol/adcp/releases)** — release archive * **[Versioning & Governance](./versioning)** — versioning model and release cadence *** ## Get Involved AdCP is developed in the open with active working groups on Slack. * **[Join the community Slack](/dist/docs/3.2.0-beta.10/community/joining-slack)** * **[GitHub Discussions](https://github.com/adcontextprotocol/adcp/discussions)** * **[Working Groups](../community/working-group)**