Capability deep-dive · inter-company corridors

Your recovery demand leaves as a PDF, lands in an inbox, and comes back weeks later with no shared state.

Two companies are running the same claim from two copies of the facts, and neither can see the other’s copy. The protocol layer for machine-to-machine work between organisations now exists as a published specification. The governance layer on top of it does not exist anywhere yet — including here.

The version gap, stated beside the conformance claim

v0.3.0the specification version our public agent endpoint conforms to, pinned by an executable conformance suite[O]◆

v1.0.0the current published specification — the first stable release, adding signed agent cards and further bindings[V]

5conformance groups the suite asserts: task fields, error semantics, card paths, cancellation, card recommended fields[O]◆

noneinsurers running inter-company agent corridors in production anywhere, ourselves included — [P: to be calibrated][P]⧖

The corridor governance layer is new build. The transport beneath it is shipped and tested, and this page keeps the two apart.

The task lifecycle, and the two states that make it governable

A task moves from submitted to working and then to one of four terminal states — completed, failed, canceled, rejected. Two further states pause a task without terminating it, and they are the ones a regulated corridor is built on.

interrupt state

input-required

In the design, this is not a queue item. A counterparty asking for a decision that matters convenes a room, and the reply is emitted by a named chair’s ruling at a durable waitpoint. There is no code path that answers a consequential request without one, and the corridor produces no record outside the governed thread.

interrupt state

auth-required

Discovery is decentralised — a peer publishes a card at a well-known path and there is no central registry. That is precisely why counterparty admission has to be a product rather than an assumption, and why an unopened channel refuses in the protocol’s own vocabulary rather than with a status code a peer’s SDK will swallow.

What is shipped, and what a corridor would inherit rather than rewrite

Stateless, domain-bound task tokens

A task id carries its own signature over the job and the domain, so a token minted for one domain is invalid on another and any pod after any restart answers identically, with no session store to lose.

A derived context id, never minted

The required context id is derived deterministically from the domain and job, so two calls echo byte-identically with nothing stored — and the same job on a different domain cannot collide.

Method errors leave as a readable body

A domain refusal travels in the response body where a caller can read the code and the retry window, rather than as a bare status the reference client re-raises before application code ever sees it. Transport faults stay visible as faults.

The card answers on both well-known paths

The current path and the pre-0.3 path are both served, and the host gate is not weakened by the compatibility path. That is the same discipline a corridor spanning two specification generations needs at every version boundary.

the agent endpoint(shipped)the conformance suite(shipped)counterparty identity, vetting and the grant matrix(designed, not built)dually-signed terminal artefacts and claim-state reconciliation(designed, not built)

Admission is a product of hard gates, not a score

In the design, a corridor opens only when every hard gate passes and a named tenant administrator approves. The gates multiply — the card resolves and parses, the signature verifies under a key the card names, the legal entity resolves against the declared operator, the regulatory permission covers the claimed skill, a live conformance probe round-trips against the pinned version, the authentication scheme is one of the two admissible ones, and the contractual resilience clauses are in place. Soft factors like dispute rate and time-to-terminal modulate the score; none of them can rescue a failed hard gate. That product form is the arithmetic of failing closed.

VETTING IS CONTINUOUS, AND VERSION IS A PROPERTY OF THE RELATIONSHIP

A card whose content hash changes without notice, a signature that stops verifying, a peer that starts answering on a different specification version, a conformance probe that goes red on re-run, a lapsed permission — each suspends the corridor and emits a record. Revocation itself requires a human, because revoking a counterparty is a consequential act. And a corridor may not be pinned to a version whose conformance suite is not green. Silent auto-upgrade is refused.

One rule is worth stating on its own, because it is the classic seam defect: a valid signature proves who. It never proves may. Authority is checked on every call through the same scope predicate as every internal read, so a signed card can never quietly become a capability.

Where a corridor fails closed

REFUSED

SIG_INVALID

The counterparty’s agent card no longer verifies under the key it names. The corridor moved to suspended and no task was accepted.

A corridor is a standing authorisation to act between two companies, so the evidence behind it is re-checked rather than remembered. A failed signature, a silently changed content hash or a red conformance probe suspends the channel and emits a record; only a named human can move it to revoked. Key rotation is a governed change with a bounded overlap window, announced on every open corridor before the old key stops answering — an ops action that silently rolled a key would look exactly like this refusal, which is why it is not one.

signed-card verification arrives with the v1.0.0 migration — designed, not built

The honest limit

WHAT THIS DOES NOT DO YET

A2A migration from the spec version our endpoint conforms to (v0.3.0) to the current one (v1.0.0), plus the party model, claim-state synchronisation and conflict surfacing.
The precise object-level delta between the two specification versions is not something we have read off the normative text, so this design builds the migration machinery and does not assert the diff.
Counterparty identity, vetting, the grant matrix, the consequential-action gate, dually-signed terminal artefacts and the corridor monitor are all new build.
Every threshold — the admission bar, the key and version overlap window, the ageing and utilisation triggers — is [P: to be calibrated], because no inter-company insurance mesh exists to calibrate against.
The second corridor waits on a paired baseline from the first. If the recovery and cycle-time deltas include zero, that is the finding and it gets reported.