Two agents, one exchange, and nobody in the middle

An agent acting for a logistics operator meets an agent acting for a warehouse it has never dealt with. They agree, in seconds, that one will release a dock slot and the other will take it. Then the exchange has to close, and every available answer assumes something the moment does not have. A processor answer assumes both sides hold accounts with the same processor. A ledger answer assumes a quorum and a commit. A session answer assumes the parties enrolled with each other beforehand.

Much of the engineering effort in agentic commerce has gone to a different and legitimately urgent question: how a principal keeps an autonomous agent from spending money it should not spend. That is a control and authorization problem, and the tooling built for it is good at what it does. Closure is a separable problem, and it is the one the disclosed architecture addresses: the point at which two parties who share nothing but a signed statement each recognize that the transaction is done, and each hold a record that proves it.

What the Stripe Agent Toolkit is built for

The Stripe Agent Toolkit is, as publicly described, a toolkit that lets AI agents and agent frameworks work with Stripe's payments APIs through tool and function definitions a model can call. Payment operations are presented to the agent as callable tools within its own toolchain, so commerce actions can be taken inside the same loop the agent uses for its other work. Public materials describe it as something a developer integrates with an existing agent framework and an existing Stripe account.

The intent it serves is the right one. Agents are non-deterministic, and giving one unbounded access to a live payments account is not acceptable to any serious operator. The category answer, and the one this toolkit is publicly associated with, is to make agent access to payments explicit, scoped, and observable: a defined surface of permitted operations rather than an open credential.

For the problem it addresses, that is a strong position. An agent transacting for a business generally should be transacting through that business's established payments relationship, where the merchant's obligations, refunds, chargebacks, and reconciliation already live. Nothing in the architecture described below competes with that.

The structural question is what a payments authorization and execution layer is organized around, which is an agent's access to an account and the movement of value through a payments network. That is a different question from the one the filing takes up, which is how two independent parties, each with separate authority and separate records, recognize between themselves that a bilateral exchange has closed.

Settlement recognized from a matched pair

The filed architecture settles a bilateral exchange between a semantic agent (100) and a counterparty through a matched pair (600) of governed observations, each bearing an authority credential, the pair recognized within one or more of a spatial proximity window and a temporal proximity window (602). The pairing rule requires spatial coincidence, temporal coincidence, or both, as the governing policy object declares. The settlement is recorded by a settlement-lineage recorder without a third-party intermediary, without centralized consensus, and without pre-negotiated session state.

A governed observation is a signed structure carrying, in sequence, an authority credential field, a continuity hash field encoding identity continuity of the emitting party, a spatial reference field, a temporal reference field, a time-to-live field, a payload field, and an observation lineage field. Emission is complete upon emission: the emitting party requires no acknowledgment, no handshake, no delivery confirmation, and no registration with a central authority as a condition of emission. An observation lacking a verifiable authority credential is not a governed observation within the meaning of that disclosure.

The first governed observation (608) represents an offer, a tender, a claim, a demand, or a commitment; the second (610) an acceptance, a counter-tender, an acknowledgment, a refusal, or a fulfillment. When the pairing rule recognizes the two within the applicable window, the pair binds into a settlement record (604) comprising both signed observations, a cryptographic binding over both, and an attestation of the window within which the pair was recognized. That record is verifiable by a downstream consumer from itself alone.

Identity for pairing is carried by continuity, not enrollment. The continuity hash field holds two subfields computed by different constructions: a successor hash field, being the emitting party's dynamic agent hash at emission, verified by an equality test rather than a distance test; and a continuity vector field, an ordered tuple of a declared count of components, each a projection of the party's operational state normalized to the interval from zero to one. A trust-slope validator computes a trust-slope consistency measure from the continuity vector field and no other field. An observation is accepted on continuity only where both conditions hold conjunctively: the per-step distance against its predecessor does not exceed a declared per-step ceiling, and the measure is not less than a declared acceptance threshold. Both bounds are declared in the governing policy object, and the filing fixes no value for either.

Admission runs through a settlement admissibility evaluator producing exactly one outcome from a set of graduated outcomes: admit, gate, defer, solicit, reject, or escalate. Evidential weight is a coefficient-weighted sum of four factors, authority, continuity, freshness, and corroboration, the coefficients being declared in the governing policy object as non-negative values summing to unity. Where evidential weight is less than a declared admission threshold, the gate outcome issues and the input is admitted at the product of that weight and a declared gate reduction factor; where it is less than a declared admission floor, the reject outcome issues with a rejection-reason classification. The filing fixes no value for either bound.

Each party appends its own settlement-lineage entry (606) into its own append-only lineage field (104), recording both observations, the pairing determination, the cryptographic binding, each escrow event, each failure and rollback, and each downstream consumption of the settlement record. Each party's transaction history is reconstructible from its own lineage, without recourse to the counterparty and without recourse to any registry. Entries are neither removed nor modified.

The filing is equally specific about non-closure. A timeout resolves nothing against either party, and neither the party whose observation went unanswered nor the party that did not answer incurs any adverse consequence. A refusal is emitted as a refusal observation and metered against the refusing party's own settlement-binding authorization, the increment and bound being declared in the governing policy object and applied without any determination of whether the refusal was well founded. Where the meter satisfies that bound, that authorization is written from a granting state to a withheld state, the party's capacity to observe, to produce determinations, and to emit further refusal observations being preserved. Disputes, timeouts, and failed fulfillments increment no refusal meter of either party.

Where the layers diverge, and where they do not

Both approaches accept the same premise: an agent should not transact on unbounded authority, and what it does should leave a record. That convergence is why the comparison is worth making.

Divergence begins with what the record is a record of, and who holds it. The filed architecture requires a per-party settlement lineage of a bilateral recognition event, held independently by each side, in which the evidence of closure is the two parties' own signed observations bound together with an attestation of the window in which they were recognized. A payments integration operates on the merchant's own payments account, where the records and the reconciliation the business already relies on continue to live.

Preconditions diverge next. The filed architecture is explicit that no account relationship, no session key, no standing channel, and no prior enrollment of either party with the other is a precondition of the pair. Consent is expressed per transaction by the paired observations themselves, and a party that has never encountered the counterparty may nonetheless form a pair. A payments toolkit is integrated against an existing payments account, which is the appropriate arrangement for a business transacting under its own merchant relationship.

Finality is the third. Under the filing, finality attaches upon recognition and admission of the pair itself, with no quorum, no distributed ledger commit, and no consensus round a condition of settlement.

None of this makes one a substitute for the other. Value movement through regulated rails is not what a matched pair does. A matched pair effects the state transition it was formed to effect, being a transition of the authorization gate (300) for an enumerated action class, a promotion or demotion of a persistence designation, or a transfer of a settlement-binding authorization.

Coexisting in a real deployment

Picture a procurement agent closing with a supplier agent it has no prior relationship with. Negotiation and closure run as matched-pair settlement: offer and acceptance as paired governed observations, admissibility evaluated per round, counter-observations bounded by a round count declared in the governing policy object, and a settlement-lineage entry appended by each side. Money then moves through the merchant's existing payments relationship, and the settlement record stands as bilateral evidence of what was agreed and when.

What the disclosed architecture does not solve is worth being direct about. It does not move funds, does not underwrite, does not touch card networks or bank rails, and does not discharge a merchant's obligations for refunds, chargebacks, tax, or regulatory reporting. Escrow in the filing is a custody construct over settlement content with a release condition specification, bounded above by an escrow-depth bound declared in the governing policy object, not a regulated escrow service. Dispute handling routes to a dispute-resolution procedure declared in the governing policy object, which may be authority adjudication, arbitration, regulatory review, or a legal-system procedure. The filing declares the routing, not the forum.

The division is legible. One layer answers whether an agent may spend and executes the movement of value. The other answers whether two independent parties recognized a closure between themselves, and leaves each able to prove it afterward from its own records.

Disclosure Scope

The settlement architecture described here is disclosed in U.S. Provisional Application No. 64/117,812, and the matched-pair subject matter originates in U.S. Provisional Application No. 64/049,409. These are pending applications. Reference numerals correspond to elements as described in those disclosures.

Statements about the filed architecture are limited to what the filing discloses. Where a window, coefficient, threshold, bound, or increment is declared in the governing policy object, no value is asserted here and none should be inferred, and outcomes conditioned on such a bound are stated as conditioned.

References to the Stripe Agent Toolkit are to public materials and are used for comparison only; no relationship, endorsement, or infringement is asserted.