A talk by Dotta (creator of Paperclip) on what "done" should mean when AI agents can produce more work than humans can review. Drawing on Paperclip's liveness model, it proposes treating agent completion as a trust protocol: an artifact meets a stated standard, carries evidence, is verified by the right party, assigns ownership of residual risk, and authorizes the next action — enabling teams to avoid approval theater, route review by risk, and keep agentic work moving. # Channel Identity Observations: Paperclip (Dotta) ## Explicit Self-Description - **Creator-identified product**: Speaker states, *“I'm Dota. I'm the creator of Paperclip”* (transcript self-introduces; name appears as "Dotta" in title). - **Claimed expertise basis**: Positions content as *“hard-earned lessons that we've learned in creating Paperclip's liveness model”* — first-person builder experience, not third-party commentary. - **Company/team framing**: Uses *“we”* throughout (*“the best pieces of advice we have”*, *“we have built a number of mechanisms”*), presenting a team behind the product. ## Intended Audience - **Engineering teams building agentic AI systems**: References integrating agents, task dependency trees, idempotent checkouts, locks, control planes, review queues. - **Tool-agnostic practitioners**: Watchdogs are described as *“harness agnostic. You can use it with Pi, OpenGL, Hermes, Claude Code, Codex”* — audience expected to know these tools. - **People accountable for serious work**: *“if you have serious work that you're accountable for, it's very important that you define what done really means.”* ## Claimed Scope - **Product-specific mechanisms**: Blockers, audit-trail approvals, reviewers/approvers, watchdog agents — all attributed to Paperclip's feature set. - **General advice beyond the product**: Explicitly flags, *“This isn't specific to Paperclip. It's just advice on how you think about what is done”* (treat "done" as an object, not a Boolean). ## Demonstrated Presentation Patterns - **Problem-first framing**: Opens with a concrete scenario (agent closing an issue saying *“Looks done to me”*) before introducing the product. - **Bold assertion hooks**: *“Programming is solved”* used as a provocation to set up the verification-bottleneck argument. - **Named-concept vocabulary**: Coins/uses terms like **liveness**, **verification theater**, **watchdogs**, **control plane**, **AI slop** — signals a thought-leadership/tutorial register. - **Actionable takeaway format**: Ends with a checklist (*“steal this checklist”*) — practical guidance structure. - **Balanced general/tool content**: Roughly half the talk is framework-agnostic advice, half Paperclip-specific features. # Delivery Observations: "What Does Done Even Mean? Agents and Paperclip's Liveness Model" ## Tone - **Conversational but structured** — the speaker uses plain, direct language while walking through an enumerated argument. - **Slightly cautionary framing** — the talk repeatedly warns of failure modes rather than celebrating capabilities: "agents can actually create more work than humans have time to verify." - Occasional **informal filler and self-corrections** appear in the transcript, e.g. "um, try as hard as you can" and "if you have peer review, um then you have this enormous review queue" — suggesting an unscripted or semi-scripted live delivery. ## Vocabulary - Consistently uses **systems/protocol terminology**: "control plane," "invariants," "audit trail," "chain of custody," "item potent checkouts," "harness agnostic," "watchdogs." - Introduces **coined or emphasized concepts**: - "liveliness" / "liveness model" - "verification theater" - "AI slop" - "done as an object" vs. "done as a Boolean" - Names **specific competing tools/models** without hedging: "Pi, OpenGL, Hermes, Claude Code, Codex" and "if you're coding using Claude, have Codex verify." ## Recurring Phrases and Structures ### Rhetorical questioning as an opener - Opens with a cascade of questions: "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?" - Returns to the title question directly: "What does done even mean?" ### Anaphora / repeated stems - Repeated **"You want to..."** constructions to introduce requirements: "You want to verify and make sure...", "You want to make sure that there's somebody...", "You want to ensure that productive work continues." - Repeated **"Make sure..."** in the checklist section: "Make sure they have access to a browser. Make sure that they have custom agent hooks..." ### Enumeration habit - The speaker repeatedly unpacks a single concept into numbered/bundled lists: - "Saying that something is done is actually a bundle of claims." - "There's really three invariants that are extremely important..." - The closing "checklist" of advice items. ## Teaching Habits - **Definitional teaching style** — explicitly defines terms before using them at length: "Liveliness means that the work is continuing with no blockers." - **Contrast framing** — sets up two poles and argues for balance: "you're always trying to keep these two things in balance" (verification vs. liveness). - **Concrete scenario opener** — begins with a vivid agent vignette ("An agent opens a pull request... 'Looks done to me.'") before abstracting. - **Anti-pattern warning** — explicitly tells the audience what not to do: "It can be easy to just fire off a single-line instruction and vibe with whatever comes back." - **Takeaway generalization** — explicitly marks portable advice: "This isn't specific to Paperclip. It's just advice on how you think about what is done." ## Communication Patterns - **Balanced product pitch and general advice** — Paperclip mechanisms are presented ("In Paperclip, we have built a number of mechanisms...") alongside tool-agnostic guidance, with the speaker explicitly flagging which is which. - **Imperative mood for the closing** — shifts from explanation to direct commands: "you should steal this checklist," "you definitely want to separate the verifier from the author." - **Clear signposting of expertise** — establishes credibility once at the start: "I'm Dota. I'm the creator of Paperclip, and I'm going to give you some hard-earned lessons," then does not repeat self-promotion. - **Clean, formulaic close** — ends with a compact summary sentence and "Thank you." ## Uncertainty Notes - Timestamps/segmentation are coarse, so pacing (e.g., pauses, emphasis) cannot be observed. - "Verification theater" and "AI slop" appear only once each; whether they are signature recurring phrases for this speaker cannot be confirmed from this single transcript. - The transcript lists the speaker as "Dota" while the title reads "Dotta" — the spoken name's spelling is uncertain. # Position Record: "What Does Done Even Mean? Agents and Paperclip's Liveness Model" **Speaker:** Dotta (self-identified), creator of Paperclip ## Central Claim: "Done" Is Not a Boolean - Agents can now produce code and documentation **faster than humans can verify**, creating a failure mode where "agents can actually create more work than humans have time to verify." - The speaker asserts, with qualification: "Programming is solved" — offered as a framing premise. - Most agent systems flatten "done" to a single green check mark, ignoring that "done enough to merge," "done enough to deploy," and "done enough to announce to customers" are **fundamentally different operational claims**. - An agent changing a task's status is not verification: "Done doesn't mean that an agent just changed the status of a task being done." ## "Done" as a Bundle of Claims Per Dotta, saying something is done means claiming: - An **artifact** was produced - **Evidence** exists that the task is complete - A **rubric/standard** exists to verify against - A clear **owner** and **next step** are known ### Levels of "Doneness" 1. Producer claims completion 2. A **reviewer** finds no obvious issues 3. Evidence meets a **specified standard** 4. An **authorized** person approves 5. Someone **stands behind** the decision 6. Ideally, the outcome has **survived real-world conditions** ## The Liveness vs. Verification Tension - **Exhaustive human verification fails at high volume**, producing "verification theater." - Pure liveness (no approvals) produces "classic AI slop," which the speaker says is "worse than creating nothing after a long period of time." - Human review gives correctness but stops work — a task is "dead in its tracks." - Liveness is defined as "work continuing with no blockers." - Naive orchestration ("a for loop over your task manager") falls apart once you add dependency trees, blockers, multiple agents, idempotent checkouts, and locks. ## Control Plane Invariants 1. Productive work continues 2. Only real blockers stop work 3. Infinite loops are bounded ## Paperclip Mechanisms (speaker's claims about his own product) - Defined **state transitions** per task - First-class, control-plane-enforced **blockers** - **Interactive human approval** moments with audit trails - Explicit **reviewers/approvers** per task - **Watchdogs**: "maximizer mode" agents enforcing goals until achieved; harness-agnostic (works with "Pi, OpenGL, Hermes, Claude Code, Codex") ## Recommended Checklist - Treat done as an **object**, not a Boolean — artifact, scope, rubric, evidence, verifier, authority, residual risk, next action - **Separate verifier from author** — often a different model (e.g., "if you're coding using Claude, have Codex verify") - Require agents to **provide evidence** via tools: browser harnesses, screenshots, custom hooks, clicking buttons - Maintain a clear **chain of custody** for handoffs - The speaker acknowledges the tension with casual use: "It can be easy to just fire off a single-line instruction and vibe with whatever comes back" — but serious, accountable work requires detailed definitions of done ## Notes on Attribution and Qualification - All product claims (Paperclip mechanisms) are the speaker's own and promotional in nature. - The "steal this checklist" advice is explicitly framed as not Paperclip-specific: "This isn't specific to Paperclip. It's just advice." # Speaker Attribution Record ## Video **Title:** What Does Done Even Mean? Agents and Paperclip's Liveness Model - Dotta, Paperclip **Video ID:** `01a15ca8-aa32-78e9-9878-7c262f6d9c51` ## Speakers | Speaker | Role | Evidence | |---|---|---| | Dota (also rendered "Dotta" in title metadata; transcript spelling: "Dota") | **Creator of Paperclip**; sole presenter | Self-introduction: "I'm Dota. I'm the creator of Paperclip" | - Single-speaker presentation; no guests, narrators, or other participants appear in the transcript. - No curated metadata was supplied beyond the title. ## Role Notes - Speaker speaks on behalf of **Paperclip** (product): "we've learned in creating Paperclip's liveness model." - Framing is partly **promotional/instructional** regarding Paperclip's mechanisms (control plane, watchdogs, blockers, audit trails), though the speaker also offers product-neutral advice: "This isn't specific to Paperclip. It's just advice." ## Referenced Third-Party Tools / Products (mentioned, not endorsed claims by third parties) - **Pi**, **OpenGL**, **Hermes**, **Claude Code**, **Codex** — cited as harnesses/agents compatible with Paperclip's watchdog; also "if you're coding using Claude, have Codex verify." - No cited external sources, studies, or publications. ## Provenance & Availability - **Comments availability:** Not stated in transcript or metadata. - **Cited sources:** None beyond tool names listed above. - **Promotional segments:** Product demonstrations of Paperclip's mechanisms (task transitions, blockers, human approval moments, watchdogs) constitute product-promoting content and are flagged as such. - **Uncertainty:** Speaker name spelling differs between transcript ("Dota") and title ("Dotta"); identity is the same person per context. 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 check mark. I'm Dota. 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, is that 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. 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, you 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 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. 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 liveliness. Liveliness 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 peer review, um 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 we 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. As soon as you start integrating task dependency trees, blockers, multiple agents, item potent checkouts, like locks on checkouts, you find that this tension between liveliness 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, 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. The important thing here is that the watchdog within Paperclip is harness agnostic. You can use it with Pi, OpenGL, 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. 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. 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. 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.