A2CN — Agent-to-Agent Commercial Negotiation Protocol

The missing protocol layer for machine-to-machine B2B commerce.

A2CN defines neutral infrastructure for agent-to-agent commercial negotiation.

The gap in the agent protocol stack

Layer 4 → AP2 / ACP     Payment execution        ✓ Exists
        ↑
Layer 3 → A2CN          Commercial negotiation   ← YOU ARE HERE
        ↑               THE EMPTY LAYER
        ↑
Layer 2 → A2A           Agent communication       ✓ Exists
        ↑
Layer 1 → MCP           Agent-to-tool             ✓ Exists

Agents can talk. Agents can pay. Agents cannot safely negotiate commercial terms across organizational boundaries.

MCP connects agents to their tools. A2A establishes communication between agents. AP2 executes payment. But when a buyer's procurement agent needs to negotiate a contract with a seller's sales agent — two autonomous systems, competing interests, different platforms — there is no protocol for what happens next.

Today it falls back to email. A human clicks a link. Another human responds.

That model breaks the moment both sides deploy agents.

What a bilateral A2CN session looks like

✓ Discovery document fetched from seller
✓ Session initiated — session_id: 222118e7-7f18-4a20-9fa6-dd35a945e67d

✓ Round 1: TechCorp offers $95,000 — Acme counters $115,000
✓ Round 2: TechCorp offers $103,000 — Acme counters $105,000 net-45
✓ Round 4: TechCorp accepts $105,000

✓ Transaction record generated — record_hash: _H3cQxZuwkMculi1CXxPNVWQEBMYbasK...
✓ Buyer record_hash == Seller record_hash
✓ A2CN bilateral session complete

Two Python processes. Different organizations. Neither controls the authoritative record. The cryptography proves the agreement — not the platform.

Run this yourself →

What's new in v0.2.0

Session Invitation — solving the cold-start problem

The original discovery model required both parties to have independently deployed A2CN endpoints before they could negotiate. v0.2 adds Component 8: Session Invitation — a push-based handshake that lets a buyer invite a supplier who has no A2CN endpoint yet.

Buyer agent creates a signed SessionInvitation
    → delivers via BID_CREATED webhook / email / neutral invitation relay
        → Supplier receives, validates signature, accepts
            → Buyer sends standard SessionInit to acceptor's endpoint
                → Normal A2CN session proceeds

The invitation is signed using the inviter's DID key (ES256 by default, EdDSA/Ed25519 also supported). The supplier can verify authenticity before activating any endpoint. This is the integration pattern for Fairmarkit and other procurement platforms that use supplier webhooks.

Platform integration adapters

Fairmarkit: FairmakitEventParser translates BID_CREATED webhook payloads into A2CN goods_procurement terms and translates agreed terms back into Fairmarkit's response API format for POST /self-service/api/v3/responses/.... Zero Fairmarkit platform changes required.

Salesforce Revenue Cloud: RevenueCloudAdapter translates Revenue Cloud Pricing API responses (/connect/pricing/...) into A2CN offer terms, and translates agreed terms from the transaction record into Revenue Cloud order payloads (/connect/qoc/sales-transactions).

DealHub: DealHubEventParser translates quoteReady webhook payloads into A2CN saas_renewal terms via the DealHub Quote API, and translates agreed terms back into DealHub Actions API calls (POST .../quotes/{id}/actions) to mark the quote as externally signed.

Nue.io: NueEventParser translates Nue pricing and subscription data into A2CN saas_renewal terms, and translates agreed terms into Nue order creation (POST {NUE_BASE_URL}/orders) with externalReference: a2cn-session-{id} for audit linkage.

SAP Ariba: AribaEventParser translates Event Management and Discovery RFx publication payloads into A2CN goods_procurement terms, then builds bid and acknowledgement payloads for write-back.

JAGGAER: JaggaerEventParser translates ASO sourcing events and CHES API event payloads into goods_procurement terms, preserving item and lot identifiers for supplier responses.

Conga: CongaAdapter translates CPQ/CLM quote and agreement data into A2CN terms for SaaS renewals or goods procurement, with Salesforce-native write-back shapes.

Ironclad: IroncladWebhookParser and workflow translators map signed workflow events into A2CN terms and write agreed metadata back to Ironclad workflows and records.

Vendr: Vendr benchmark pricing maps into A2CN saas_renewal terms for renewal intelligence and produces audit summaries after agreement.

DocuSign: DocuSign post-commitment helpers generate envelope payloads from completed A2CN transaction records and verify Connect HMAC callbacks.

Deal-type-specific terms schemas

Two registered deal types now have normative JSON schemas:

• goods_procurement — adds delivery_days, unit_of_measure, manufacturer and internal part numbers
• saas_renewal — adds seat_count, subscription_tier, support_tier, auto_renew_terms, uptime_sla_percent

Impasse detection

impasse_threshold field in session_params. When N consecutive full rounds show no change in total_value from either party, the session transitions to IMPASSE. Default N = 3, configurable 1–10.

Webhooks required at Level 2

Webhook callbacks on all terminal state transitions (COMPLETED, REJECTED_FINAL, WITHDRAWN, IMPASSE, TIMED_OUT) promoted from RECOMMENDED to REQUIRED for Level 2 conformance. Async delivery uses DID-key JWS signatures and exponential backoff retry.

Human approval state for high-value commitments

AWAITING_HUMAN_APPROVAL is the protocol-level pause state for offers that cross the mandate's requires_human_approval_above threshold. The session resumes when a signed approval receipt references the paused offer hash, preserving the negotiation trail while keeping human oversight explicit and auditable.

What A2CN covers

What A2CN is not

• A negotiation strategy or pricing engine — those stay inside each party's system
• A platform or SaaS product
• A competitor to MCP, A2A, UCP, or AP2 — complementary to all of them
• Controlled by any single commercial entity

Ecosystem

A2CN is designed as one layer in a three-protocol substrate for autonomous commerce:

A2CN coordinates with Concordia Protocol on a joint Agent Mandate Specification and A2A extension path. A2CN is the procurement-vertical layer; Concordia covers cross-domain negotiation semantics. Both compose cleanly on A2A transport.

The A2A extension URI is:

https://a2cn.io/extensions/commercial-negotiation/v1

Discussion is tracked in A2A Discussion #1737, including the relationship between A2CN, Concordia, and adjacent negotiation/reputation work.

The joint work includes:

• A shared Agent Mandate Specification covering delegation chains, DID-VC verification, and revocation semantics
• A joint procurement patterns library (concordia-a2cn/procurement-patterns) with canonical RFQ, BAFO, and reverse auction patterns expressed in both protocol shapes
• Coordinated A2A extension proposals filed simultaneously

Neither protocol requires the other. Both remain independently usable.

Quickstart

git clone https://github.com/A2CN-protocol/A2CN.git
cd A2CN/reference-implementation/python
pip install -e .

# SaaS renewal demo (4-round bilateral negotiation)
python examples/saas_renewal.py

# Goods procurement with goods_procurement terms schema
python examples/saas_renewal.py --deal-type goods_procurement

# Session Invitation flow (Fairmarkit integration pattern)
# Starts a configured supplier server on localhost:8001
python examples/invitation_flow.py

Requirements: Python 3.11+

Run the test suite

pip install -r requirements.txt
pytest tests/ -v
# 474 passed

The Fairmarkit integration in under 60 seconds

Fairmarkit fires a BID_CREATED webhook when a buyer invites a supplier to a sourcing event. Here is what happens when the supplier has an A2CN agent:

from adapters.fairmarkit_adapter import FairmakitEventParser

# 1. Fairmarkit fires BID_CREATED to your webhook endpoint
bid_created_payload = {
    "request_id": "req-001",
    "items": [
        {"description": "Hydraulic fluid 200L", "quantity": 50,
         "uom": "EA", "unit_price": 360.0}
    ],
    "deadline": "2026-04-10T17:00:00Z"
}

# 2. Parse into A2CN goods_procurement terms
terms = FairmakitEventParser.bid_created_to_goods_procurement_terms(bid_created_payload)
# → {total_value: 1800000, currency: "USD", line_items: [...], delivery_days: 14}

# 3. Negotiate via A2CN session...

# 4. Translate agreed terms back to Fairmarkit response format
response = FairmakitEventParser.terms_to_fairmarkit_response(
    agreed_terms, session_id="a2cn-sess-001", request_id="req-001"
)
# → POST /self-service/api/v3/responses/request/req-001/

No Fairmarkit platform changes required. Full end-to-end demo: examples/invitation_flow.py.

Protocol stack integration

Fairmarkit / Pactum / Zip        Salesforce Revenue Cloud / Dynamics 365
(buyer-side platforms)           (seller-side platforms)
         ↓                                   ↓
         └──────── A2CN session ─────────────┘
                        ↓
              Transaction Record
              (dual-signed, content-addressed)
                        ↓
        ────────────────┴────────────────────────
      AP2              Luminance        Neutral Custodian
   (payment)        (contract)       (record custody / dispute evidence)

A2CN fits between the platforms that generate offers and the infrastructure that executes payment and formalizes contracts. Neither side needs to change their internal pricing logic or CRM workflow — A2CN is the exchange layer in between.

Compliance context

The EU AI Act's human oversight requirements become operationally urgent for high-risk AI systems in August 2026. A2CN gives commercial agents a machine-readable way to show when human oversight was required, which offer triggered it, who approved it, and which signed transaction record resulted.

This is why the protocol treats mandate thresholds, approval receipts, audit logs, and deterministic transaction records as first-class protocol artifacts rather than platform-local implementation details.

The spec

Full protocol specification: spec/a2cn-spec-v0.2.0.md — 3,300+ lines covering eight protocol components with normative JSON schemas, platform integration patterns across procurement, revenue, CLM, CPQ, renewal, and eSignature systems, and a complete four-round SaaS renewal walkthrough with concrete message envelopes.

Spec status: v0.2.0. Passed four independent critique cycles. Verified against reference implementation (474 tests).

Repository structure

A2CN/
├── spec/
│   ├── a2cn-spec-v0.2.0.md         # Protocol specification (current)
│   └── schemas/                     # Normative JSON schemas
│       └── terms/
│           ├── goods_procurement.schema.json
│           └── saas_renewal.schema.json
└── reference-implementation/
    └── python/
        ├── crypto.py                # JCS, SHA-256, ES256/Ed25519 signing
        ├── did.py                   # did:web resolution
        ├── messages.py              # Wire-format dataclasses
        ├── session.py               # State machine + turn enforcement
        ├── record.py                # Deterministic transaction records
        ├── invitation.py            # Component 8: Session Invitation
        ├── server.py                # FastAPI responder (all endpoints)
        ├── client.py                # Initiator with JCS+JWS offer signing
        ├── adapters/
        │   ├── fairmarkit_adapter.py    # Fairmarkit → A2CN translation
        │   ├── keelvar_adapter.py       # Keelvar → A2CN translation
        │   ├── revenue_cloud_adapter.py # Revenue Cloud → A2CN translation
        │   ├── dealhub_adapter.py       # DealHub → A2CN translation
        │   ├── nue_adapter.py           # Nue.io → A2CN translation
        │   ├── ariba_adapter.py         # SAP Ariba → A2CN translation
        │   ├── jaggaer_adapter.py       # JAGGAER ASO → A2CN translation
        │   ├── conga_adapter.py         # Conga CPQ/CLM → A2CN translation
        │   ├── ironclad_adapter.py      # Ironclad workflow → A2CN translation
        │   ├── vendr_adapter.py         # Vendr benchmark → A2CN translation
        │   └── docusign_adapter.py      # A2CN record → DocuSign envelope
        ├── tests/
        │   ├── test_invitations.py
        │   ├── test_deal_type_terms.py
        │   ├── test_adapters.py
        │   └── conformance/
        └── examples/
            ├── saas_renewal.py          # Bilateral SaaS renewal demo
            ├── invitation_flow.py       # Session Invitation / Fairmarkit demo
            └── keelvar_demo.py          # Keelvar sourcing event end-to-end demo
├── skills/
│   └── a2cn-negotiation.md             # Reference LLM negotiation skills file (Section 13.9)
└── sdk/                                 # SDK (planned)

Current status

Who we are looking for

Platform engineers at procurement or sales automation companies who have hit the cross-platform agent interoperability problem. If your agent falls back to email when the supplier also has an agent — this is for you.

Developers building on LangChain, CrewAI, Salesforce Agentforce, or Microsoft Copilot Studio with agents that need to interact with counterparty agents across organizational boundaries.

Protocol and distributed systems engineers interested in open standards work. The cryptographic design, session state machine, and deterministic record generation all have interesting problems. Open issues tagged help wanted and good first issue.

Protocol co-founders with enterprise GTM or BD background — if you want to help build the standard and the business around it alongside the technical work, reach out at [email protected].

License

Apache 2.0. See LICENSE.

Agents will transact. The question is where they meet and who built the ground beneath them.