# What Does Done Even Mean? Agents and Paperclip's Liveness Model Dotta, Paperclip | AI Engineer World's Fair 2026 | 07:14 Source: https://www.youtube.com/watch?v=7P0elyLIxXo Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/what-does-done-even-mean-agents-and-paperclips-liveness-model Published: 2026-07-12 Tags: agents, human-in-the-loop, reliability, workflows ## TL;DR - Agent completion is a bundle of claims about the artifact, evidence, verification, ownership, remaining risk, and next action. - Agent systems need to balance verification with liveness, so work keeps moving without allowing unreviewed output or invalid states to accumulate. - Paperclip's control plane uses task transitions, blockers, approvals, audit trails, reviewers, approvers, and watchdog agents to keep agent work progressing toward a defined goal. ## Summary Dotta argues that an agent changing a task to done does not settle whether the work is ready to merge, deploy, or announce. Completion includes an artifact, a stated scope and standard, evidence, a verifier, an authorized approver, ownership of remaining risk, and a next action. Agent systems also need liveness: work must continue unless a real blocker stops it. Too much approval creates review queues and verification theater, while unrestricted production creates low-quality output. Paperclip addresses this with explicit state transitions, dependency blockers, human approval points with audit trails, assigned reviewers and approvers, and watchdog agents that keep pursuing a goal. Dotta recommends treating done as an object, separating authors from verifiers, giving agents tools to produce evidence, and defining a clear chain of custody for every handoff. ## Key ideas ### Completion is a bundle of operational claims [00:35](https://www.youtube.com/watch?v=7P0elyLIxXo&t=35s) Dotta says an agent claiming a task is done should mean more than a status change. The claim includes an artifact being produced, evidence that the task is complete, and a rubric or standard against which it can be checked. It also assigns an owner for the next step and states what that step is. This matters because the same pull request may be ready for review, ready to merge, ready to deploy, or ready to announce to customers. Those are different claims, even when an agent presents them as one green check mark. ### Verification and liveness pull in opposite directions [01:50](https://www.youtube.com/watch?v=7P0elyLIxXo&t=110s) A reviewer can find obvious issues, check evidence against a standard, and confirm that an authorized person approved the work. Human sign-off can also make a task stop moving. Dotta calls continued progress without blockers liveness. Systems with no approval produce a lot of low-quality output, while systems that require people to review everything build a queue humans cannot handle. The control problem is to keep tasks moving while preventing them from entering invalid states. ### A control plane needs three operating invariants [03:53](https://www.youtube.com/watch?v=7P0elyLIxXo&t=233s) Dotta gives three conditions for an agent-work control plane. Productive work should continue. Only real blockers should stop it. Infinite loops should be bounded. In Paperclip, task states have explicit allowed transitions, and dependencies and blockers are enforced by the control plane. Human approval points record choices in an audit trail. Reviewers and approvers can be assigned to tasks so a completed task has a defined handoff and review path. ### Watchdogs keep work pursuing a goal [04:32](https://www.youtube.com/watch?v=7P0elyLIxXo&t=272s) Paperclip includes watchdogs in a maximizer mode. A watchdog is another agent given a goal, with responsibility for pushing the other agents to continue until the goal is achieved. Dotta says the watchdog is harness agnostic, so the same interface can work with Pi, OpenGL, Hermes, Claude Code, or Codex. This gives the system a persistent mechanism for dealing with unfinished work instead of relying on a single agent's completion claim. ### Done should be represented as an object [05:13](https://www.youtube.com/watch?v=7P0elyLIxXo&t=313s) Dotta recommends recording the parts of a completion claim separately. The object should identify the artifact, its scope, the rubric or standard, the evidence, the person or agent who verified it, the authority that can approve it, the risk that remains, and the next action. Humans often fill in these details automatically. Agents need them stated explicitly because a checkbox hides which parts of the claim have actually been established. ### Authors and verifiers should be separated [05:49](https://www.youtube.com/watch?v=7P0elyLIxXo&t=349s) Dotta recommends using a different verifier from the author, which can mean using different models. His example is coding with Claude and asking Codex to verify. Agents should receive tools that let them gather evidence rather than simply answer whether their own work is done. Those tools can include a browser, a custom browser harness, screenshot capture, and agent hooks that click through an interface and test the result. ### Every completion needs a clear chain of custody [06:27](https://www.youtube.com/watch?v=7P0elyLIxXo&t=387s) When an agent finishes, the system should make clear who receives the work next. Dotta warns against firing off a one-line instruction and accepting whatever comes back for serious accountable work. The workflow needs enough structure for agents to check each claim in the definition of done. That structure also makes ownership and the next action visible instead of leaving the handoff to an informal assumption. ## Notable quotes - "Done doesn't mean that an agent just changed the status of a task being done." (00:52) - "Liveliness means that the work is continuing with no blockers." (02:33) - "You want to ensure that productive work continues. You want to make sure that only real blockers stop work. And you want to make sure that infinite loops are bounded." (03:53) - "Stop treating done as a Boolean and treat it more like an object." (05:13) - "You definitely want to separate the verifier from the author." (05:59) ## Tools & references mentioned - Paperclip - Pi - OpenGL - Hermes - Claude Code - Codex ## Who should watch - You are building agent workflows where a completed task needs to move safely into review, deployment, or another handoff. - Your team is choosing between human approval for every task and letting agents run without enough evidence or quality control. - You need a control plane for dependencies, blockers, approvals, watchdogs, and audit trails across multiple agents.