AI coding agents have a consistency problem. Ask one to add authentication to your project and it'll tell you it's done. Commits made, tests passin...
For further actions, you may consider blocking this person and/or reporting abuse
Strong piece, and CrisisCore's "proof of execution is not proof of correctness" is the line I keep coming back to.
The gap I keep hitting sits one step past the artifact checks: a lot of an agent's most load-bearing claims have no artifact to diff. "I escalated this to the human", "I stopped because it was outside my authority", "I left the migration for review instead of running it" — there's no build or test that proves those happened the way the transcript says. Kalpaka's no-op example is the same root one move earlier: the artifact is present, the claim about what it means is false. Outcome-based gates close proof-of-execution; the residual is proof-of-claim on the decisions that never produce an artifact.
The other one that bites is continuity across a model switch. A boundary the agent honored under one model at step 3 isn't automatically re-checkable under a different model at step 30 — the diff/build/test trail can stay green while the decision provenance silently resets.
We've been treating those two — non-artifact decision/boundary claims, and provenance that has to survive a model swap — as the part outcome-based verification doesn't reach yet, and trying to instrument checks around them specifically. Does your next-release semantic pass touch the decision layer, or does it stay on the code artifacts?
Decision claims can't be checked here, no trace of them in a diff. Transcripts don't count as evidence. The model-switch case is the same: it only sees the finished diff, not the live session. Catching that needs a signed log of what the agent actually did at runtime, then claims checked against it. Out of scope for this tool.
This is the exact boundary we keep hitting. Outcome/diff checks catch "did the output match," but the two you name — decision claims and mid-session model-switch — leave no trace in the artifact, only in the live run. We added a small detector for the model-switch case (it flags the model id changing mid-session, because the inherited context goes quietly unreliable), but that's a tripwire, not the signed log you're describing. "A signed log of what the agent actually did at runtime, then claims checked against it" is the right shape; the hard part is making that cheap and routine rather than another bespoke harness. Transcripts-don't-count is the crux: a transcript is the agent's own narration, so it's self-authored evidence. Curious what you'd accept as the signing authority — the runtime/harness emitting the log out-of-band from the model, or something cryptographic?
this hits home. i’ve had agents swear they fixed a broken hook when the code literally didn’t change — it’s a massive vibe killer when the tool tells you one thing and the browser says another. focusing on the actual outcome instead of the agent’s chat log is the only way i can stay productive. vibe first, polish later, but you’ve got to verify the work actually happened.
Hi Jill, appreciate your comment! Yes, that exact reason is why Swarm skips the chat log and only pushes forward on real git diffs, builds, and test results. Appreciate you chiming in!
that's the right call — git diffs don't lie. i've started doing the same thing manually, just checking what actually changed instead of trusting the agent's summary. if swarm automates that verification layer, that's worth watching. have you listed it on stackapps.app? fits right in with the indie dev tool crowd there.
Strong post. The core move here is shifting trust from transcript to artifact.
An agent saying it changed files, passed tests, or completed the task is not evidence. A real diff, a real build, and real test execution at least move the system back onto something observable.
The next gap, like you pointed out in the comments, is semantic completion. Passing checks proves the branch is less broken. It does not yet prove the branch actually did the thing.
That is the boundary more teams need to get serious about:
proof of execution is not proof of correctness
proof of correctness is not proof of safe merge
and self report is not proof of anything
Still, this is exactly the right direction. Verification has to be outcome based, branch grounded, and hostile to agent narration by default.
The priority shift on the final attempt -- "get something working over something complete" -- is the detail that sticks. It mirrors what experienced developers do under time pressure: reduce scope to protect correctness. Most retry logic just throws the same prompt again.
One thing I'd push on: does the verification layer track whether the RepairAgent "fixes" a build by quietly dropping the feature? I've seen agents pass all checks by producing a no-op implementation. Technically green, semantically empty. Outcome-based verification handles "did it break?" well, but "did it actually do the thing?" is still mostly an open problem.
Correct on the semantic completeness problem. Closest I have to it right now is verifyExpectedOutputs, which does term pattern matching against diff. It could definitely be bypassed by an agent giving a technically present, but behaviorally empty implementation.
In the next release, I'm thinking about adding a semantic verification pass. Small, seperate, agent that reviews the final diff against original goal and flags (if it looks like a no op or scope reduction.) Adding it shouldn't be hard at all.
Hi Brad, thank you for the mention and the great article. I‘m Arne, one of the Emdash founders and wanted to state that Emdash is not „local-only“ - we allow you to connect to any remote server via SSH and our users love it.
Arne
Good to meet you Arne and thanks for the clarification on this. I have edited my post to better state the true state of things at this time. Appreciate the heads up. I also took out the direct references to similar tools. Naming them specifically wasn't intended. We address two different areas and its not right to call anyone out like that. Swarm Orchestrator is a CLI-first verification and governance layer with no dashboard or UI at all. It's built purely for native CI execution and outcome-verified gates inside pipelines, not for interactive desktop workflows. Different tools for different needs. Appreciate the comment and hope my edits are sufficient!
Strong agree on the core claim, and the verification table is the right shape — re-running build and test against the branch is strictly better evidence than anything the agent narrated, and for gating a merge it's the correct answer.
One distinction I'd draw inside "transcript parsing", because I think two very different things are wearing the same name:
Parsing the agent's prose as evidence. The verifier reads "all tests passing" and treats the sentence as proof. You're completely right that this is worthless — the completion language is generated regardless of state, so you're grading the homework with the homework.
Parsing the transcript's tool results. The same file also contains what actually executed: the command, and the real exit code the harness recorded coming back. That isn't self-report, it's the harness's record. You can then use it against the prose — extract every claim, extract every command's real exit code, and report the ones that contradict.
The difference matters because they fail in opposite directions. The first over-trusts. The second is how you catch the first lying.
Ran that over my own 51MB session: 743 commands, 79 checkable claims, 2 flatly contradicted by their own exit codes. The more interesting bucket was 11 claims whose only evidence was a piped command —
pytest -q | tail -3reports tail's status, not pytest's, so it's ~always 0. A verifier watching exit codes without noticing the pipe gets a confident green.Where I'd concede your approach wins outright: yours is prospective and re-executes, so it catches "code compiles but is wrong", which no transcript can. Mine only works on things that already ran — its actual niche is auditing sessions that already happened (nobody's re-running last Tuesday's agent run) and measuring how often this happens rather than blocking it.
Relevant data point if useful: a June benchmark ran 45 failing Python suites through an agent; it reported all 45 fixed, hidden tests showed 26 were. 42% false-positive rate on the self-assessment alone.
Tool's here if you want to point it at a session: github.com/aurumflux20/coherence (Apache-2.0, no signup). Genuinely curious whether Swarm Orchestrator's
transcriptcheck is the prose kind or the tool-result kind — if it's the latter, we've independently landed on the same idea from different ends.