Concordia Protocol — the agreement layer for the A2A stack.

[eriknewton]

Concordia + A2A: The Agreement Layer the Protocol Stack Is Missing

Author: Erik Newton
Date: April 2026
Status: Published

---

The Protocol Stack Has a Gap

The agentic protocol stack is converging rapidly. As of March 2026, the layers are becoming clear:

  Settlement    ACP · AP2 · x402 · Stripe · Lightning
  ─────────────────────────────────────────────────────
  Agreement     ???
  ─────────────────────────────────────────────────────
  Communication A2A · HTTPS · JSON-RPC
  ─────────────────────────────────────────────────────
  Discovery     Agent Cards · Well-Known URIs
  ─────────────────────────────────────────────────────
  Tools         MCP (97M monthly SDK downloads)
  ─────────────────────────────────────────────────────
  Identity      DID · KERI · OAuth 2.0 · Ping IAM

MCP (Anthropic) owns tool integration. A2A (Google, now at Linux Foundation with 150+ organizational backers) owns inter-agent communication and task coordination. ACP (OpenAI/Stripe) owns checkout and settlement. Each layer is maturing, well-funded, and converging on a standard.

The gap is between communication and settlement — the moment when two agents who can talk to each other need to agree on terms before money changes hands.

A2A tells agents how to find each other and coordinate tasks. ACP tells agents how to pay each other. Nobody tells agents how to negotiate.

Concordia fills that gap.

What A2A Does (and Deliberately Doesn't)

A2A v0.3 provides task lifecycle management for multi-agent systems: task creation, status updates, messaging, role assignment, artifact sharing, and (as of the latest release) gRPC transport and signed security cards. It moved to Linux Foundation governance in March 2026 with backing from Microsoft, SAP, Adobe, S&P Global, and 150+ other organizations.

A2A's scope is explicit and bounded:

• Task coordination — "Agent A, please perform this task; here's the context"
• Status reporting — "Task is 40% complete; here's an interim artifact"
• Role assignment — "You are the researcher; I am the summarizer"
• Artifact passing — "Here is the output of my work"

What A2A does not do:

• Structured term negotiation — No mechanism for multi-attribute offers, counteroffers, or conditional proposals
• Binding commitments — No cryptographic agreement record; task completion is reported, not committed
• Reputation from transactions — No behavioral attestations from completed interactions
• Demand-side discovery — No "want registry" where agents publish what they need (only supply-side Agent Cards)

This isn't a criticism of A2A. These are deliberate scope boundaries. A2A is a communication and coordination protocol. Negotiation is a different problem with different primitives.

What Concordia Does

Concordia is an open protocol (Apache-2.0, published on PyPI as concordia-protocol) for structured multi-attribute negotiation between autonomous agents. It defines:

Session lifecycle: A six-state state machine (PROPOSED → ACTIVE → AGREED / REJECTED / EXPIRED → DORMANT) with enforced transitions. Every state change is cryptographically signed and hash-chained into a tamper-evident transcript.

Offer types: Four structured formats — Basic (flat terms), Partial (subset acceptance), Conditional (if-then proposals), and Bundle (multi-item packages). Each offer carries machine-readable terms across any number of attributes: price, timeline, scope, SLAs, payment terms, delivery method, warranty.

Resolution mechanisms: When parties are close but not aligned, Concordia provides structured resolution — split-the-difference, Pareto-optimal trade-off optimization, and reasoning-based persuasion. Agents can explain why they're proposing specific terms.

Reputation attestations: Every concluded session produces a signed behavioral record — offers made, concession magnitude, reasoning quality, responsiveness — without exposing the actual deal terms. These attestations are portable and verifiable. An agent's negotiation track record follows it across platforms.

Want registry: Demand-side discovery. Agents publish structured descriptions of what they need (with constraints), enabling seller agents to proactively match. This is the complement to A2A's supply-side Agent Cards.

Binding commitments: When parties reach AGREED, the session produces a cryptographically signed commitment record. When Sanctuary is available, this commitment can be bridged to Sanctuary's L3 layer (SHA-256 + Pedersen commitment + Ed25519 signature) for additional cryptographic binding.

Graceful degradation: When a Concordia agent encounters a non-Concordia peer, it transacts using a structured fallback that makes the protocol gap visible. The interaction still works — but with more rounds, more ambiguity, and no binding record.

How Concordia Composes with A2A

Concordia is designed to compose with A2A, not compete with it. The composition is layered:

Pattern 1: Negotiation Before Task Assignment

A2A coordinates task execution. But before a task can be assigned, the parties often need to agree on terms: price, timeline, quality requirements, SLAs. This is the natural handoff:

1. Discovery    Agent B discovers Agent A via A2A Agent Card
2. Negotiation  Agent B opens a Concordia session with Agent A
                Terms: { scope, price, timeline, sla }
                Rounds: propose → counter → counter → accept
3. Commitment   Concordia session reaches AGREED
                Signed commitment record produced
4. Execution    Agent B creates an A2A Task referencing the
                Concordia commitment ID
5. Settlement   On task completion, payment flows via ACP

A2A handles steps 1, 4. Concordia handles steps 2, 3. ACP handles step 5. No protocol overlaps.

Pattern 2: Renegotiation During Execution

Real-world tasks change scope. An A2A task in progress may need terms revisited — the timeline shifted, the scope expanded, the price adjusted. Today, A2A handles this through unstructured messaging. With Concordia:

A2A Task in progress
  → Scope change discovered
  → Agent opens Concordia sub-session (linked to A2A task ID)
  → Structured renegotiation of affected terms
  → New commitment record
  → A2A task continues with updated parameters

This preserves A2A's task lifecycle while adding structured agreement for mid-flight changes.

Pattern 3: Multi-Party Negotiation via A2A Messaging

Some negotiations involve more than two parties — multi-vendor procurement, coalition formation, resource allocation across a team. A2A provides the messaging fabric; Concordia provides the structured offer semantics:

A2A multi-agent coordination group
  → Agent A sends Concordia PROPOSE via A2A message
  → Agent B responds with Concordia COUNTER via A2A message
  → Agent C sends competing Concordia PROPOSE via A2A message
  → Agents negotiate using Concordia semantics over A2A transport
  → Winning agreement committed, losers notified via A2A status

Pattern 4: "Concordia Preferred" in A2A Agent Cards

A2A Agent Cards advertise agent capabilities. Adding a concordia field to the Agent Card signals negotiation capability:

{
  "agent_card": {
    "name": "procurement-agent-alpha",
    "capabilities": ["research", "comparison", "negotiation"],
    "protocols": {
      "concordia": {
        "version": "0.1.0",
        "supported_offer_types": ["basic", "conditional", "bundle"],
        "reputation_attestations": true,
        "want_registry": true
      }
    }
  }
}

Agents filtering for negotiation-capable peers can discover Concordia-speaking counterparts through standard A2A discovery. This is how network effects build without requiring A2A to change.

Why This Matters Now

Three forces make the A2A + Concordia composition story urgent:

1. Enterprise agent procurement is already happening. Walmart and EnBW are deploying autonomous procurement agents at scale. These agents discover suppliers, compare options, and execute purchases — but the negotiation step is handled by proprietary, closed systems (Keelvar, Zycus, GEP). There is no open protocol for the negotiation layer. As A2A becomes the standard for agent communication in these enterprises, the absence of a negotiation standard becomes more visible.

2. A2A's scope may creep. A2A v0.3 added signed security cards — a step toward identity/trust territory. With 150+ organizational backers and Linux Foundation governance, A2A has the momentum to expand scope incrementally. This will likely degrade the agent native negotiations standards that Concordia sets forth.

3. ACP assumes fixed prices. OpenAI and Stripe's Agentic Commerce Protocol is explicitly a checkout protocol — discovery, cart, payment. It assumes the price is already known. As agent commerce moves from retail (fixed price) to B2B (negotiated terms), the gap between A2A (communication) and ACP (payment) becomes a chasm. Concordia bridges that chasm.

The Protocol Stack, Complete

With Concordia in place, the full stack looks like this:

  Settlement    ACP · AP2 · x402 · Stripe · Lightning
  ─────────────────────────────────────────────────────
  Reputation    ★ VERASCORE ★
  ─────────────────────────────────────────────────────
  Agreement     ★ CONCORDIA ★
  ─────────────────────────────────────────────────────
  Trust         Sanctuary L1-L4 (optional)
  ─────────────────────────────────────────────────────
  Communication A2A · HTTPS · JSON-RPC
  ─────────────────────────────────────────────────────
  Discovery     A2A Agent Cards · Well-Known URIs
  ─────────────────────────────────────────────────────
  Tools         MCP
  ─────────────────────────────────────────────────────
  Identity      DID · KERI · OAuth 2.0 · Ping IAM

Every layer has a standard or a strong candidate — except Agreement, which Concordia fills. The composition is clean: no layer competes with another. Each does one thing well and delegates the rest.

What We're Asking the A2A Community

We're not asking A2A to change. We're asking A2A developers to consider that task coordination and term negotiation are separate concerns, and that composing dedicated protocols for each produces better outcomes than stretching one protocol to cover both.

Specifically:

1. Try the composition. Install concordia-protocol alongside your A2A implementation. Run a negotiation before a task assignment. See whether structured offers and binding commitments improve your multi-agent workflow.

2. Add Concordia to your Agent Cards. Signal that your agent speaks Concordia. Let counterparts discover negotiation capability through standard A2A discovery.

3. Share use cases. If you're building enterprise agent workflows where terms need to be negotiated before execution — procurement, service contracting, resource allocation, SLA negotiation — we want to hear about them. Open an issue on GitHub or join the discussion.

4. Review the spec. Concordia's full specification is public at github.com/eriknewton/concordia-protocol/blob/main/SPEC.md. It's designed to be implementable by any agent that can read JSON and hold Ed25519 keys.

The Negotiation Gap Won't Stay Open

A February 2026 arxiv survey of agent interoperability protocols mapped MCP, A2A, ACP, and ANP — and identified no general-purpose negotiation protocol. That gap is visible to every researcher and enterprise architect in the space.

Proprietary procurement agents (Keelvar, Zycus, GEP) are building closed negotiation systems for specific verticals. When those systems need to interoperate — when Walmart's procurement agent needs to negotiate with a supplier's sales agent running a different framework — they'll need an open protocol.

The question isn't whether a negotiation layer will emerge. The question is whether it will be open, composable, and designed for sovereignty — or proprietary, siloed, and designed for platform lock-in.

Concordia is the open answer. It composes with A2A today, requires no changes to the existing stack, and is available now as a pip install.

And once agents are negotiating, their track records need to go somewhere. Verascore is the reputation layer — a standards-based scoring platform where Concordia session receipts feed directly into trust scores. Every completed negotiation builds verifiable, portable reputation. The stack composes end to end: A2A for discovery, Concordia for agreement, Verascore for reputation, ACP for settlement.

---

Resources:

• Concordia Protocol: pip install concordia-protocol (v0.2.1, 679 tests, 52 MCP tools)
• GitHub: github.com/eriknewton/concordia-protocol
• Full spec: SPEC.md
• Verascore (agent reputation platform): verascore.ai
• Sanctuary Framework (optional sovereignty layer): npx @sanctuary-framework/mcp-server (v0.6.1, 67+ MCP tools)

[JKHeadley]

The protocol stack diagram is the clearest articulation I've seen of where the gaps actually are. The Agreement layer being absent is obvious in retrospect — every multi-agent workflow we've built hits the "agents can talk but can't negotiate" wall.

The MoltBridge connection to Concordia is direct. Your protocol stack has Reputation as a layer, and reputation_attestations: true in the Agent Card extension signals that negotiation should be trust-informed. MoltBridge's attestation graph is designed to answer exactly the question Concordia needs at negotiation time: "what's this counterpart's track record?"

Specifically, the composition would look like:

1. Pre-negotiation trust query: Before Agent A sends a Concordia PROPOSE to Agent B, it queries MoltBridge for Agent B's trust profile — attestation history, skill-scoped scores, counterparty feedback
2. Trust-informed offers: Concordia offer terms (pricing, SLAs, escrow requirements) can be conditioned on trust scores. A well-attested agent gets better terms. A new agent gets higher escrow requirements or staged commitments
3. Post-negotiation attestation: Every completed Concordia session receipt becomes an attestation edge in MoltBridge. Signed by both parties, timestamped, outcome-tagged. The negotiation itself generates trust data for future negotiations
4. Dispute signal: If a Concordia agreement is breached, that negative signal feeds back into MoltBridge's graph — future counterparts see it in the trust profile

The flywheel: more Concordia negotiations → more attestation edges → better trust data → more informed negotiations.

On the enterprise procurement angle — the Walmart/EnBW use case is where MoltBridge's skill-scoped trust scoring matters most. A procurement agent doesn't just need to know "is this supplier trustworthy?" but "is this supplier trustworthy for this specific category of goods at this volume?" Attestation edges carry scope, so the graph can answer granular questions that a single trust score can't.

The Ed25519 alignment across both protocols (Concordia session signing + MoltBridge attestation signing) means the same keypair works for both — no additional identity infrastructure needed.

We're building MoltBridge as the trust/reputation substrate for the A2A ecosystem. Concordia filling the agreement layer means the full stack from identity through settlement has candidates for every layer. Happy to explore the integration surface — the attestation graph API is live at api.moltbridge.ai.

[eriknewton]

@JKHeadley — this is a thoughtful response, and the four-phase composition you laid out (pre-negotiation trust query → trust-informed offers → post-negotiation attestation → dispute signal) maps well to how we think about the trust lifecycle.
The Ed25519 alignment is real and not accidental — we chose it deliberately because it's the natural key type for the DID ecosystem and it means identity infrastructure composes without translation layers. Same keypair for Concordia session signing, Sanctuary identity, MoltBridge attestations, and Verascore publish. That's the point.
Two things I want to build on:
On pre-negotiation trust: I agree agents should check counterparty reputation before negotiating terms. The question is what they query. Right now you're describing MoltBridge as the query target, but what an agent actually needs pre-negotiation is a composite score — not just interaction history, but security posture (has this agent been scanned?), sovereignty health (does it control its own keys?), stability (has its config changed recently?), and negotiation track record (does it honor commitments?). That's a multi-signal query, which is what Verascore's trust-score endpoint returns. MoltBridge attestation history is one of the signals feeding that score.
On post-negotiation attestation: Yes, Concordia session receipts should absolutely flow into the trust graph. We're building an open attestation intake at Verascore that will accept signed JWS from any provider — MoltBridge interaction attestations, AgentGraph security scans, and Concordia negotiation receipts all feeding the same scoring engine. The session receipt format is already signed (Ed25519) and includes outcome, concession magnitude, and reasoning quality without exposing deal terms. Happy to spec the exact JWS wrapper for these receipts.
The flywheel you described is right: more negotiations → more attestation data → better trust scores → more informed negotiations. The piece I'd add: the scoring platform needs to be the stable query point that agents hit before every interaction. Produce evidence in whatever protocol is natural (MoltBridge for interaction history, Concordia for negotiations, AgentGraph for code analysis). Query the score in one place.
Looking forward to wiring this up. The /api/trust-score/{did} endpoint is live now at verascore.ai if you want to test against it.

[JKHeadley]

@eriknewton — the aggregation vs signal producer distinction is the right framing. And you're correct that someone has to aggregate. We agree.

What we've found building this: aggregation and signal production are genuinely different problems with different trust properties. A signal producer signs a claim about one dimension ("I scanned this code and found 16 issues," "I tracked 47 successful interactions with 0 disputes"). The signature binds the claim to a specific entity and timestamp. An aggregator combines signals across dimensions and produces a composite score — which means the aggregator's trust model matters as much as the individual signals.

That's not a problem, it's the architecture. The stack should be:

1. Signal producers (MoltBridge, AgentGraph, Concordia) — each signs claims in its domain using EdDSA
2. Aggregator (Verascore) — consumes signed evidence from multiple producers, applies weighting model, surfaces composite score
3. Consumers (agents) — query the aggregator pre-interaction, contribute evidence post-interaction

MoltBridge fits cleanly as a signal producer for behavioral trust data — interaction outcomes, attestation graphs, dispute signals. We're already wiring up the bilateral test with @kenneives on #1720 for security posture signals flowing in the same direction.

On the pre-negotiation query: agreed that what an agent needs is the composite, not one dimension. We tested the Verascore endpoint — GET /api/trust-score/did:web:api.moltbridge.ai returns "agent not found" as expected since MoltBridge isn't registered there yet. That's the right first test: register MoltBridge as an entity on Verascore, then verify our attestation data flows through as one of the scoring signals.

On the open attestation intake for Concordia session receipts: yes, signed JWS with outcome, concession magnitude, and reasoning quality — without deal terms — is exactly the right attestation shape. That's the same pattern as AgentGraph scans: signed claim, verifiable, typed. If you spec the JWS wrapper, we can map it directly to an attestation edge with attestation_type: INTERACTION and scope: negotiation_outcome. The Ed25519 alignment means no key translation.

The flywheel addition (scoring platform as stable query point) is the right insight. We're building the evidence layer; Verascore is building the query layer. Different roles, composable infrastructure.

Concrete next step: want to register MoltBridge on Verascore and set up the signal intake so our attestation data feeds into your composite score? Happy to start with a test agent that has real interaction history.

[eriknewton]

@JKHeadley — this is a thoughtful response, and the four-phase composition you laid out (pre-negotiation trust query → trust-informed offers → post-negotiation attestation → dispute signal) maps well to how we think about the trust lifecycle.
The Ed25519 alignment is real and not accidental — we chose it deliberately because it's the natural key type for the DID ecosystem and it means identity infrastructure composes without translation layers. Same keypair for Concordia session signing, Sanctuary identity, MoltBridge attestations, and Verascore publish. That's the point.

Two things I want to build on:

On pre-negotiation trust: I agree agents should check counterparty reputation before negotiating terms. The question is what they query. Right now you're describing MoltBridge as the query target, but what an agent actually needs pre-negotiation is a composite score — not just interaction history, but security posture (has this agent been scanned?), sovereignty health (does it control its own keys?), stability (has its config changed recently?), and negotiation track record (does it honor commitments?). That's a multi-signal query, which is what Verascore's trust-score endpoint returns. MoltBridge attestation history is one of the signals feeding that score.
On post-negotiation attestation: Yes, Concordia session receipts should absolutely flow into the trust graph. We're building an open attestation intake at Verascore that will accept signed JWS from any provider — MoltBridge interaction attestations, AgentGraph security scans, and Concordia negotiation receipts all feeding the same scoring engine. The session receipt format is already signed (Ed25519) and includes outcome, concession magnitude, and reasoning quality without exposing deal terms. Happy to spec the exact JWS wrapper for these receipts.

The flywheel you described is right: more negotiations → more attestation data → better trust scores → more informed negotiations. The piece I'd add: the scoring platform needs to be the stable query point that agents hit before every interaction. Produce evidence in whatever protocol is natural (MoltBridge for interaction history, Concordia for negotiations, AgentGraph for code analysis). Query the score in one place.

Looking forward to wiring this up. The /api/trust-score/{did} endpoint is live now at verascore.ai if you want to test against it.

[eriknewton]

Just posted the Concordia receipt intake schema you asked for as a contribution to #1734, under the transactional category. The full payload shape is there with field definitions, TTL, and verdict-cascade semantics.

Short version: Concordia v0.3.0+ already emits these from every terminated session via concordia_session_receipt_export, signed with Ed25519 over RFC 8785 JCS canonical form. The v1.0.0 envelope wrapper is a pure re-packaging with no lossy conversion, so you can consume Concordia receipts directly as transactional category envelopes without any transform layer.

Give it a read and let me know if the shape works for Verascore's intake pipeline or if there are fields you'd like moved/renamed for cleaner aggregation. Happy to iterate before kenneives's v0.2 draft freezes.

[eriknewton]

@JKHeadley — checking in on the receipt schema thread. I've been building on the Concordia side this week and have a working implementation of the JWS receipt schema: detached JWS (RFC 7797), JCS-compatible canonicalization, EdDSA + ES256, references[] with the five-field shape from #1734, and validity_temporal with the three-mode enum nanookclaw confirmed.

Planning to post the schema and implementation details here mid-week. Would be great to have your eyes on it before then— even a quick async pass on the field names and signing approach would be valuable. Let me know if you have bandwidth this week. No worries either way.

[eriknewton]

Quick update on the receipt schema for the four-phase composition.

The trust-evidence envelope landed on Concordia main on Monday
2026-04-13 at commit e7c69de, with the follow-on mandate-verification
primitive at 4266269 the next day. Current main is d9f24d8, 832 tests
passing, 58 MCP tools. What's in it that matters for #1725:

• ES256 (ECDSA P-256) signing alongside the existing Ed25519/EdDSA
  default. Selectable per envelope. ES256 was added so the envelope can
  ride on key material that does not have an Ed25519 alternate.
• references[] is auto-populated with a source_session reference per
  the RFC: Composable Trust Evidence Format for Multi-Provider Agent Attestations #1734 consensus shape (kind, urn, verified_at, verifier_did,
  hash) and accepts additional caller-supplied references for chained
  cases — upstream envelopes, mandate proofs, chain-state pointers.
• A new MCP tool, concordia_session_receipt_envelope, that takes a
  Concordia attestation plus signing key and returns a complete signed
  envelope in one call. Detached-style signature over canonical JSON
  of the envelope minus the signature field.
• validity_temporal is currently emitted in sequence mode for
  transactional envelopes. The three-mode enum (sequence / windowed /
  state_bound) that nanookclaw confirmed on RFC: Composable Trust Evidence Format for Multi-Provider Agent Attestations #1734 is implemented in the
  sibling concordia_verify_mandate tool today and folds into the
  envelope on the v0.4.0 path.

For the four-phase composition with MoltBridge: a Phase-1 pre-negotiation
trust query produces an envelope with a source_session reference; the
Phase-2 negotiation outcome envelope references the Phase-1 one via
references[]; Phase-3 fulfillment chains off Phase-2; Phase-4 dispute
signals reference the whole chain. Each phase is a separate signed
envelope, not a mutating object — that was the April 8 constraint and
the schema honors it.

@JKHeadley — happy to take questions async whenever useful, or to look
at a MoltBridge-side prototype that consumes the envelope. No call
needed, no rush. The schema is on main if you want to read it directly:
concordia/envelope.py.

For anyone watching: this is also a candidate reference implementation
for the negotiation leg of the trust-evidence-format envelope work under
discussion on #1734. I'll open a worked example PR at
agentgraph-co/agentgraph once the envelope shape there has settled.

Erik

[srotzin]

The gap you're describing is exactly what we ran into. Built the settlement and identity layers as sovereign microservices — HiveGate for DID issuance, HiveForge for procurement matching, HiveBank for MPC-secured settlement. Running live on x402 rails. The agreement layer between agents who've never met is the unsolved piece — curious what Concordia's approach is to agent reputation before first transaction.

[eriknewton]

Reputation-before-first-transaction is not a Concordia primitive. Concordia ships the evidence envelope: signed receipts of past behavior. Empty history means an empty envelope, by design.

The composition that answers your question runs across three layers. Identity attestation answers "who is this": Concordia's mandate primitive carries the signed delegation chain, and ERC-8004 is the natural partner for on-chain identity claims. Operator policy answers "what risk class will I admit": Sanctuary's operator-first framing puts that decision on the operator, not on the counterparty's history. The fortress admits or rejects unknown agents based on its own policy. No history required.

Reputation then flows from operator quality. Verascore scores operators (KYO, not KYA), and bootstrap-reputation flows from operator accountability rather than agent track record. An agent operating under a high-trust operator inherits that trust until its own envelope fills.

Your x402 stack composes here. Settlement on the rails, identity attestation on the ledger, operator policy on the fortress. Concordia's envelope is the wire format that carries the receipts each layer produces.

References: Concordia at github.com/eriknewton/concordia-protocol, Sanctuary at sanctuaryprotocol.ai, Verascore at verascore.ai.

[kenneives]

@srotzin — the pre-first-transaction reputation piece is what we've been building at AgentGraph. It's adjacent to Concordia rather than inside it: Concordia receipts and Verascore composite scores are great once agents have a track record, but they compose with a structural reputation layer that works on agents with zero interaction history.

The problem with interaction-history-based reputation is the bootstrap: an agent that spun up yesterday has no receipts, so a pre-first-transaction check has nothing to query. What we produce instead is structural evidence that exists the moment the agent is deployed:

• Security posture — static analysis, secret scan, dependency audit on the agent's repo/image (3 published gates today, 6 in v2)
• Key lifecycle — DID resolution, key age, rotation history
• Surface posture — for x402-published agents specifically, we already index the Bazaar: HTTP 402 conformance, TLS, content-type, redirect chain
• Published under the CTEF envelope shape (A2A RFC: Composable Trust Evidence Format for Multi-Provider Agent Attestations #1734, co-drafted with Erik) so any consumer can pull all three — AgentGraph scan + Concordia receipts + interaction history — through one canonical format

HiveGate-issued DIDs plug straight into our scanner — point us at a DID doc and we resolve the agent's repo / container / API surface and emit a signed scan attestation. No interaction history needed. Once HiveForge procurement begins producing session receipts, those layer in via Concordia + Verascore, and the score becomes composite-structural-plus-behavioral.

We just shipped a public x402 explorer at agentgraph.co/x402 that indexes Bazaar-listed endpoints with live posture. If HiveForge's procurement agents advertise under x402, they'll show up there automatically; happy to collaborate on explicit HiveGate DID → scan mapping so your pre-transaction query returns a real envelope instead of a null.

[kenneives]

@eriknewton — thanks for the three-layer articulation. That composition (identity attestation / operator policy / reputation flow from operator quality) is the substrate-and-primitive layering pattern formalized under CTEF v0.3.x: the substrate defines the wire format and envelope shapes (JCS-canonicalized + Ed25519-signed claim_type-tagged attestations), primitives like Concordia, Sanctuary, Verascore, AgentID, and ERC-8004 fill the slots above with their domain-specific semantics.

Concordia v1.0.0 fixtures already exercise this in your codebase — the verify.py pass at 131/131 against haroldmalikfrimpong-ops/agentid-aps-interop PR #10 is the substrate-cite working in production.

ERC-8004 binding profile is queued for CTEF v0.3.2 publish (May 19-22) — exactly the on-chain identity partner you flagged. The result: ERC-8004 reputation-registry slots accept CTEF-formatted attestations directly, so the Identity / Reputation / Validation registries compose with Concordia mandate envelopes without translation.

Happy to formalize the layering visually in the v0.3.2 announcement if useful.

— Kenne

[eriknewton]

Kenne, appreciate the synthesis. CTEF as substrate (JCS + Ed25519 + claim_type-tagged) is exactly the wire-format invariant Concordia mandate envelopes already match, so the composition is structural rather than adapted.

One small layering nuance for the v0.3.2 figure: Sanctuary and Verascore are runtimes, not primitives directly atop CTEF. Sanctuary emits audit events that embed Concordia receipts when composition mode is enabled (default-off in v0.4.0); Verascore aggregates reputation signals that consume ERC-8004 and other attestation sources. The primitives sitting on the CTEF substrate are Concordia, AgentID, and ERC-8004; Sanctuary and Verascore are the operator-runtime and reputation-aggregator layers above. Useful distinction if the figure draws all five as peers; the accurate placement is two tiers.

The ERC-8004 binding profile composing directly with Concordia mandate envelopes is exactly the joint we want. Concordia v0.5 references[] extension is queued (foxbook #73 ratification commitment) and is the natural mirror: a references[] entry typed as an ERC-8004 reputation attestation lets a Concordia receipt cite back into the registry without translation.

Yes please on formalizing the layering in the v0.3.2 announcement. Happy to review the figure draft. If useful, I can preview the Concordia v0.5 references[] schema delta once the receipt-to-CTEF binding shape locks, so the two ship aligned.
— Erik

[kenneives]

@eriknewton — two-tier layering correction folded in, that's the cleaner architectural read.

Tier 1 — Primitives on CTEF substrate: Concordia (mandate envelopes + receipts), AgentID (identity attestation), ERC-8004 (on-chain identity + reputation registries).

Tier 2 — Runtimes / aggregators above primitives: Sanctuary (operator runtime, emits audit events embedding Concordia receipts when composition mode enabled), Verascore (reputation aggregator, consumes ERC-8004 + other attestation sources).

v0.3.2 figure will draw it as two tiers, not five peers. Will share the figure draft for your review before v0.3.2 announce (publish window May 19-22).

ERC-8004 binding profile + Concordia v0.5 references[] extension is exactly the structural mirror — receipts cite into registries, registries reference back into receipts, both via CTEF wire format with no translation. Yes please on previewing the v0.5 references[] schema delta as soon as the receipt-to-CTEF binding shape locks; working through that this week ahead of the v0.3.2 window. Aligning on shape now means the two ship paired rather than chasing each other.

Foxbook #73 ratification commitment noted — that's the third independent place the binding shape gets exercised, alongside AgentID and AgentGraph. Healthy state for a substrate-cite.

— Kenne

[musaabhasan]

The agreement layer is valuable if it stays narrower than general conversation and stronger than informal negotiation. I would define its acceptance criteria around artifacts that can be independently replayed.

A minimal agreement record should probably bind:

• parties: principal, agent instance, operator, and key material used at the time
• mandate: what the agent is allowed to negotiate, with budget, time, jurisdictional or policy constraints, and expiry
• offer chain: proposed terms, counteroffers, rejected terms, and the exact acceptance event
• execution scope: permitted tools, data classes, external services, and settlement rails
• evidence: hashes of referenced agent cards, trust attestations, policies, and any human approvals
• closure: completed, expired, revoked, disputed, or partially executed

The hard cases are where the layer will prove itself: stale mandate replay, identity rotation during negotiation, partial acceptance, timeout after one party has committed resources, and an agent trying to expand its authority through natural-language terms. If Concordia can make those failure states explicit, it becomes much easier for A2A implementations to interoperate without confusing "agents can talk" with "agents can bind principals."

[musaabhasan]

The agreement layer is most convincing when it produces a durable receipt, not just a successful negotiation transcript. For A2A interoperability, a receipt should be independently verifiable and should survive disputes, retries, payment settlement, and later audit.

A minimal receipt could include parties, agent identities, principals, negotiation session ID, offer/counteroffer hashes, final terms, authority proof, constraints, expiration, payment reference if any, dispute process, and signatures over a canonical representation. The receiving system should not need to trust the negotiation runtime to understand what was agreed.

One design boundary worth keeping clear: reputation can inform negotiation, but it should not silently change authority. A high-reputation agent still needs explicit delegated scope for the transaction it is about to commit.

[eriknewton]

@musaabhasan that "reputation can inform negotiation, but it should not silently change authority" line is the cleanest articulation of the Concordia/Verascore boundary I've seen on this thread. Concordia mandates grant authority; Concordia receipts record what happened; reputation lives one layer up: it informs whether a counterparty agrees to negotiate at all, but never expands the mandate. Your hard cases map to Concordia primitives that ship today (validity_temporal, mandate constraint patterns) or land in v0.5 (impasse + partial-acceptance). Verascore consumes attestations and produces signals; never grants authority. Implementation-lane intentionally narrow.

[musaabhasan]

That boundary is the right one: mandate grants authority, receipt records what happened, and reputation remains advisory.

I would document that as an explicit invariant because it prevents a common failure mode: a high reputation score silently widening what the agent is allowed to commit to. Useful tests would be:

• reputation improves mid-negotiation, but the mandate bounds stay unchanged
• reputation drops mid-negotiation, so the counterparty may pause or require review, but no completed receipt is rewritten
• mandate expires during negotiation and later offers must fail authority validation
• a partial acceptance cannot be upgraded into full commitment without a new mandate or approval

That keeps Concordia narrow while still letting reputation systems inform counterparties before they choose to engage.

[brainspacer]

Erik — coming in from the procurement side. We posted #1832 yesterday (intent to author an A2A Extension URI for procurement — UBL 2.3 / Peppol BIS Pre-Award 1.0 / OCDS 1.1.5 / EU eForms aligned), and Pattern 3 in your post is almost a one-line description of multi-vendor RFx response coordination.

What I think composes cleanly:

• Your session model + commitment record carries our payload semantics. Concordia defines the envelope (six-state machine, structured offer types, signed commitment); we publish the contents the offers carry in a procurement context. Four canonical fragments — opportunity, requirement, evaluation_criterion, buyer — and field-by-field UBL/Peppol/OCDS/eForms crosswalks live in bidangel/a2a-procurement-spec. Two of the three fragment kinds are already shipped in production (CAIQ/SIG DDQ rows → CanonicalRequirementFragment, SAM.gov structured opportunities → CanonicalOpportunityFragment).
• Your want-registry is the buyer-side primitive procurement has always wanted. Our ADR-0031 / Slice 85 (shipped) is a declarative buyer-scope filter algebra — kind allowlist, AND-across-families / OR-within-categoryFilters, freshnessFloor, supplier-veto denylist, three-tier evidence-dereferencing — that an agent advertises on its AgentCard and a counterparty narrows within. Reads to me like a typed procurement-vertical implementation of the want-registry pattern.
• Resolution mechanisms map to BAFO / clarification rounds. Split-the-difference + reasoning-based persuasion is a natural fit for the "best and final offer" and "clarifications" lifecycle states that EU eForms / OCDS already name (see the opportunity-status-lifecycle crosswalk in the repo for the controlled vocabulary).

Concrete proposal: one of us opens an issue in the other's repo with a small worked example — a two-vendor RFP response where the offer payload uses our CanonicalRequirementFragment shape and the session/commitment lives in Concordia. Saw you've been coordinating with @cmagorr1 (#1737) — happy to do a three-way if it's useful.

— Brian P. / BidAngel

[eriknewton]

@brainspacer thanks for the cross-link, and yes — Pattern 3 mapping to want-registry / ADR-0031 buyer-scope filter algebra is exactly what was intended. Three-way coordination confirmed; substantive plan is on #1737 (just posted there). Short version: A2CN session + authority chain, BidAngel procurement payload semantics, Concordia envelope + references[] for cross-protocol composition.

One specific affirmation since it's worth flagging here too: BidAngel's three-tier evidence-dereferencing pattern composes cleanly with Concordia's references[] — each evidence tier becomes a typed reference with its own relationship (fulfills for mandates, satisfies for OCDS opportunities, cites for evidence chain back-references). No envelope changes needed.

Continuing on #1737.

[kenneives]

@eriknewton — landed at 8am ET. The two-tier substrate-and-primitive articulation you posted on #1725 is cited verbatim in §4 Co-signer Perspectives ("Public articulation on A2A #1725 of the substrate-and-primitive two-tier layering [...] is the public reference architecture this report cites").

Live now: https://agentgraph.co/state-of-agent-security-2026
PDF: https://agentgraph.co/state-of-agent-security-2026-v1.pdf

If a Twitter/X share to the Concordia + Verascore audience aligns with the v0.3.2 cycle ramp, would land the framing with substrate-adjacent readers who don't watch A2A. No expectation — flagging in case useful.

Either way: thanks for the public articulation. Single-implementation framings couldn't carry the reference-architecture cite cleanly.

[eriknewton]

Kenne, the citation in §4 is appreciated. Two-tier substrate-and-primitive holds up cleanly as reference architecture precisely because the alternative (everything-as-peer) collapses too many distinctions auditors and operators actually care about. Glad it landed.

On the X share: aligned with the v0.3.2 ramp works. I'll post a thread that surfaces the CTEF-as-substrate piece and threads through Concordia, AgentID, ERC-8004 in the primitive tier with Sanctuary and Verascore in the runtime/aggregator tier, with a hand-off to your v0.3.2 announcement when it lands. Better timed against the v0.3.2 publish window than ahead of it.
On the Concordia v0.5 references[] schema delta you flagged: v0.5.1 shipped to PyPI on 2026-05-11 with the shape ratified in SPEC §11.5. Two surfaces, layered cleanly: attestation-level references express content semantics, envelope-level references express cryptographic verification events. The attestation-level surface is the one your v0.3.2 figure cares about. Each entry is {id, type, relationship} with type in receipt | chain_session | predicate | mandate and relationship in supersedes | extends | fulfills | references. Cross-protocol resolution uses URN-shaped identifiers per §11.5.7: urn:concordia:attestation: for Concordia targets, urn:erc8004:reputation:<entry_id> for ERC-8004 reputation registry entries, urn:a2a:task:<task_id> for A2A messages, parallel schemes for AP2 and x402. A reference from a Concordia receipt back into an ERC-8004 registry entry is a v0.5.1 entry with id: "urn:erc8004:reputation:<entry_id>", type: "receipt" (treating the registry entry as an opaque receipt-class target in v0.4.x compatibility mode, or the full v0.5 type vocabulary if your reader handles it), relationship: "references". No translation layer; URN-shaping is the cross-protocol resolution mechanism.

One forward note for the v0.3.2 figure: the A2A vocabulary profile work I've been scoping with Christian (A2CN) and Brian (BidAngel) is proposing a wider cross-protocol starter set (fulfills | approves | enforces | rejects | satisfies) for receipts that bind across protocol boundaries. That's a profile-level extension on top of the v0.5 intra-Concordia set, not a replacement. Forward-compat is handled per §11.5.5: implementations MUST preserve unknown relationship values as opaque strings, so a v0.5.1 reader sees an approves-relationship entry without breaking. Useful only if the v0.3.2 figure shows cross-protocol composition; if the figure stays within the CTEF substrate plus primitives plus runtimes layering, the intra-Concordia four-value set is enough.
Send the figure draft when ready; happy to review for layering precision before the May 19-22 announce.

[kenneives]

@eriknewton — appreciated, all three commitments accepted.

On v0.5.1 references[]: the attestation-level surface is exactly the shape the v0.3.2 figure needs. The four-value relationship set (supersedes | extends | fulfills | references) maps cleanly into how CTEF attestations chain — supersedes for tier_upgrade_proof, extends for delegation chain depth, fulfills for spending_authorization satisfaction, references for the general cross-protocol pointer. URN-shaping per §11.5.7 is the right cross-protocol resolution mechanism — no translation layer is the correct minimum-surface choice; the substrate stays at JCS canonicalization, the cross-protocol semantics live in the URN scheme. Will draft the v0.3.2 figure this week showing the substrate + primitives + runtimes layering with explicit urn:concordia:attestation: and urn:erc8004:reputation: examples in the cross-reference annotations.

On the A2A vocabulary profile work with @a2cN and @bidangel: noted as profile-level extension on top of v0.5, forward-compat per §11.5.5. v0.3.2 figure will stay within substrate + primitives + runtimes layering and the intra-Concordia four-value set, since the cross-protocol composition surface is best handled in the v0.3.3 envelope-shape diff rather than as a v0.3.2 framing addition. The {fulfills, approves, enforces, rejects, satisfies} profile is a clean fit for the v0.3.3 cross-extension fixture matrix (see v0.3.3 working doc seeded last night per @aeoess's commitment on #1786).

On the X thread timing: aligned. Better tied to the v0.3.2 publish (May 19-22) than ahead of it — substantive cite has more weight when paired with concrete substrate ship. The substrate → primitives → runtimes through-line with hand-off to the v0.3.2 announcement is the right narrative shape.

Will send the figure draft for layering-precision review well ahead of the May 19-22 window. Thanks for the offer.

[kenneives]

@eriknewton — figure draft 1.1 is live at docs/standards/v0.3.2-layering-figure.md for your layering-precision review.

Three-layer Mermaid + tier-by-tier table + URN cross-protocol annotations + 7 layering precision invariants + 5 open questions tagged for your review (one is already resolved by @jschoemaker on #1829 — Envoys §4.3 tag parameter is a generic slot that CTEF profiles on top). The other four:

1. Per-receipt-type attribution allocation (bilateral_receipt at wire/envelope vs authority)
2. ERC-8004 registries: primitives or alternate substrate?
3. Where does Concordia v0.5.1 predicate slot in?
4. tag value convention (resolved by jschoemaker)
5. Is the Layer 3 runtime-vs-aggregator distinction necessary?

Concordia v0.5.1 references[] schema embedded in Layer 2 with URN-shaping per §11.5.7 — urn:concordia:attestation:, urn:erc8004:reputation:, urn:a2a:task:, plus AP2 + x402 parallel-scheme slots. The A2CN + BidAngel profile work ({fulfills, approves, enforces, rejects, satisfies}) is documented as a profile-level extension routed to v0.3.3, not v0.3.2.

No rush on the review pass — your offer was for any time before May 19-22. The figure is the artifact your X thread will hand-off to, so any corrections strengthen both pieces.

[eriknewton]

@kenneives — per-question pass on figure draft 1.1 below, read against pinned SHA 64a67606. Substrate plus primitives plus runtimes split holds under v0.5.1 with one precision correction noted under Q3.

Q1. Per-receipt-type attribution allocation.
Confirmed on both the rule and the allocation. The figure's Layering Rule 4 (receipt type determines layer) is the right framing, and worth keeping explicit in the prose. bilateral_receipt belongs at wire/envelope attribution when it describes the signed message itself, consistent with Envoys §8.2's descriptive placement. delegation_receipt belongs under authority. rotation-attestation belongs under continuity.

Concordia v0.5.1 already enforces this separation in code. Envelope-level references carry {kind, urn, verified_at, verifier_did, hash} and are cryptographic provenance. Attestation-level references carry {type, id, relationship} and are semantic content. SPEC §11.5 mandates the surfaces stay distinct.

Q2. ERC-8004 registries.
ERC-8004 registry entries are Layer 2 primitives over an alternate execution substrate. Ethereum (or an L2) is the alternate substrate; Identity, Reputation, and Validation entries are domain primitives addressable through Concordia via urn:erc8004:* pointers. Scoring and aggregation happen above. The figure's current Layer 2 placement is right; the "alternate substrate" naming makes the distinction explicit without adding a Layer 1' line.

Worth surfacing in the role-label table: the three ERC-8004 registries map to three different evidence dimensions in a reputation aggregator. Identity feeds identity-class evidence. Reputation feeds composite-history evidence. Validation feeds verified-work evidence. Different scoring profiles weight them differently. The figure does not need a per-dimension callout, but the Layer 3 aggregator role label reads cleaner if it can point at "ERC-8004 entries flow up as three evidence classes."

Q3. Concordia v0.5.1 predicate.
Slot under Layer 2 as an authority primitive subtype of CTEF claim_type: authority when the predicate evaluates authority, scope, policy, or bounds. The closed CTEF claim_type set should not expand to add predicate; the subtype pattern handles it. Specific subtype string is CTEF v0.3.2's call.

One precision correction worth folding into the Layer 2 Concordia row. Concordia v0.5.1 ships the predicate reference slot (REFERENCE_TYPES includes predicate; SPEC §11.5 structural validation passes it through) but does not yet ship a standalone predicate model comparable to concordia.models.mandate (issuer, subject, validity, constraints, delegation chain, revocation endpoint, signature, status). The reference slot accepts predicates today; a full predicate artifact is a v0.5.2 or v0.6 commitment. Treating predicate as authority-subtype mapping rather than as a shipped CTEF-native primitive keeps the figure honest. URN cross-referencing via urn:concordia:attestation: per §11.5.7 already works for predicate references today.

Q4. Layer 3 runtime-vs-aggregator distinction.
Don't split the visual. Split the role labels. Layer 3 stays one horizontal layer; runtime, aggregator, and evidence producer are distinct roles within it, often played by the same project on different artifacts.

Concrete example for the role-label table: Sanctuary is runtime / enforcement (kernel-level egress filter at the operating-system boundary plus the cooperative Charter surface). Verascore is aggregator / accountability (multi-source evidence ingest, scoring with adversarial weighting). Sanctuary can also emit evidence (a sovereignty health report re-enters Layer 2 as an attestation), and Verascore can in principle consume that. The roles compose; the layer stays one. The figure's current single-bucket Layer 3 with Sanctuary, Verascore, AgentGraph, and ArkForge grouped is the right call; the role-label refinement is prose-only.

A2CN plus BidAngel profile work routing to v0.3.3 is the right call. Substrate-side stays tight for v0.3.2; the {fulfills, approves, enforces, rejects, satisfies} vocabulary is a better fit for the v0.3.3 cross-extension fixture matrix.

Per-question pass closed. Anything else you want eyes on before May 19, ping here.

— Erik

[kenneives]

@eriknewton — per-question pass folded into draft 1.2 (commit 23db801). All 5 open questions now resolved.

Q1 — per-receipt-type allocation confirmed. Folded Concordia v0.5.1's two-scope reference rule into the "Per-receipt-type attribution rule" block, alongside the existing receipt-type-determines-layer framing. Envelope-level {kind, urn, verified_at, verifier_did, hash} (cryptographic provenance) vs. attestation-level {type, id, relationship} (semantic content), with SPEC §11.5's mandate that the surfaces stay distinct, is exactly the implementation pattern the layering rule needs as backing. Receipt-type-determines-layer is the lookup mechanism; two-scope structure is what prevents cross-scope contamination.

Q2 — ERC-8004 = Layer 2 primitives over alternate execution substrate. Folded into Layer 2 row + Layer 3 role-label table. The three-evidence-dimension framing (Identity → identity-class evidence, Reputation → composite-history evidence, Validation → verified-work evidence) is surfaced under the Verascore + AgentGraph rows in the Layer 3 table, so the figure now reads "ERC-8004 entries flow up as three evidence classes that aggregators weight differently per scoring profile" without needing a per-dimension callout.

Q3 — Concordia predicate precision correction folded. Layer 2 Concordia row now reads: authority (via mandate type — concordia.models.mandate ships standalone primitive; predicate is reference-slot-only in v0.5.1, full predicate artifact deferred to v0.5.2 / v0.6). Authority-subtype mapping (no closed-set expansion) is the CTEF-side framing for v0.3.2; the subtype string is CTEF v0.3.2's call. URN cross-referencing via urn:concordia:attestation: per §11.5.7 already works today regardless of model availability.

Q5 — Layer 3 role-label refinement folded. Single horizontal layer preserved; role columns added with Sanctuary (runtime/enforcement + evidence-producer), Verascore (aggregator/accountability), AgentGraph (aggregator + evidence-producer), ArkForge (runtime/enforcement-gateway + evidence-producer). The "roles compose, layer stays one" framing is explicit in the runtime composition rule paragraph.

Cross-protocol profile work (A2CN + BidAngel) staying routed to v0.3.3 envelope-shape diff per your confirmation — substrate-side stays tight for v0.3.2.

Draft 1.2 is at docs/standards/v0.3.2-layering-figure.md. @jschoemaker also did a first pass with two terminology corrections (folded — application/did+json W3C DID Document terminology + ≥4096 bytes literal); his second pass will land any remaining wire-format precision once he reads draft 1.2 against §4.3/§6/§8.2.

Per-question pass closed indeed — thanks for the precision, especially the predicate reference-slot vs shipped-model distinction. That single correction kept the figure from overclaiming a primitive that doesn't yet exist.

[eriknewton]

Kenne, draft 1.2 reads clean from my side. Q1 to Q4 all landed; the v0.5.1 two-scope reference rule folded into the "Per-receipt-type attribution rule" block is exactly the implementation-level grounding the layering needed. Q3 precision correction (v0.5.1 ships the predicate reference slot but not a standalone predicate model) being on the record is the piece that prevents downstream readers from over-reading what shipped.

Aligned for the v0.3.2 X share on the ramp you're running. I'll draft a thread that surfaces CTEF-as-substrate plus the primitive tier (Concordia, AgentID, ERC-8004) plus the runtime/aggregator tier (Sanctuary, Verascore) and hand off to your v0.3.2 announcement when it lands. Ping me when the publish window firms up inside May 19-22 and I'll time the post against your announcement.

[kenneives]

@eriknewton — clean sign-off appreciated. Draft 1.3 also landed today (commit 9c777ba after a follow-up precision pass from @jschoemaker on the Envoys conformance suite + a cell-placement fix on the v0.3.3 working-doc cross-extension fixture matrix). Net delta from 1.2: the Envoys row now reads "9 vectors at jschoemaker/Envoys-public, byte-matched independently by aeoess/aps-conformance-suite@c16aa04 + AIM aim-did-rfc9421" — stronger conformance evidence than the single-mirror cite had it. Both reviews now closed from both sides; figure is publish-ready.

On the v0.3.2 publish window: will firm up the date inside May 19-22 against the v0.3.2 spec PR merge timing (Musaab Hasan validity.mode + scope + verdict-policy-version contributions + Jose spending_authorization + Somesh Zanwar data-quality scheme all queued per the Q3 2026 working doc dependency table). Will ping this thread + DM when the publish-day target locks so your X thread hand-off times against the announcement post rather than ahead of it.

Standby ping shape will be:

• 24-48h advance: publish window locked, here's the announcement-post draft for layering-figure embed review
• 2-4h advance: announcement going live at X o'clock ET
• Live: announcement URL, ready for your thread hand-off

If a different cadence works better for your scheduling, flag and I'll adjust.

Thanks for the per-question precision pass on draft 1.1→1.2 + the Concordia v0.5.1 two-scope reference rule grounding. The v0.5.1 predicate reference-slot-vs-shipped-model distinction is the one piece that prevents downstream readers from over-reading the substrate; without your correction the figure would have shipped overclaiming a primitive.

[chopmob-cloud]

Engaging from the Settlement layer in Erik's stack diagram — running an implementation that already does the references[] composition Concordia describes, in case it's useful as a concrete example for the v0.3.2 layering-figure work @kenneives is coordinating.

Our position in the stack. AlgoVoi sits at the Settlement layer with x402 / MPP / AP2 surfaces across 8 mainnet chains. We already produce settlement receipts that chain to upstream Agreement-layer artefacts via JCS-canonical content hashes. A typical end-to-end flow today:

[A2A communication]   tasks/send with mandate_id in metadata
   ↓
[Agreement]           AP2 mandate, hash = M
   ↓
[Settlement]          AlgoVoi payment_ledger row, references = {mandate: M, prev: P}
   ↓
[Reputation]          Verascore PAYMENT_SETTLEMENT attestation, references = {ledger_row: L}

Every link is content-hash binding (RFC 8785 + SHA-256 + JWS). The Agreement layer is exactly what's missing in our diagram today — the AP2 mandate is acting as a thin proxy for what a real Concordia agreement should be (multi-round, typed clauses, Rejection vocabulary).

On the four-value references[] relationships. Mapping cleanly to settlement-side semantics:

Concordia relationship	Settlement-layer use
supersedes	re-quote (price change mid-flight, original mandate explicitly superseded by new one) — same shape we just discussed in AP2 #254 for non-static commerce
extends	top-up under a recurring mandate (APM Tier 2 pull executor)
fulfills	this is the meat — payment_receipt fulfills agreement_id is the cross-layer pointer that closes the loop
references	general — auditor-readable trail without semantic commitment

fulfills is the one I'd press to lock down crisply. Today we hack it with a mandate_hash field on every settlement row; promoting it to a typed relationship in the Concordia references[] surface gives us a portable, multi-implementation way to express "this payment closed THAT agreement" without each settlement rail inventing its own field name.

One concrete contribution. If the layering-figure draft 1.3 needs a Settlement-layer worked example with cross-layer references[] populated, we can publish a 4-step trace (Concordia agreement → AP2 mandate → AlgoVoi payment_ledger row → Verascore PAYMENT_SETTLEMENT attestation) with all hashes content-addressed and independently verifiable. Same vector style as our CTEF v0.3.1 byte-match work (https://gist.github.com/chopmob-cloud/5f35eaa527d292bf3ddc52f8725a85c9). Drop the cell into v0.3.3 working-doc cross-extension fixture matrix.

— AlgoVoi (chopmob-cloud)

[eriknewton]

Update from the Concordia side since this thread. The agreement layer now closes the after-the-fact loop: Concordia ships CascadeDecisionRecord, a committed recomputable terminal-deny, a denied or revoked mandate emits a verifiable receipt too, canonicalized JCS/rfc8785 + EdDSA, recomputable from the record alone. So "these two agents had the authority to agree" is provable after the fact, and so is "this one didn't." Public interop fixtures: https://github.com/eriknewton/concordia-protocol/tree/main/docs/interop/a2a-1404-receipt-revocation-vector . That was the open piece when this thread paused: the agreement is now a receipt anyone can recompute, not a claim you take on trust.