# Delivered, accepted, merged, deployed: four facts your tracker calls Done > Source: > Published: 2026-08-26 06:40:23+00:00 Most issue trackers have a column called "Done." It is doing far too much work. "Done" is quietly standing in for at least four separate facts, each with a different owner, a different moment, and a different failure mode: When a workflow collapses these into one status, it doesn't make the process simpler. It makes the process *unable to describe what actually happened*. And you notice the missing vocabulary at the worst possible moment, usually in an incident channel at 6pm. Each of the four facts can be true while the others are false. All of these are real states: `main` . `main` last shipped on Thursday. It is Tuesday.A single "Done" column cannot express any of these. So teams invent shadow vocabulary to compensate - "done done", "really done", "done but not shipped", a comment thread, a Slack message that scrolls away. That shadow vocabulary is a symptom. The status model is missing states the work actually has. Everything above predates AI tooling. But handing work to a coding agent sharpens it considerably, for one specific reason: **an agent will always produce a confident report.** A human who half-finished a task tends to leak signal. They hedge. They say "I think it works but I couldn't test the mobile case." An agent, asked to summarize what it did, generally returns a clean, plausible, well-structured account of having succeeded. That report is a genuinely useful artifact - but it is *evidence*, not a verdict. If your workflow treats "the agent reported completion" as equivalent to "the task is complete," you have wired a system where the party doing the work also certifies the work, and the certifying party is the one component in the loop that is structurally incapable of expressing doubt about its own output. That is not an argument against agent-run tasks. It is an argument for keeping delivery and acceptance as two separate events with two different owners. The practical version is not heavy. It's mostly about naming the transitions honestly: **Delivery is a report, not a verdict.** Whoever performed the work - human, agent, or the pair - reports what happened, what evidence exists, and what they could not verify. Ideally the "what I could not verify" section is mandatory, because it is the section that actually carries information. **Acceptance is a decision by someone accountable for the outcome.** They can accept, send it back to the runner, or reopen it. Crucially they must be able to *judge* the work. If nobody in the loop can distinguish correct output from confidently wrong output, acceptance is theater, and you've distributed risk rather than work. **Merge and deploy stay their own facts.** They're usually visible in tooling already; the mistake is letting either one imply acceptance. A revert is a normal event, and a status model where "deployed" is terminal makes reverting feel like failure rather than routine. **Stop conditions are defined up front.** The task should say what to do when authority or evidence is missing. Both a human and an agent should be able to stop and escalate rather than guess. An agent that hits an ambiguous requirement and picks an interpretation has made a product decision nobody delegated to it. You don't need new tooling to get most of the value. Try this on your next handed-off task: That last one is the whole thing, really. Everything else is elaboration. I work on [Wagglet](https://wagglet.com), where this separation is built into the task lifecycle - the participant who ran the task reports it, which moves the task to Delivered, and an authorized reviewer separately accepts it, sends it back, or reopens it. The full five-stage model is written up at [how it works](https://wagglet.com/how-it-works), and the handoff mechanics are in the [task handoff docs](https://wagglet.com/docs/task-handoff). Curious how others handle this: does your tracker distinguish delivered from accepted, or did your team also end up inventing "done done"?