What keeps work from disappearing or colliding
Paperclip's normal task-to-heartbeat path assumes that execution can be admitted, run, and recorded cleanly. This chapter examines the harder cases: two execution paths competing for one task, a future wakeup that must survive a restart, and an apparently successful run that leaves no visible progress. The practical judgment is whether an open task has an accountable next path—not whether the system can claim that every failure has been healed.
The symptoms are easy to confuse. Duplicate work may look like an agent mistake when the deeper cause is missing ownership. A repeated run may look like persistence when the deeper cause is a status decision that never converges. A task that survives a database restart may still lose its workspace or provider process. Paperclip addresses these problems with several connected mechanisms rather than one universal retry switch.
The collision symptom: two paths want one task
Imagine an issue assigned to an engineering agent. A timer wakes the agent at the same moment that a user comment requests attention. Without a shared ownership rule, both triggers can start work against the same issue. Each run may read an apparently available task, create a different workspace change, or post a different interpretation of the result. The damage is not limited to duplicated tokens. The organization loses a reliable answer to who owned the next decision.
Paperclip's atomic checkout is the root mechanism for this symptom. A checkout validates the company and agent, checks pause holds and unresolved blockers, confirms that the issue is in an expected status, and tests whether the assignee and execution lock are compatible with the claimant. If those conditions hold, one guarded update sets the assignee, checkout run, execution run, status, and start time together. If another path wins the race, the losing request receives a checkout conflict rather than quietly acquiring a second owner.
The important idea is not the database syntax. It is the ownership decision. A task can be visible to many agents, but one active execution path owns the authority to move that task forward. The same run can retry its own checkout without producing a false conflict. A later run can adopt a stale lock only when the previous run is terminal or missing, or when another guarded condition establishes that adoption is safe. This prevents a fresh process from assuming ownership merely because a previous process is inconvenient to find.
Single ownership does not mean that the task cannot involve several agents. Collaboration can be represented with child tasks, comments, blockers, or delegated work. It means that the organization does not use simultaneous ownership of one issue as its default collaboration mechanism. The distinction makes the work graph more legible: one issue has a current owner, while related issues and comments show how other people or agents contribute.
What a checkout conflict actually diagnoses
A checkout conflict is not one diagnosis. It can mean that another run already owns the task, that the issue has moved out of an eligible status, that a blocker or pause hold prevents execution, or that the stored lock points to an earlier run whose state has not yet been safely resolved.