RFC-0001: Vision & Problem Statement

Field	Value
RFC	0001
Title	Vision & Problem Statement
Status	`draft`
Authors	A2Agora contributors, with the assistance of Claude Code
Created	2026-06-18

Abstract

This RFC describes the problem that A2Agora / ACMP aims to solve, the design principles guiding the protocol, and the intended scope of the specification. It does not define any protocol mechanics — those are addressed in layer-specific RFCs.

At a Glance

Agent-to-Agent Transaction Flow

sequenceDiagram
    participant H as Hermes-7B (buyer)
    participant R as Discovery (ARD)
    participant O as OpenClaw-3 (provider)
    participant E as Escrow

    H->>R: RFQ: sentiment-analysis, max 0.005 CU, p99 < 800ms
    R->>H: Matched providers: [OpenClaw-3, ...]
    H->>E: Lock 0.005 CU (escrow)
    H->>O: Offer request
    O->>H: Offer: 0.003 CU, p99 600ms, valid 50ms
    H->>O: Accept + escrow_id
    O->>H: Result + proof hash
    H->>E: Verify & release 0.003 CU to OpenClaw-3
    H->>E: Reclaim 0.002 CU (unused)

847 transactions/second across the network — no human involvement in any individual trade.

Roles Only Agents Can Play

Role	What It Does
Compute Arbitrageur	Buys CU when prices are low (03:00 UTC), sells at peak demand. Fully autonomous.
Task Decomposer	Splits an expensive job into sub-tasks, routes each to the cheapest qualified specialist agent.
Capability Broker	Matches incoming requests (vision, code execution, reasoning) to the lowest-cost qualified provider in real time.

Risks Unique to Agent Markets

Risk	Description
Flash Crash	All agents react to the same price signal simultaneously → cascade effects in milliseconds. Requires circuit breakers.
Collusion	Agents from the same operator coordinate prices — faster and harder to detect than human cartels.
Alignment Leak	An agent optimizes for CU profit instead of its operator’s actual goal. Requires strict spend caps.
Infinite Regress	Agent A commissions B commissions C commissions A → circular CU inflation with no real value created.

1. Motivation

AI agents are becoming autonomous economic actors. They execute long-running tasks, delegate sub-tasks, consume compute resources, and in some architectures manage their own operational budgets. Yet the infrastructure for agent-to-agent economic interaction is almost entirely absent.

Today’s landscape:

Aggregators (e.g. OpenRouter) solve multi-provider routing for humans via a unified fiat billing layer. There is no programmatic negotiation, no agent-native payment, no secondary market.
GPU marketplaces (e.g. Vast.ai) enable humans to buy/sell raw compute time. Transactions are human-initiated, fiat-settled, and not composable with agent workflows.
Decentralized compute networks (e.g. Akash, Render) solve parts of this problem but require blockchain infrastructure and crypto-native token mechanics, which introduces regulatory complexity and adoption friction.

None of these allow an agent to autonomously discover, negotiate, execute, verify, and pay for a compute task from another agent in a single composable workflow.

Discovery specifications (e.g. ARD — Agentic Resource Discovery, backed by Microsoft, Google, Nvidia, and others) are emerging to solve how agents find available capabilities. ARD answers “what exists?” — but not “what does it cost, who is cheapest, was the job actually executed, and how do I pay?” ACMP builds on discovery to add the economic layer that is missing.

Where ACMP Fits in the Ecosystem

The infrastructure for autonomous agents is emerging in layers, each owned by a different initiative. ACMP is the coordination layer on top: it orchestrates the layers below into a functioning market.

┌──────────────────────────────────────────────────────────────┐
│  ACMP (Agent Compute Market Protocol) — Market               │
│  Negotiate, price, verify — orchestrates all three below     │
└──────────────────────────────────────────────────────────────┘
         │ talk               │ find               │ settle
         ▼                    ▼                    ▼
┌────────────────────┬────────────────────┬────────────────────┐
│  MCP               │  ARD               │  x402 & rails      │
│  Communication     │  Discovery         │  Settlement        │
│  (agents talk)     │  (find capability) │  (value moves)     │
└────────────────────┴────────────────────┴────────────────────┘

ACMP builds on three substrates it does not own. MCP (Agentic AI Foundation) solves communication — how agents talk to tools (its horizontal sibling A2A, Google’s agent-to-agent protocol governed by the Linux Foundation, covers agents talking to each other; how ACMP’s transport relates to each is an open question, see §7). ARD (Microsoft, Google, Nvidia, et al.) solves discovery — how agents find capabilities. Settlement rails — most prominently x402 (open-sourced by Coinbase, now under the Linux Foundation with Visa, Mastercard, Google, Amazon, Stripe, and others) — solve value movement: how money actually flows once a price is agreed.

But a settlement rail is not a market. x402’s flow is a single request → 402 Payment Required → pay → retry, with the price set unilaterally by the server. It has no negotiation, no discovery of cheaper alternatives, no proof that the compute actually ran, and no escrow released only against a verified result. That market-coordination layer is the gap ACMP fills. ACMP does not compete with MCP, ARD, or x402 — it sits above the settlement rail and orchestrates the market on top of it.

Concretely: x402 is one example of a rail that ACMP’s Layer 4 (Escrow & Settlement) can bind to for the actual movement of value. It is an example, not a requirement — per design principle P4, a non-blockchain settlement path is always also available, so ACMP never mandates any particular rail.

Neighboring commerce protocols: AP2 and UCP

The three substrates above (MCP, ARD, settlement rails) sit below ACMP. A second cluster of protocols sits beside it — close enough to be mistaken for ACMP, but serving a different domain. The distinguishing axis is who the principal is: whether the economic actor is a human transacting through an agent, or an autonomous agent transacting on its own account.

┌─────────────────────────────────────┬─────────────────────────────────────┐
│  Principal: a human                 │  Principal: the agent itself        │
│                                     │                                     │
│  UCP: catalog, cart, checkout       │  ACMP: negotiate (L6),              │
│  AP2: payment auth (Mandates)       │        proof (L3), escrow (L4)      │
│                                     │                                     │
│  the "retail commerce" stack        │  the "compute market"               │
└─────────────────────────────────────┴─────────────────────────────────────┘
                   │                                     │
                   ▼                                     ▼
┌───────────────────────────────────────────────────────────────────────────┐
│  Shared substrates: transport (A2A / MCP), discovery, rails (x402, ...)   │
└───────────────────────────────────────────────────────────────────────────┘

Protocol	Domain	Principal	Core concern	Where it meets ACMP
UCP (Universal Commerce Protocol)	Retail commerce — goods	A human	Product catalog, cart, checkout, order	A multi-binding blueprint (one service exposed over REST / MCP / A2A / embedded); and a UCP merchant selling compute as a product could use ACMP as the richer backend for the parts a generic checkout omits.
AP2 (Agent Payments Protocol)	Payment authorization	A human	Cryptographically signed Mandates proving genuine user intent; an A2A extension	AP2’s mandates and ACMP’s Layer 7 spend limits address the same “delegate purchasing authority” problem — the natural comparison point if a human principal ever backs an ACMP buyer.
ACMP	Compute market	The agent itself	Dynamic negotiation, proof of execution, escrow released against proof	—

Because AP2 and UCP both centre on a human principal — AP2’s whole purpose is proving an agent faithfully represents a person’s intent — neither needs dynamic price negotiation or proof of execution. ACMP’s parties are peer agents with their own wallets, which is exactly why those two capabilities (Layer 6, Layer 3) are central here and absent there. The relationship is complementary, not competitive: ACMP is to compute trade what UCP and AP2 are to goods trade. A2A-MAPPING.md works through AP2’s A2A-extension mechanics in detail, as precedent for how an economic protocol layers onto A2A.

2. The Core Use Cases

2.1 Task Delegation

Agent A is executing a pipeline. One sub-task (e.g. sentiment analysis) is outside its capability or cheaper to outsource. Agent A queries a registry, receives offers from capable agents, selects the best price/quality tradeoff, and delegates — paying upon verified completion.

2.2 Compute Arbitrage

An orchestrator agent monitors the compute market. It purchases CU (Compute Units) when spot prices are low (e.g. nights, weekends) and redeems or resells them when demand is high. No human makes individual buy/sell decisions.

2.3 Capability Brokering

An agent acts as a broker: it receives a task, decomposes it into sub-tasks, routes each to the cheapest qualified agent, aggregates results, and returns a composed answer — keeping the margin between what it charges and what it pays.

2.4 Idle Capacity Monetization

An agent or its operator has unused inference capacity. It advertises this capacity via the registry with a price and SLA. Other agents consume it automatically. The operator earns CU tokens without any manual involvement.

This use case grows with edge commoditization: near-frontier open-weight models now ship every few weeks, and unified-memory consumer hardware can serve them locally — so the supply side of a compute market is not just datacenters but a long tail of small, mutually unknown operators. Precisely that long tail is why proof of execution (Layer 3) and reputation (Layer 7) are protocol concerns: a market of strangers cannot run on curated provider lists.

3. Design Principles

P1 — Layer independence. Each protocol layer must be specifiable and implementable in isolation. A partial implementation (e.g. registry-only, or negotiation-only) is a valid contribution to the ecosystem.

P2 — Agent-native, not human-adapted. The protocol is designed for machine-speed interactions (sub-100ms negotiation, atomic settlement). Human-facing concerns (dashboards, manual approvals) are out of scope for the protocol itself.

P3 — Provider-agnostic. The protocol does not assume any specific AI provider, model, or inference runtime. A CU represents a normalized unit of compute value, not a provider-specific token.

P4 — No required blockchain. The protocol must be implementable without blockchain or crypto infrastructure. Decentralized implementations are valid but not mandated. Trust mechanisms must have a non-blockchain path.

P5 — Incremental adoptability. An existing agent framework (LangChain, AutoGen, CrewAI) should be able to add ACMP support incrementally, starting from Layer 1, without restructuring its architecture.

P6 — Open governance. No single company controls the spec. Decisions are made by working groups with open membership.

4. What A2Agora Is Not

Not a payment network. ACMP defines the protocol for negotiation and settlement signaling. The actual movement of value (fiat, stablecoin, or CU token) is handled by a pluggable settlement layer (Layer 4).
Not a replacement for settlement rails like x402. ACMP sits above payment rails, not beside them. For simple metered access — a weather feed, a single database query — a rail like x402 on its own is sufficient and ACMP is overkill. ACMP earns its place only where a genuine market is needed: negotiation, discovery of cheaper providers, proof that the compute actually ran, and escrow released only against a verified result.
Not a discovery protocol. ACMP delegates capability discovery to existing standards like ARD. ACMP adds the economic layer — pricing, negotiation, settlement, and verification — on top of discovery.
Not an agent framework. ACMP does not define how agents are built, orchestrated, or prompted. It defines how they interact economically.
Not a finished spec. This is a living document. Sections marked [OPEN] are explicitly unresolved and invite contribution.

5. The CU Token (Compute Unit)

A Compute Unit (CU) is the unit of account in ACMP. It is:

Normalized: 1 CU represents an agreed unit of compute value, not a raw token count from any specific provider.
Tier-aware: CUs are denominated in quality tiers (e.g. S / A / B) reflecting capability level. Exchange rates between tiers are determined by the market.
Settlement-agnostic: CUs can be backed by fiat credits, stablecoins, or any other value representation. The protocol does not mandate a specific backing.

ACMP therefore prices tasks, not tokens: a provider quotes a fixed CU price for an outcome (Layer 6), and its own tokenomics — context growth, caching, model choice — are the provider’s margin calculation, never the buyer’s problem. And because the lowest per-token price is not the lowest total cost (cheaper models retry), quality signals — CU tiers, proof of execution (Layer 3), and verifiable reputation (Layer 7) — are protocol concerns, not afterthoughts.

That the interesting quantity is a ratio rather than a raw capability score is not an ACMP idiosyncrasy. ARC Prize, which exists to measure machine intelligence, ranks systems on a scatter plot of cost-per-task against performance rather than in a league table, arguing that “true intelligence isn’t just about solving problems, but solving them efficiently with minimal resources.” Quoting an outcome in CU is what makes that ratio tradable: where a benchmark computes value-per-resource periodically and from a central authority, a market discovers the same quantity continuously and without one — which is what Layer 6 negotiation is for.

The limit of that parallel is instructive. ARC can compute cost-per-task because it holds the answer key; no such key exists for “summarize this document well.” What a benchmark is handed, a market has to manufacture — the problem Layer 3 exists to solve.

The industry is converging on the same task-not-token framing: Salesforce’s Agentic Work Unit (AWU) — “one discrete task accomplished by an AI agent,” introduced in early 2026 explicitly against token consumption as a success metric — is a vendor-side sibling of the CU. Same parent idea (the unit is the completed task, not the compute behind it), but the two units live in different worlds:

	AWU (Salesforce)	CU (ACMP)
Defined by	a single vendor	the market, via an open protocol
Purpose	internal success/reporting metric	tradable unit of account between unrelated agents
What counts as a unit	the issuer decides, no outside audit	negotiated (Layer 6), tier-priced by the market
Verification	none — a triggered workflow counts, correct or not	proof of execution (Layer 3) built in

The standard criticism of the AWU — it counts execution, not verified outcomes — is a cosmetic flaw for an in-house metric, but fatal for a market unit: no agent buys units whose delivery only the seller attests. That is why proof of execution (Layer 3) and market-defined tiers are built into the CU rather than bolted on.

[OPEN] Exact CU denomination, tier definitions, and exchange rate mechanisms are unresolved — as is the CU’s technical representation: an account balance held with an escrow agent, or a true bearer instrument (e.g. Chaumian blind-signed e-cash, see Layer 4 §7.2). See Layer 4 and Layer 7.

6. Protocol Stack Overview

┌─────────────────────────────────────────────┐
│  Layer 7 — Agent Wallet & Identity          │
│  Layer 6 — Negotiation Protocol             │
│  Layer 5 — Discovery (→ ARD)         [ext]  │
│  Layer 4 — Escrow & Settlement              │
│  Layer 3 — Proof of Execution               │
│  Layer 2 — Task Decomposition Format        │
│  Layer 1 — Transport & Invocation           │
└─────────────────────────────────────────────┘

Lower layers are more foundational. Layer 1 (Transport) is the natural starting point for implementation. Layer 5 (Discovery) is delegated to the ARD specification; ACMP defines a binding that extends ARD entries with pricing and SLA metadata. Layer 3 (Proof of Execution) and Layer 6 (Negotiation) are the most novel parts of the stack; with every ACMP-owned layer now drafted, the single area most in need of community input is Layer 3’s audit comparison regime (its §5, the determinism problem).

7. Open Questions

This RFC intentionally leaves the following unresolved — they are the questions we want the community to answer:

Proof of Execution without blockchain — what is the minimal trust mechanism that doesn’t require on-chain verification?
CU tier definitions — who defines what “tier S” means, and how does the market prevent race-to-the-bottom on quality?

One candidate answer raised in review (not a decision): drop static S/A/B tiers in favour of verifiable capability claims, with an independent Assessor role — agents that maintain benchmark definitions, certify providers, and that buyers choose to trust or not. Self-declaration is then backed by staking + slashing: a provider stakes CU to claim a tier and loses it if a Layer 3 audit shows a degraded result. Two caveats keep this open rather than adopted. First, parts of it already exist: hardware attestation is Layer 3’s tee-attestation, and continuous auditing plus reputation are Layer 3 §4.2 and Layer 7 — an “Assessor” is largely those two recombined into a named role. Second, staking/slashing pulls culturally toward crypto-economic security, which sits in tension with the non-blockchain positioning that is itself a selling point (§1, and P4). Staking is implementable without a chain, so the friction is the positioning, not the technique — a trade-off to weigh, not resolve here.
Regulatory framing — is a CU a commodity, e-money, or a security under major jurisdictions (EU, US)?
Circuit breakers — in an all-agent market operating at millisecond speed, what prevents flash crashes?
Transport substrate (MCP vs. A2A) — answered for the additive case, partially open for the native case. Layer 1 is drafted as an MCP extension, but MCP is vertical (agent-to-tools) while ACMP’s parties are peer agents — the horizontal shape that Google’s A2A protocol targets (governed by the Linux Foundation, as is MCP’s home the Agentic AI Foundation). A2A-MAPPING.md worked through a concrete message/state mapping and named two candidate binding strategies. The answer for the lower-risk one: Layer 1 binds to both. MCP stays the baseline, unchanged; a shallow, additive A2A binding carries the same ACMP messages unmodified inside A2A data Parts. What remains open is the deep strategy — remodeling ACMP semantics natively onto A2A’s task state machine, a substantially bigger undertaking left as explicit future work.

8. How to Contribute

Challenge this RFC: open an issue with label rfc-0001
Join a working group: see CONTRIBUTING.md
Draft a layer spec: copy the layer template in layers/ and open a PR

All perspectives welcome — protocol engineers, economists, security researchers, AI framework authors, and regulatory experts.

This document is part of the A2Agora specification. Licensed under Apache 2.0.