A coding agent can often correct an error after the fact. For a financial operation or irreversible change, that approach reaches a limit: a second attempt can produce a second effect. Recovery becomes a business security problem.
With Swarm, I explore the separation of agent reasoning from explicit execution control. Cursor’s work on self-driving codebases offers coordination experience. Its experimental domain does not qualify a banking process.
The payment whose response never arrives
Consider an authorised payment request. The connector receives the instruction, but the connection fails before the requester obtains a usable response. The effect may not have happened, or it may have happened without confirmation. At that point, a transport error does not mean no payment occurred.
If the agent recreates the operation under a new identity and resends it, payment could be duplicated. Reporting a definite failure could also trigger a manual intervention that duplicates the effect. Uncertainty must therefore survive through the report, interface and recovery decision.
An acknowledgement, an authorisation decision and an observed effect are three different facts.
This scenario exposes a critical process risk. It is not a real payment executed by Swarm: the relevant pilot connector has simulated effects.
Retain intent before deciding to retry
Controlled recovery retains the identity and parameters of the intent: beneficiary, amount, currency, resource and mandate. An idempotency key lets the connector recognise the same operation within its contract. Changing parameters or generating a new key to bypass an uncertain result breaks that binding.
Stripe’s idempotency documentation illustrates this mechanism for its API, with specific reuse and retention rules. These properties depend on the service; they are not a universal exactly-once guarantee.
When the effect is unknown, the process must seek authoritative state and reconcile before allowing another emission. Reconciliation itself may fail or remain ambiguous, and that limit must remain visible. Later compensation is a separate operation requiring its own authority; it does not erase the initial effect.
What Swarm’s pilot contains
The Rust Trust monitor includes commitment and reconciliation operations in a simulated domain. Its contract distinguishes committed, denied, unknown and reconciled states. Handling an already committed, reconciled or unknown action must not be mistaken for a new effect merely because commitment is replayed.
The control re-examines the mandate and applicable operation conditions. An approval in principle must not cover altered parameters. These contracts can be examined in source; they establish neither a production finance connector, nor control of every external path, nor complete authority independence.
Reporting is part of the risk
An architecture can retain the right state and still mislead an operator if a layer turns “unknown outcome” into “failed without effect”. Outputs, errors, logs and manual recovery require the same discipline. Ordinary logs alone are not an immutable audit journal.
A relevant evaluation would lose responses at different stages and examine the observed effect, retained intent and subsequently authorised decisions. Simulation provides bounded evidence for that contract; a real deployment would require qualification of the connector and its actual guarantees.
The Swarm repository makes this architecture work examinable. For critical processes, the decisive questions remain: what do we know about the effect, and what evidence justifies trying again?