# What Does Done Even Mean? Agents and Paperclip's Liveness Model - Dotta, Paperclip AI Engineer ยท 2026-07-12 Dotta, creator of Paperclip, argues that "done" for agents must be a structured claim bundle rather than a boolean checkbox, as agents produce more work than humans can verify. He introduces Paperclip's Liveness Model which balances liveness (keeping work moving) with verification (human review) through three invariants: productive work continues, only real blockers stop work, and infinite loops are bounded. The model uses explicit task transitions, first-class blockers, interactive human approvals, watchdogs (goal-enforcing agents), and separation of verifier from author. Dotta advises defining "done" with artifact, evidence, rubric, owner, and next action, and providing agents tools to verify their own work. The episode presents a protocol for agentic work that avoids approval theater and enables safe delegation. ## Questions this episode answers ### How does Paperclip balance the speed of AI agents with the need for human verification? Dotta explains that agents can easily overwhelm human reviewers, creating 'verification theater' if every output requires sign-off. Paperclip's liveness model aims to keep work moving (liveness) without sacrificing quality (verification). It achieves this through clear task state transitions, explicit blockers, audit trails for human decisions, and watchdogs that ensure goals are met. The system separates the act of verifying from authoring, often using different AI models, and routes reviews based on risk, so work isn't stalled by every check. [2:30](https://aie.addtry.com/87873cea-3f2f-4d1f-9edc-f68b54801ee5?t=150000) ### What is a watchdog in Paperclip and how does it help with agentic work? A watchdog in Paperclip is a 'maximizer mode' agent given a goal that enforces other agents to continue working until that goal is achieved. It acts harness-agnostically, meaning it can coordinate tools like Py, OpenClaw, Hermes, or Claude Code consistently. This ensures that even when individual tasks might stall, a meta-agent keeps overall progress moving, preventing infinite loops and ensuring liveness, while still allowing for human approvals and verifications within the workflow. [4:34](https://aie.addtry.com/87873cea-3f2f-4d1f-9edc-f68b54801ee5?t=274000) ### What does Dotta mean by treating 'done' as an object instead of a boolean? Dotta advises that when agents claim a task is done, it's not a single true/false signal but a bundle of claims. Instead of a checkbox, teams should treat done as an object composed of: the artifact produced, the scope of the work, the rubric or standard applied, the evidence of completion, who verified it, who authorized it, any remaining risk, and the next action. This forces agents to distinguish and provide specifics for each component, making the completion claim verifiable and actionable for downstream processes. [5:22](https://aie.addtry.com/87873cea-3f2f-4d1f-9edc-f68b54801ee5?t=322000) ## Key moments - **[0:00] The Setup** - [0:29] Agents can now produce more code and documentation faster than any human can verify, leading to unverifiable work backlogs. - **[0:46] Bundle of Claims** - **[1:45] Verification Theater** - [1:45] Human verification at scale becomes 'verification theater,' where sign-offs fail to ensure actual quality. - **[2:30] Liveness vs Review** - [3:00] If you have tasks that are completely alive with no approvals, then what you get is this classic AI slop. - **[3:28] Three Invariants** - [4:04] Three invariants for agentic work: productive work continues, only real blockers stop work, and infinite loops are bounded. - **[5:05] Done as Object** - [5:22] Stop treating 'done' as a boolean and treat it more like an object. - **[6:05] The Checklist** - [6:05] To get 100x more work done, define what done means, separate verifier from author, ask agents to provide evidence, and maintain a clear chain of custody. - **[6:40] Chain of Custody** ## Speakers - **Dotta Bippa** (guest) ## Topics Autonomous Agents ## Mentioned Claude (product), Codex (product), Hermes (product), OpenClaw (product), Paperclip (product), Py (product) ## Transcript ### The Setup **Dotta Bippa** [0:00] An agent opens a pull request, it passes the tests, it updates the documentation, it closes the issue and comments, "Looks done to me." But is it actually done? Is it done enough to merge? Is it done enough to deploy? Is it done enough to announce to your customers? These are fundamentally different operational claims, and most agent systems just flatten it to a single green checkmark. I'm Dotta, I'm the creator of Paperclip, and I'm going to give you some hard-earned lessons that we've learned in creating Paperclip's Liveness Model. What does "done" even mean? Here's the thing: programming is solved, and agents can now produce more code and documentation faster than any human can ever verify. And this actually gives us a new failure mode: agents can actually create more work than humans have time to verify. So we need a way to verify that our agents are done, more than just letting them check a checkbox. Done doesn't mean that an agent just changed the status of a task being done. Saying that something is "done" is actually a bundle of claims. ### Bundle of Claims **Dotta Bippa** [0:58] You're saying that an artifact was produced, that you have evidence that the task is actually complete, and you have a rubric in which you can verify against. You know exactly who the owner is for the next step, and you know exactly what the next step is. There's different levels to how "done" something is. The producer might claim something is complete, but you need to have a reviewer, another party that looks at it and finds no obvious issues. You want to verify and make sure that the evidence actually meets a specified standard. You want to make sure that a person who is authorized to approve it actually approves that the work is done. And you want to make sure that there's somebody who actually stands behind the decision. And ideally, what you want is that the outcome has actually survived real-world conditions. Because exhaustive human verification fails at high volume. You might be able to verify a few tasks per day, but essentially, if you have humans verifying all the tasks and they have to sign off on it, eventually what you just get is a form of verification theater. ### Verification Theater **Dotta Bippa** [2:04] What you need is a protocol for defining how tasks actually progress through a system. You want to make sure that tasks are always kept moving, but they don't get stuck into invalid states. You need a control plane that actually has the execution of the tasks being tied to specific contracts and constraints about what the system will do, and what agents it will hand off your next task to. ### Liveness vs Review **Dotta Bippa** [2:30] Because really what you're trying to play against is this idea around keeping work moving, but also having it verified. When a task has been reviewed by a human, you get the assurance that it's correct, but having a human verify it means that the task is dead in its tracks. You also want to keep liveness. Liveness means that the work is continuing with no blockers. And you're always trying to keep these two things in balance. If you have tasks that are completely alive with no approvals, then what you get is this classic AI slop, because you're producing a lot of things with kind of no quality control, and it's worse than creating nothing after a long period of time. But if you have pure review, then you have this enormous review queue where humans can't actually review it by hand anyway. These agents will be creating far more than you can ever actually review, and so you have to find a way to tease apart the bundle of claims that are involved in saying a task is done. With Paperclip, we have a number of mechanisms to keep this going. You might think that you can easily just write a for loop over your task manager and have your agents work, but quickly you'll find that falls apart. ### Three Invariants **Dotta Bippa** [3:39] As soon as you start integrating task dependency trees, blockers, multiple agents, idempotent checkouts, like locks on checkouts, you find that this tension between liveness and verification actually gets quite complicated. There's really three invariants that are extremely important when you're thinking about what you want out of a control plane for your agentic work. 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. In Paperclip, we have built a number of mechanisms to deal with this problem. So for example, every time you have a task, there's clear transitions to what the next state could be. We have first-class blockers between tasks, and the control plane enforces those blockers. We have moments of interactive human approval where human choices leave an audit trail. You can set reviewers and approvers on tasks explicitly, meaning when this task completes, another agent can review it. We also have the idea of watchdogs, which is this maximizer mode, which says, "Try as hard as you can to make sure that this happens." When you have a watchdog, it's another agent who is given a goal, and it enforces that all of your agents continue to work until that goal has been achieved. The important thing here is that the watchdog within Paperclip is harness-agnostic. You can use it with Py, OpenClaw, Hermes, Claude Code, Codex, whatever you're using. You have one consistent interface for ensuring that goal is complete. So one of the best pieces of advice we have is that you stop treating "done" as a boolean and treat it more like an object. ### Done as Object **Dotta Bippa** [5:22] This isn't specific to Paperclip; it's just advice on how you think about what is done. Humans automatically paper over these details, but when we're building agentic systems, it's important that your agents can distinguish between the different pieces of what they're claiming when they say something is done: the artifact that they're saying is complete, the scope, the rubric or the standard, the evidence that it's done, who verified the work, who has the authority to sign off on the work, and what risk might be left, and really what's the next action going to be. So you want to make sure that when you define "done," it's not just a checkbox. So if you want to get 100 times more work done, you should steal this checklist. You need to define exactly what does "done" mean for this task. ### The Checklist **Dotta Bippa** [6:05] You definitely want to separate the verifier from the author. Often this means you're using a different model. So if you're coding using Claude, have Codex verify. You want to ask your agents to provide evidence. Don't just ask them to say, "Is this done?" but give them the tools they need to verify that the work is done. Write the code to have the custom browser harness. Write the code to take the screenshots. Make sure they have access to a browser. Make sure that they have custom agent hooks or custom agent tooling to actually run through and click the buttons and try it out themselves and verify that the work is truly done. Make sure you have a clear chain of custody, that every agent knows that as soon as they're done, who they're supposed to give the work to next. It can be easy to just fire off a single line instruction and vibe with whatever comes back. ### Chain of Custody **Dotta Bippa** [6:55] But if you have serious work that you're accountable for, it's very important that you define what "done" really means in as much detail as possible, and that you have a structure for your agents so that way they can verify that all of the claims that are involved with something being done are actually met. Thank you. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.