AI Engineer World's Fair 2026
What Does Done Even Mean? Agents and Paperclip's Liveness Model - Dotta, Paperclip
Read the talk
What Does Done Even Mean? Building Liveness into Agent Work
A passing pull request is only one kind of completion. Paperclip’s liveness model separates evidence, approval and ownership so agent work can keep moving without losing accountability.
From a talk by Dotta
Before you start: Familiarity with pull requests, automated tests and coding agents is helpful; no prior Paperclip experience is required.
A green check mark hides different claims
An agent opens a pull request, passes the tests, updates the documentation, closes the issue and comments, “Looks done to me.” Is it ready to merge? Ready to deploy? Ready to announce to customers? Those are different operational claims, even if the task manager represents all of them with one green check mark.
Dotta, creator of Paperclip, introduces the problem with the provocative premise that “programming is solved.” His practical concern is the verification bottleneck: agents can produce code and documentation faster than people can check them. Generating another completed task can therefore create more work for the human responsible for deciding whether to trust it. A checkbox does not resolve that imbalance.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Completion has contents and levels
Done is a bundle of claims. An artifact exists; evidence supports its completion; a rubric defines what completion means. The bundle also includes the owner of the next step and the action that owner should take. Without those last two pieces, finishing one agent’s work can leave the overall task stranded.
The strength of the claim also matters. Dotta moves through progressively stronger forms of assurance:
| Level | What it establishes |
|---|---|
| Producer claim | The author says the work is complete. |
| Independent review | Another party finds no obvious issues. |
| Verification | Evidence meets a specified standard. |
| Approval | An authorized person signs off. |
| Accountability | Someone stands behind the decision. |
| Real-world outcome | The result survives actual conditions. |
These levels answer different questions. Finding no obvious issues does not itself establish that a standard was met, and meeting a standard does not identify who has authority to approve the result. Ideally, the outcome eventually earns confidence through real-world use—but exhaustive human verification cannot support arbitrarily large volumes of agent work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep work moving without abandoning verification
Requiring a human signature on every task does not make the verification bottleneck disappear. As volume grows, sign-off can become a ritual rather than a meaningful check. The alternative needs a task-progression protocol: rules that move work forward while preventing invalid states. A control plane connects execution to those contracts and constraints, including which agent receives the next handoff.
Human review supplies assurance, but waiting for it pauses progress. Dotta describes liveness informally as work continuing without blockers. The orchestration problem is to balance that forward movement with verification:
- Unrestricted execution: Agents keep producing, but without approvals or quality control the output can accumulate into work that is worse than having produced nothing.
- Pure review: Everything waits for inspection, creating a queue that people cannot realistically clear.
Separating the claims inside completion makes it possible to reason about what must be checked before the next step, instead of routing every result through the same undifferentiated approval gate.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A task loop needs enforced rules
A loop that reads tasks and asks agents to work on them looks sufficient until tasks depend on other tasks. Dependency trees introduce blockers; multiple agents introduce coordination; idempotent checkouts and checkout locks introduce ownership constraints. These details make continued execution and meaningful verification a control-plane problem.
Dotta identifies three invariants for that control plane:
- Productive work continues. The system keeps useful execution moving.
- Only real blockers stop work. A halt must correspond to an actual impediment.
- Infinite loops are bounded. Attempts to make progress cannot repeat without limits.
Together, these requirements rule out both an orchestration system that silently stalls and one that keeps agents busy indefinitely without achieving anything.
Paperclip’s mechanisms give those requirements concrete places to act. Tasks have explicit allowed transitions. Dependencies are first-class blockers enforced by the control plane. Interactive human approvals leave an audit trail, while reviewers and approvers can be assigned explicitly so that finishing the producer’s step can hand work to another agent for review. The handoff becomes part of the task’s structure rather than something the producer must improvise.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Watchdogs supervise a goal across harnesses
A watchdog adds goal-directed supervision. Dotta describes another agent receiving a goal and pushing the working agents to continue until that goal is achieved, calling this “maximizer mode.” The useful distinction is between an agent finishing its local assignment and a supervisor checking whether the larger goal still needs work. This is a supervision objective, not a guarantee that every goal can be achieved.
The watchdog is intended to be harness agnostic. Dotta names Pi, OpenClaw, Hermes, Claude Code and Codex as possible agent environments beneath the same supervisory interface. The control plane can express a consistent goal-completion contract without requiring every worker to use the same harness.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Represent done as an object
Replace the completion Boolean with a completion object. This recommendation applies beyond Paperclip. Humans often fill in missing context implicitly; agents need to distinguish the artifact, the scope of the claim, the standard, the evidence, the verifier, the sign-off authority, the remaining risk and the next action.
For the opening pull request, a completion record could look like this. The assigned roles and rubric make the example concrete: the producer has reported tests and documentation complete, while independent verification and merge approval remain pending.
json
{
"artifact": "pull request",
"scope": "ready for merge review",
"rubric": [
"tests pass",
"documentation is updated",
"independent review finds no obvious issues"
],
"evidence": [
{ "claim": "tests pass", "reportedBy": "author" },
{ "claim": "documentation updated", "reportedBy": "author" }
],
"verifier": {
"owner": "review agent",
"status": "pending"
},
"signOff": {
"authority": "maintainer",
"status": "pending"
},
"remainingRisk": [
"independent verification is incomplete",
"deployment readiness is not established"
],
"nextAction": {
"owner": "review agent",
"action": "inspect the changes and supporting evidence"
}
}
The record preserves the producer’s work without upgrading it into approval. It also gives the next agent a specific assignment. A single done: true cannot express those distinctions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give independent verifiers the tools to check
Dotta introduces his practical checklist with an aspiration to get a hundred times more work done, rather than a measured productivity result. The procedure starts by defining completion for the particular task:
- Specify the completion standard. Decide exactly what the task must establish.
- Separate the verifier from the author. Dotta suggests using a different model or agent system—for example, Claude writes the code and Codex verifies it.
- Require evidence. Ask the agent to supply support for its claim, rather than simply asking whether it is done.
Evidence requires tools. Build the custom browser harness, provide screenshot capture and give the verifier browser access. Add agent hooks or tooling that let it click buttons and exercise the result itself. A verifier that can inspect actual behavior has something more substantial to evaluate than the author’s description of what should work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make the next owner explicit
The final requirement is chain of custody: every agent should know who receives the work immediately after its own step finishes. In the pull-request example, producing the change leads to review; the pending review and approval remain visible rather than disappearing when the author closes the issue.
A single-line instruction followed by acceptance of whatever comes back leaves too much implicit for work someone must answer for. Define completion in enough detail that the agents can check each claim, and give them a structure that carries evidence and responsibility through the handoff. The task is ready to advance when the claims required for its next step have been met.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Open-source agent orchestration platform with task ownership, execution locks, approvals, budgets and setup instructions.
Updates since the talk
- Paperclip execution semanticsDocumentation
Current contracts for blockers, waiting paths, task watchdogs and recovery when assigned work stops progressing.
- Paperclip implementation specificationDocumentation
State machines and authority rules connecting task execution, review, approval and recovery.
Guide to connecting agent runtimes through built-in adapters, commands, webhooks and external plugins.
Read the complete timestamped transcript
- 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?
- 0:11
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 check mark.
- 0:21
I'm Dotta, I'm the creator of Paperclip, and I'm gonna 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.
- 0:39
And this actually gives us a new failure mode, is that agents can actually create more work than humans have time to verify. And so we need a way to verify that our agents are done more than just letting them check a checkbox.
- 0:50
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. You're saying that an artifact was produced, that you have evidence that the c- task is actually complete, and you have a rubric in which you can verify against.
- 1:07
You know e- exactly who the owner is for the next step, and you know exactly what the next step is.
- 1:14
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.
- 1:23
You wanna verify and make sure that the evidence actually meets a specified standard. You wanna make sure that a person who is authorized to approve it actually approves that the work is done.
- 1:34
And you wanna 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.
- 1:49
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, you...
- 2:00
eventually what you just get is a form of verification theater. What you need is a protocol for defining how tasks actually progress through a system. You wanna make sure that tasks are always kept moving, but they don't get stuck into invalid states.
- 2:16
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.
- 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.
- 2:46
You also wanna 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
- 3:05
it's worse than creating nothing after a long period of time. But if you have pure review, um, then you have this enormous review queue where humans can't actually review it by hand anyway.
- 3:17
These agents will be creating far more than you can ever actually review, and so we have to find a way to tease apart the bundle of claims that are involved in saying a task is done.
- 3:27
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.
- 3:39
As soon as you start integrating task dependency trees, blockers, multiple agents, idempotent checkouts, like l- locks on checkouts, you find that this tension between liveness and verification actually gets quite complicated.
- 3:55
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 wanna ensure that productive work continues, you wanna make sure that only real blockers stop work, and you wanna make sure that infinite loops are bounded.
- 4:11
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.
- 4:23
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.
- 4:41
We also have the idea of watchdogs, which is this maximizer mode, which says, um, "Try as hard as you can to make sure that this happens." When you have a watchdog, it's another agent, um, who is given a goal, and it enforces that all of your agents continue to work until that goal has been achieved.
- 4:58
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.
- 5:15
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. This isn't specific to Paperclip, it's just advice on how you think about what is done.
- 5:27
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
- 5:45
to sign off on the work, and what risk might be left, and really, what's the next action going to be? So you wanna make sure that when you define done, it's not just a checkbox.
- 5:56
So if you wanna get a hundred times more work done, you should steal this checklist. You need to define exactly what does done mean for this task. You definitely wanna separate the verifier from the author.
- 6:08
Often this means you're using a different model. So if you're coding using Claude, have Codex verify. You wanna ask your agents to provide evidence. Don't just ask them to say, "Is this done?"
- 6:19
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.
- 6:27
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.
- 6:40
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, but if you have serious work that you're accountable for, it's very important that
- 6:58
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.
- 7:11
Thank you.