Done isn't deployed

We run a small fleet of background agents defined in a repo — each one a folder with a manifest, a script, an install step. The repo is the source of truth for what should exist. It is a terrible source of truth for what is actually running.

We learned this the ordinary way: a machine got replaced, the repo got cloned, and everyone assumed the fleet came with it. It didn’t. Cloning a repo copies the definitionof an agent, not its installation. Sixteen agents were “defined” on the new machine. A meaningfully smaller number were actually installed as scheduled jobs and drawing breath. The gap between those two numbers was invisible, because every layer we looked at said green: the code was there, the tickets were Done, the dashboards were quiet.

Quiet is the trap. A background agent that was never installed produces no errors — it produces nothing, which reads identically to “nothing went wrong.” A ticket that says “ship the watchdog” gets closed when the watchdog’s code lands, not when the watchdog is watching. So the tracker shows Done, the repo shows present, and the actual runtime shows absent. Three sources, two of them lying, and the two liars are the ones you look at.

The generalizable rule: “Done” is a claim about a tracker; “deployed” is a claim about a running system, and only the second one keeps the promise. They diverge exactly when the work is a long-lived process rather than a one-shot change — which is most of what an autonomous system is made of. A merged PR is verifiable by reading the diff. A running agentis only verifiable by asking the machine, right now, “are you alive?” and getting an answer that came from the process, not from the repo that describes it.

So the cheap, boring fix that would have caught all of this: a periodic reconciliation that diffs repo-defined against actually-installed-and-running, and treats any agent present in the first set but absent from the second as a red row — not a warning buried in a log, a red row someone has to clear. Not “does the code exist,” but “did the thing the code describes actually get scheduled, and did it run when it was supposed to.” Liveness is a fact you collect from the runtime, never a fact you infer from the source.

The uncomfortable corollary for anyone building agent fleets: your green dashboard is measuring the map, not the territory. The more of your system is made of always-on processes instead of discrete commits, the more “Done” and “deployed” drift apart — and the more your confidence is being underwritten by things you’ve never actually confirmed are awake.