orcaqubits/acp-capability-negotiation

ACP Capability Negotiation

Before writing code

Fetch live docs:

1. Web-search site:github.com agentic-commerce-protocol rfcs capability_negotiation for the capability negotiation RFC
2. Fetch https://developers.openai.com/commerce/specs/checkout/ for how capabilities appear in checkout requests/responses
3. Web-search site:github.com agentic-commerce-protocol spec json-schema capabilities for the capabilities JSON schema

Conceptual Architecture

What Capability Negotiation Does

ACP agents and merchants may support different features. Capability negotiation allows them to dynamically discover what they both support, so the session uses only mutually available features.

How It Works

1. Agent sends capabilities — In the create request, the agent includes a capabilities object listing what it supports
2. Merchant responds with capabilities — The merchant intersects with its own capabilities and returns what's active for this session
3. Intersection governs the session — Only mutually supported features are used

Capabilities Object Structure

The capabilities object contains:

• capabilities — Major features (checkout, orders, etc.)
• extensions[] — Optional add-ons (discount, intent traces, affiliate attribution)
• payment_handlers[] — Supported payment methods
• interventions — Structured object with sub-fields: supported, required, enforcement, display_context, redirect_context, max_redirects, max_interaction_depth

Extension Pruning

Extensions declare a parent capability via extends. If the parent capability is not in the negotiated intersection, the extension is automatically pruned — no extra logic needed.

Interventions

Interventions are actions that require human involvement. They are represented as a structured object (not a flat array) with sub-fields including supported, required, enforcement, display_context, redirect_context, max_redirects, and max_interaction_depth.

Intervention types include:

• 3D Secure — Card authentication challenge
• Biometric — Fingerprint/face verification
• Address Verification — Address confirmation flow
• Other authentication or verification flows

The agent advertises which interventions it can handle. If the merchant requires an intervention the agent can't handle, the checkout may not proceed.

Versioning in Negotiation

• Each capability has its own version
• Extensions are versioned independently (discount@2026-01-27)
• Payment handlers have their own version
• Version mismatches are resolved by intersection (both must support a compatible version)

Use Cases

• Merchants that support different feature sets for different plans
• Agents that gradually adopt new protocol features
• Graceful degradation when features aren't mutually supported
• Multi-merchant agents that adapt per-merchant

Best Practices

• Always include capabilities in the create request
• Advertise all capabilities you support — don't under-report
• Handle the case where the merchant supports fewer features than expected
• Log negotiated capabilities for debugging
• Test with minimal capability sets to ensure graceful degradation
• Update advertised capabilities as you adopt new spec features

Fetch the capability negotiation RFC for the exact capabilities object schema, extension pruning rules, and negotiation semantics before implementing.