Transactional semantics gap: canceled is not compensated: reference schema for a commitment layer

[valeriouberti]

First off congrats on v1.0, the protocol has come a long way in a year.
I want to raise a design-level question about the task lifecycle. The current states (submitted, working, input-required, completed, failed, canceled) describe the task itself, but say nothing about the side effects a task has already produced when it fails or gets canceled mid-chain. In a multi-step delegation (e.g. vendor onboarding: create record → reserve budget → provision tenant → compliance check → capture fee), a failure at step 4 leaves steps 1-3 in effect with no protocol-level way to unwind them: no saga context propagating across the delegation chain, no way for an agent to advertise “this operation is compensable, here’s how,” no idempotency semantics in the transport.
I wrote a longer analysis of this gap here: https://www.valeriouberti.dev/articles/agents-can-talk-but-they-cannot-commit
To make the discussion concrete rather than hypothetical, I’ve also built a small reference implementation of the missing piece a typed “plan artifact” schema plus a validator that enforces its invariants before execution:
https://github.com/valeriouberti/apology-protocol
The schema carries: step classification (compensable / retriable / irreversible), compensation declared in advance (not improvised at rollback time), an explicit pivot point after which there is no undo, per-step idempotency keys, undo-token TTLs, and an authority mandate (spend cap + expiry). The validator enforces invariants like: no irreversible step before the pivot, undo TTLs must cover the worst-case path to the pivot, and a step that claims irreversible cannot also declare a compensation, if it does, it’s lying about one of them.
Questions for the maintainers/community:
1. Has transactional/compensation semantics been discussed before? (I searched issues/discussions and didn’t find a dedicated thread happy to be pointed to prior art I missed)
2. Is this considered in scope for A2A itself: e.g. reversibility declarations in Agent Cards, effect-context propagation across delegations or deliberately left to a layer above?
3. If a layer above: would it be useful to align the plan-artifact schema with where the spec is heading? I’d rather converge on something interoperable than invent in a vacuum, and I’m happy to adapt the schema to fit A2A’s direction.

[chopmob-cloud]

The current states "say nothing about the side effects a task has already produced when it fails or gets canceled mid-chain" is the gap in one line, and the invariant you draw, that a step claiming irreversible cannot also declare a compensation, is the right kind of constraint to build on. The observation worth adding is that your pivot point is not only a lifecycle marker, it is an authorisation boundary, and that changes what the schema has to carry.

Before the pivot, an undo runs under the same authority that approved the forward action, so an undo token bound to that mandate is enough to reverse it. After the pivot there is no undo, only a new forward action, a refund or a reversal, and that action needs its own authority, because reversing a captured spend is itself a privileged and spendable act. So the authority mandate probably has to size the compensation path as well as the forward path, with its own cap and expiry, or a compensation becomes an unbudgeted action the original mandate never accounted for. In the same spirit, per step idempotency keys are stronger bound to the canonical bytes of the step than as free tokens, since a replay then cannot present a different payload under the same key.

On your second question, the split that seems to hold is A2A declaring compensability and effect context as capability metadata and propagating an effect context identifier across the delegation, while the plan artifact and its invariants sit a layer above. A2A leaves in-task authorisation to implementations and extensions today, so the schema would be defining that authority model rather than reusing one, which is an argument for aligning it with the Agent Card signing and the extension mechanism before parallel approaches harden. Would you expect the undo token and the compensation declaration to be signed under the same mandate that authorised the forward step, so a verifier can confirm the compensation was pre-authorised rather than improvised, or is rollback authority meant to be established separately?

[valeriouberti]

This is exactly the kind of pushback I was hoping for. The reframing of the pivot as an authorisation boundary rather than just a lifecycle marker is, I think, correct, and it cleanly splits the answer to your question in two.

Before the pivot: same mandate, verifiable pre-authorisation. The compensation declaration is part of the plan artifact, and the artifact is signed as a whole under the mandate, so the undo is pre-authorised by construction. That's the core of the design stance: compensation declared in advance is only meaningful if a verifier can confirm it was inside the signed contract, not improvised at rollback time. And I'd argue it must be the same mandate: a separate rollback authority for pre-pivot steps would reopen the gap the declaration exists to close. You could end up mid-saga with forward authority but no reverse authority, which is precisely the "unrecoverable while succeeding" failure mode.

After the pivot: your point stands, and the current schema undersizes it. A refund or reversal is not an undo. It's a new forward action, privileged and spendable, and running it under the original mandate would make it an unbudgeted act the mandate never accounted for. I hadn't carried this through: the mandate should size the apology path separately, with its own cap and its own expiry, plausibly longer than the forward path's, since apologies happen on human timescales. Concretely: mandate.forward and mandate.apology, each with {maxSpendEur, expiresAt}, with the validator refusing plans whose post-pivot steps declare reversal costs exceeding the apology budget. Tracking here: valeriouberti/apology-protocol#1.

On idempotency keys bound to canonical bytes: agreed, and it's strictly better. ${sagaId}:${stepId} guarantees uniqueness but not integrity. A replay can present a different payload under the same key, and the executor has no protocol-level way to notice. Deriving the key from a hash of the step's canonical serialization closes that: same key + different bytes = rejected before execution. The open design question is canonicalization itself. JCS (RFC 8785) seems the obvious candidate, but if A2A already has a canonicalization convention around Agent Card signing, reusing it would be strictly better than introducing a second one. Tracking here: valeriouberti/apology-protocol#2.

On layering and where to take this: the split you describe matches where I'd hoped this would land. A2A carrying compensability and effect context as capability metadata, an effect-context identifier propagated across delegations, and the plan artifact with its invariants a layer above. Your point about aligning with Agent Card signing and the extension mechanism before parallel approaches harden is well taken: I'd rather adapt the artifact's authority model to A2A's signing primitives than invent a competing one. What's the right vehicle for that from your side: a formal extension proposal, a design doc to iterate on, or continuing here first? Whichever fits your process, I'm happy to draft the artifact-side as a concrete starting point.

[chopmob-cloud]

On the vehicle: I would keep shape-finding here for one more turn, then take the A2A-facing surface to a formal extension proposal, with the plan artifact staying your spec a layer above that references it. Everything A2A has to carry, a compensability declaration, an effect-context identifier propagated across delegations, and the reversibility and authorisation metadata, is capability metadata on the card and the task, which is what the extension mechanism is for. The artifact and its invariants are richer than one extension should encode, so they belong in the companion spec rather than in a standalone design doc.

On canonicalisation you do not have to choose, because A2A already pins it. Specification section 8.4.1 requires Agent Card content to be canonicalised with JCS (RFC 8785) before the JWS is computed, and AgentCardSignature is an RFC 7515 JWS over that canonical payload. Reusing it is the same primitive the card layer already mandates, and a second convention would fork verification for no gain. An idempotency key taken from a hash of the step's RFC 8785 canonical bytes then reuses that canonicalisation, not a parallel one.

One edge to carry across: the rule is not RFC 8785 alone, it is RFC 8785 after Protocol Buffer field-presence handling (8.4.1 rule 1, section 5.7). Explicitly set to a default and omitted are distinct, and only the explicit case survives into the canonical form. If the artifact or a step uses proto3 default-value semantics, a field that round-trips through its default hashes differently from one carried explicitly, breaking key stability on exactly the optional fields most likely to vary. Pinning presence semantics in the schema closes that early.

On the mandate split, forward and apology as separate {maxSpendEur, expiresAt} is the right cut, and it composes with pre-authorisation: the verifier that confirms a compensation was in the signed contract can also confirm the mandate covers the reversal cost, so the unbudgeted case is refused at authorisation time, not at rollback. Happy to review the artifact-side draft against A2A's signing primitives once it is up.

[valeriouberti]

That settles both open questions cleanly, thank you. Adopting JCS via 8.4.1 rather than pinning it independently is clearly right: one canonicalisation, one verification path, and the idempotency key becomes a hash over the same canonical bytes the signing layer already produces.
The field-presence edge is a genuinely useful catch. The artifact is JSON-native, so proto3 default semantics don't apply directly, but the equivalent hazard exists: a validator or SDK that materialises defaults before hashing would make omitted and explicit-default collide or diverge depending on the implementation. I'll pin this in the schema spec as an explicit rule: omitted means absent, defaults are validator semantics and never enter the canonical form, and canonicalisation happens over the bytes as authored. With a test fixture asserting that an omitted optional field and the same field set to its documented default produce different hashes, so implementations can't drift quietly. Same for signature exclusion: the artifact's own signature field stays out of the canonical bytes, mirroring 8.4.1's rule for the card's signatures field, so implementations can't diverge on whether the plan is hashed with or without its signature.
On the mandate split composing with pre-authorisation: agreed, and it strengthens the core stance of the project. The same verifier confirms the compensation was in the signed contract and that the apology budget covers it, so the unbudgeted-reversal case is refused at authorisation time. Everything moves left of execution, which is where this whole layer wants to live.
Concrete next steps on my side, in order:
Ship the canonical-bytes idempotency key (JCS per 8.4.1, presence rule pinned, signature excluded) in apology-protocol 0.2.0. Tracking: valeriouberti/apology-protocol#2. The mandate split follows as 0.3.0 once its shape stabilises against the extension surface: valeriouberti/apology-protocol#1.
Draft the extension proposal for the A2A-facing surface: compensability declaration, effect-context identifier propagation, reversibility and authorisation metadata as capability metadata on card and task, per the extension mechanism.
Restructure the artifact repo's documentation as the companion spec the extension references.
I'll post the extension draft here for a first pass before taking it through the formal process, and I'll take you up on the review of the artifact-side draft against the signing primitives once 0.2.0 is up.

[valeriouberti]

Shipped in apology-protocol 0.2.0: canonical-bytes idempotency keys per §8.4.1 — JCS (RFC 8785, vendored with the official test vectors), signature excluded from the hashed bytes, and the presence rule (omitted stays omitted, explicit-at-default included).
The §5.7 divergence case is now a checked-in fixture pair: the same optional field omitted vs. explicitly set to its default produces different hashes, and a key-integrity rule rejects a replay that presents different bytes under the same key.
Release notes: https://github.com/valeriouberti/apology-protocol/releases/tag/v0.2.0