A private automation platform runs agents in the background, with retries, cancellation, recovery and sessions that persist between runs. The specification described how to run agents well, and it was a competent list. It did not describe how to decide that an agent's work had actually been done. Every reliability feature on the list made that decision by asking the agent, and an agent's account of its own run is the least reliable evidence on the platform.
An agent's report on its own work is written by the thing being judged.
An agent is a language model running in a loop. It reads a task, decides on an action, calls a tool such as a file editor or a shell, reads the result, and repeats until it decides it is finished. When it stops, it produces a final message describing what it did, and if it runs inside a wrapper process, that process ends with an exit status. Together, the final message and the exit status are the agent's self-report. Most orchestration software treats them as the outcome of the run.
The self-report is weak evidence for structural reasons. The final message is generated text, produced by the same model that did the work, and it describes what the model believes or intended, which can drift a long way from what happened on disk. The exit status reports how the process ended, and a process can end cleanly after an upstream service refused its requests. Worst of all, the failures that matter most tend to destroy the means of reporting them accurately. A session cut off by an output limit loses the context that would have said what was left undone. The component that failed is the one being asked whether it failed.
The alternative is independent evidence: facts about the world after the run that the agent did not author. Files exist or they do not. Tests pass or they fail when the platform runs them itself. Version control shows a diff or it shows nothing. The same thinking applies to the machinery around the agent. A job queue has to decide what a silent worker means, and it either assumes the worker died and hands the job to someone else, risking the work being done twice, or waits for the worker to release it, risking a job held by a worker that will never return. Cancellation and budget controls each have a failure direction too. Knowing those directions is part of knowing what the platform's reports mean.
Ordinary events show the gap.A run that hits a rate limit can return a success status with a zero exit code. A session lost to an output limit leaves no files and no handle to resume from. A checkpoint can miss changes made through the shell, outside the tool it watches. Each one produces a confident, well-formed account of work that did not happen, and a platform built to display that account will display it faithfully.
Reliability features multiply whatever signal they are given.
Retries, recovery and status displays exist to make a platform dependable, and each of them starts by asking whether the last run succeeded. When the answer comes from the run itself, a false success flows straight through. Retry sees nothing to retry, recovery sees nothing to recover, and the status page turns green. The more reliability machinery a platform has, the more confidently it presents the false claim.
The second pattern is inherited defaults. Queues, budget controls and cancellation each have a behaviour under failure that someone else chose. Those choices are reasonable for some workload. Whether they suit an agent that runs for a long time, spends money as it goes and can be killed partway through is a separate question, and it is usually answered for the first time during an incident.
- Rate limit hits mid-runthe provider stops serving requests
- Wrapper exits cleanlysuccess status, zero exit code
- Retry sees successnothing to retry
- Recovery sees successnothing to recover
- Dashboard shows donea faithful display of a false claim
The reflex, and the fix.
Build the orchestration the specification describes
It is a complete and competent feature list, and every item on it is genuinely needed.
Retry, recovery and status all read the agent's report of itself. Built on that, the platform records claims, and its reliability features act on a wrong claim as diligently as on a right one, which amplifies it.
Accept the work, not the claim
An independent check between the run and its acceptance, and a milestone signed off by drills that break the system on purpose.
A definite meaning for the word done: files exist, tests pass and a diff is present.
The report is most likely to be wrong at exactly the moments it matters, so acceptance rests on evidence the agent did not produce.
An independent check between running and accepting
After a run ends, the platform looks for evidence in the workspace: the expected files, tests that pass, a diff that exists. The check never consults the agent's opinion of its own run.
Six drills as the acceptance criteria
Kill the worker. Hit the token cap. Resume a task and watch the budget. Cancel a run that does not heartbeat. Rate-limit a run partway through. Change a file through the shell where checkpointing cannot see it. A milestone is accepted when these pass, and a successful demonstration does not count.
Knowing which way the queue fails
The two common database-backed queues fail the kill-the-worker drill in opposite directions. One re-runs a job after a fixed interval even when its worker is alive and busy. The other holds a dead worker's job for hours. Neither default is wrong, and the platform has to know which one it has.
Budget caps that survive a resume
A cost cap that resets when a task is resumed or continued stops working precisely when a task goes back for changes, which is when the cost accumulates. The cap has to belong to the task, across every resume.
Cancellation that can actually arrive
Cancellation is delivered only to work that reports in. A wrapped process that never sends a heartbeat cannot be cancelled, whatever the dashboard offers, and the drill makes that visible before anyone relies on the button.
What each choice cost, and what it bought.
APutting an independent check in the acceptance path
Trusting the run's status is free and immediate. An independent check means deciding, per kind of task, what evidence of completion looks like, and it adds a step between finishing and accepting. That cost is real and recurring. What it buys is that done means something the platform can stand behind. The alternative leaves every reliability feature acting on claims, so the platform becomes more confident without becoming more correct.
BDrills in place of demonstrations
A demonstration shows the path where nothing goes wrong, and it is what milestones are usually signed off on. The six drills are harder to build, because each one needs a harness that kills a worker, exhausts a budget or throttles a run on cue, and they make milestones harder to pass. In return, the behaviour under each named failure is known before production finds it, and a milestone means the system survives the conditions it will actually meet.
CEstablishing the queue's failure direction
Both common database-backed queues are defensible. One prefers re-running a job too early, the other prefers holding it too long. The cost of finding out is a drill and some reading. The value is that the rest of the platform can be designed for the direction it actually has: a queue that may re-run needs work that tolerates running twice, and a queue that may hold needs something that notices a stalled job. Inheriting the default without knowing it leaves either duplicated work or silent stalls to be discovered later.
DMaking the budget belong to the task
Resetting a cost cap on each session is the simplest implementation, and it is how a cap ends up being a control on the first attempt only. Tying the cap to the task across every resume and continuation costs bookkeeping across sessions. It keeps the cap working in the revision phase, which is where a long-running task does most of its spending.
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
No measured figures are published for this engagement. Outcomes are described qualitatively.
A platform with retries, recovery and cancellation that trusts the agent's account of itself, shows done for a run that was rate-limited and wrote nothing, and cannot cancel the runs that most need cancelling.
Acceptance based on an independent check, a milestone gated on six drills that break the system deliberately, and queue, budget and cancellation behaviour established by testing it.
What it owns, and what it hands to a person.
The drills establish how the platform behaves under six named failures. They do not make the agent correct. The independent check confirms that work was done, and it does not confirm that it was the right work. Those are separate properties and only the first is claimed here. Unattended irreversible actions stay out of scope, and the behaviour of queues and model providers under limits can change between versions, so the drills have to be re-run whenever either is upgraded.
Anywhere one system reports on itself and another acts on that report, the same gap opens. Find independent evidence that the work happened, and accept against that. Establish which way each component you depend on fails by breaking it on purpose, and never inherit its defaults unexamined.
An agent's report of success is produced by the process being judged. Accept work against evidence the agent did not author, such as files, passing tests and a diff.
A clean exit and a success status describe how a process ended. They say nothing reliable about whether the task was done.
Sign off milestones on drills that break the system on purpose. A demonstration only shows the path where nothing went wrong.
Every job queue fails in some direction when a worker dies. Find out which by killing a worker, then design the rest of the system for that direction.
Cost caps and cancellation have to survive the events that test them: a resume for the budget, and a silent process for cancellation.