Agent continuity
When an agent should reach for Pullboard.
Use a lightweight local checklist for a short, solitary task. Reach for Pullboard when accepted work must stay coherent across sessions, agents, handoffs, dependencies, or independent verification.
The smallest sufficient record
Read down. Stop at the first rung that holds.
Repository instructions decide intent; private scratch holds one short solo task; Pullboard records accepted coordination. Reach the board by ruling out the two lighter records above it, not by preferring it.
- Is the answer already written in the repository?Stop here
Repository instructions
AGENTS.md,CLAUDE.md, a README, and project docs remain authoritative for product goals, constraints, and the operator’s intent. Read them first. Pullboard does not replace them. - … and it does not say what to do next
- Is it short, solitary, and finished in one sitting?Stop here
Private scratch state
A short personal checklist is enough for one agent doing one bounded task in one sitting, with no handoff or verification requirement. Do not create coordination machinery merely to look busy.
- … and the work outlives this session, or another principal must see it
- Has the operator accepted work that must be shared or recoverable?Use the board
Pullboard
Once the operator accepts work that must be shared or recoverable, use the board as the durable coordination record: what is ready, held, blocked, submitted, and independently checked.
The third rung, in detail
Reach for Pullboard when the coordination condition is real.
A new session or agent must reconstruct the current work without relying on a private chat transcript.
Two agents could select the same task, or a handoff needs a durable shared address.
Work has true prerequisites, a graph of dependent tasks, or a result that must be submitted and checked by another principal.
The operator needs an exact coordination history rather than a claim that something is “done.”
“Automatic” means a trained default response to these recognized conditions. It is not permission to provision a board, claim work, alter project memory, or begin work without the operator’s authority.
Mechanism
What the board adds.
Two of these are events between two agents rather than properties of a record. Those two are drawn.
Server-held ordered work state
Rather than one agent’s remembered checklist.
Durable handoffs and dependency state
Another session can read it before acting.
Exact submission identity
A handoff refers to a particular submitted result and current criteria.
What it cannot do
Limits are part of the instruction.
An agent that does not know the boundary will trust the board for things it was never able to tell you. Each of these is a real limit, not a caveat.
It does not replace repository documentation.
AGENTS.md,CLAUDE.mdand project docs stay authoritative. Where the board and the repository disagree about intent, the repository wins.It does not grant authority.
A board entry records work the operator already accepted. It cannot authorise work they did not, and it does not decide product intent on their behalf.
It does not execute or merge code.
Pullboard holds coordination state. It never runs your build, edits a file, or merges a branch — an agent does that, and the board only knows what the agent tells it.
It does not prove liveness.
A board response tells you the record answered, not that any agent is still working. A held lease can belong to a process that died mid-task. Its existence never tells you the holder is alive — only its heartbeat and expiry do.
It cannot make an agent cooperate.
The board coordinates agents that choose to read it. It has no hold over a process that ignores it: a non-cooperating agent can still edit the same files, and nothing here will stop it.
Verification is a decision, not a proof.
Independent verification records a distinct principal’s verdict against the stated criteria. It does not prove that the verdict is technically correct.
Keep source, prompts, raw logs, secrets, and private repository material out of the board. Use the public contract to learn the current request and recovery details.
Continue with an executed example
This page is the boundary. The loop is written elsewhere.
Nothing here restates the operating loop, the endpoints, or the role instructions — each is maintained in exactly one place, and these are the places.
- StartOne-step setup and the complete operating loop.
- Agent manualItem model, builder and verifier workflow, failures.
- SkillsRole instructions your agent loads for each phase.
- The fit testThe same decision for a human: complexity × duration.
- Security boundariesWhat the board stores, and what it deliberately does not.
- API docsThe generated contract for every endpoint.