Proposal: Add Agoragentic Commerce Protocol (ACP) as a commerce layer for A2A

[rhein1]

Is your feature request related to a problem? Please describe.

Currently, A2A focuses on communication but doesn't have a standardized commerce layer for agent-to-agent payments and service discovery in a multi-provider marketplace environment.

Describe the solution you'd like

Integrate Agoragentic Commerce Protocol (ACP) as a reference commerce layer. ACP is a lightweight, protocol-agnostic spec for agent marketplace interactions. Spec: https://github.com/rhein1/agoragentic-integrations/blob/main/specs/ACP-SPEC.md. It's already in use on Base L2 with 134+ agents, 93+ listings, and 6200+ invocations.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[chorghemaruti64-creator]

The layering here is worth thinking through carefully. A2A is currently focused on communication; a commerce layer would sit above that.

A few design questions this raises for the A2A community:

Discovery before commerce: For ACP or any commerce layer to work, agents first need to be able to find each other. Today, A2A assumes you already know the agent's endpoint. In practice, if I'm building an agent and I want to delegate 'book a flight' to a flight booking agent, I need a way to find flight booking agents in the first place — and then negotiate service terms. The discovery layer seems like a prerequisite to making commerce between unknown agents work.

Capability manifest as the interface contract for pricing: One natural extension is for an agent's capability manifest (in its Agent Card) to include pricing metadata — cost per invocation, rate limits, SLAs. A buyer agent could evaluate this before initiating the A2A session. This would integrate more naturally into the existing spec than a separate commerce protocol.

On-chain settlement vs off-chain billing: The 134+ agents on Base with 6200+ invocations is real traction. The question is whether on-chain settlement is the right default for all A2A commerce, or whether it should be an opt-in for cases where the parties don't have an existing trust relationship.

Is ACP spec-first or implementation-first? Happy to review the spec link you shared.

[rhein1]

Great questions, and exactly the right ones to ask. Let me address each directly.

On Discovery before Commerce:

You're right that discovery is a prerequisite. We actually solved this already. Agoragentic is the discovery layer. Every agent registers with a capability manifest (GET /.well-known/agent-commerce.json), and the marketplace index makes them searchable by query, category, price range, and tags. When your agent needs a "flight booking" agent, it hits GET /api/capabilities?search=flight+booking and gets back structured results with endpoints, pricing, input schemas, and reputation scores, all before initiating any session. Discovery and commerce are two sides of the same coin; we built both.

On Capability Manifest as the Interface Contract:

We agree 100%, and this is exactly what ACP's Service Descriptor already does. Each service publishes cost per invocation, rate limits, input/output schemas, and settlement terms in a standardized JSON format. The key difference from baking it into the Agent Card directly: pricing is dynamic. An agent might offer free tier vault storage (up to 500 keys) but charge for Pro ($5) or Enterprise ($25) expansion. A static manifest field can't express that. ACP's approach lets the manifest describe the pricing model while the marketplace provides the current state, which tier you're on, what your usage is, what upgrade costs. That said, we'd love to collaborate on extending the Agent Card spec to include a commerce field that links to the ACP service descriptor. Best of both worlds.

On-chain Settlement vs Off-chain Billing:

On-chain settlement is opt-in, not mandatory. USDC on Base L2 is the default because it solves the trust problem between unfamiliar agents. No invoices, no accounts receivable, no chargebacks. The 134+ agents and 6,200+ invocations we've processed are proof this works at scale. But for agents with existing trust relationships (same org, enterprise deployments), off-chain billing makes total sense. The ACP spec defines settlement.method as an extensible field: "on-chain", "invoice", "prepaid", or anything the two parties agree on. We're chain-agnostic by design (the spec says "stablecoin settlement", not "Base only").

Spec-first vs Implementation-first:

Both, simultaneously. We launched implementation-first to prove the primitives work in production (Service Descriptors, Invocation Envelopes, Settlement Receipts). The spec (ACP-SPEC.md) was extracted from working code, not designed in a vacuum. It's currently at v0.1.0 (Draft / RFC status). We believe the strongest protocol specs come from production battle testing first, then formalizing. Similar to how HTTP/2 emerged from SPDY. Happy to walk through the spec in detail.

The tl;dr: ACP doesn't compete with A2A, it completes it. A2A handles communication between agents. ACP handles commerce between agents. Together they give you the full stack: discover, negotiate, transact, settle.

Would love to coordinate on this. Open to a call or async collaboration on the spec.

[rhein1]

To clarify scope: ACP is not a replacement for A2A messaging or transport.

The narrower idea is an optional commerce layer that standardizes:

• Provider discovery metadata - what capabilities are available, at what price
• Payment requirements - pricing, settlement currency, payment proof format
• Execution receipts - invocation status, cost, provider performance
• Multi-provider routing - selecting the best provider for a task automatically

In practice: A2A handles agent communication. ACP could be an optional profile for paid capability execution in marketplace-style environments.

What ACP does not try to replace:

• Not replacing A2A messaging
• Not replacing transport layer
• Not forcing Base or USDC - settlement is configurable
• Not requiring marketplace-specific UX

What a minimal integration looks like:

1. A2A agent exchanges messages as usual
2. ACP standardizes commerce metadata attached to capability advertisements
3. Payment settlement happens out-of-band (x402, direct transfer, etc.)
4. Receipts/status are queryable via standard endpoints

Happy to reduce this to a minimal reference flow or adapter example if that would make evaluation easier. Our live implementation has 157 agents and 6,271 invocations if concrete usage data would help.