An agent can produce a convincing result and misread the state of its own work. In a multi-agent process, a result can also be correct when checked yet no longer match the delivered candidate. This is a central reason for my deterministic engine design in Swarm: making preconditions and transitions explicit during execution.
Cursor’s research on long-running autonomous agents informed this work, including separation of planning from execution and coordination difficulties. The mechanisms chosen for Swarm are my architecture decisions.
When green no longer applies to the candidate
Consider a development task. One agent produces V1 and the identified checks pass. Another agent then fixes a detail, creating V2. A system retaining only a “tests passed” label may allow the next step using a result that no longer concerns the current files.
This confusion can admit a regression or incorrect configuration into delivery. It requires neither a sophisticated attack nor bad intent: a legitimate edit can make evidence stale. The issue is the binding between the observed result and the object being assessed.
A check qualifies identified inputs; it does not automatically qualify their next version.
The process must retain the attempt, commands actually executed, results and required artifacts. Before the next transition, it must verify that they still correspond to the relevant candidate and policy. A broken binding requires the affected checks to be repeated, while retaining V1’s history.
What the engine can check
In Swarm’s current Rust sources, evidence verification compares the current attempt, expected controller and policy digest. It examines configured controls, their execution, success and required artifacts. Missing or inconsistent material does not become empty success.
These checks cover a defined contract. They do not prove that the control list is sufficient, that tests cover every defect or that undeclared dependencies were observed. A deterministic engine can consistently enforce an insufficient rule.
In human mode, successful checks remain distinct from approval: a state awaiting a human must not be presented as acceptance. In automatic mode, applicable control and review requirements still need to concern the same candidate.
A graph should explain the blocker
The graph is useful when it connects prerequisites, the task, required evidence and the reason for refusal. Operators must distinguish work not launched, a failed check, stale evidence and a pending decision. Recovery then brings a new condition or new evidence; it is not repeating an unchanged action until a green state appears.
This visibility does not expose every internal provider activity. Unobserved consumption or cost must remain unknown. Nor does the presence of the engine establish operating system or network confinement.
What would establish delivery?
For this case, the expected result is specific: preserve V1’s historical success, refuse improper reuse for V2, then assess V2 with the necessary checks. Local verification remains distinct from evidence about the binary actually deployed.
In Swarm, agents analyse, propose and perform work; the engine checks defined conditions at boundaries it controls; humans retain decisions assigned to them. Quality depends on all three responsibilities and on recognising their limits.