One human, many agents: working templates

For the smallest useful version and everyday habits, start with quick-start.md. Use these fuller records when the task needs their detail.

Adapt these to the consequence of the task. Keep small tasks small. A written instruction describes authority; access controls and execution tools must enforce consequential boundaries.

Assignment

Task / owner:
Desired outcome:
Acceptance criteria:
Inputs and pinned revisions:
Writable territory:
Shared resources and their owners:
Allowed actions / explicit exclusions:
Time, compute, or cost budget:
Stop conditions / escalation destination:
Required artifacts and checks:
Independent review or observation:
Done when:

Example assignment (illustrative)

Task / owner: Prepare a self-hosted service upgrade / preparation worker
Outcome: A reviewable candidate that preserves consumer behavior
Inputs: Current revision, target version, dependency list, acceptance checks
Territory: Own worktree and isolated test environment
Authority: Prepare and test; deployment is a separate controlled action
Stop: Unknown data migration, missing recovery path, or budget exhausted
Output: Exact candidate, dependency impact, checks, limitations, recovery plan
Done: Reviewer can reproduce the checks and decide on this exact candidate

Handoff / cold pickup

Task, current owner, and state:
Candidate revision / artifact identity:
Last observed target state, timestamp, and observation method:
Completed work and evidence locations:
Failed checks and unresolved uncertainty:
Current authority, exclusions, and later overrides:
Pending decisions and who can resolve them:
Outstanding jobs and logical operation / attempt identities:
Ownership transfer: released or reclaimed; prior executor stopped or fenced:
Evidence confirming the transfer:
Next executable action:
Tools, environment, and access needed:
Recovery procedure and prerequisites:

Review record

Object reviewed: exact revision, config, artifact, target context
Question the review must answer:
Inputs and checks actually inspected or run:
Independent evidence path:
Meaningful negative control, where appropriate:
Findings and their reproduction paths:
Limitations / checks not performed:
Disposition: accepted for the named purpose / correction / blocked
Reviewer and timestamp:
Changes that invalidate this review:

Deployment grant and result

Task / accountable executor:
Logical operation identity (stable across retries of the same operation):
Attempt identity (unique to this attempt):
Authorized target, candidate revision, config, and migration:
Allowed action, validity period, and stop conditions:
Grant authority and timestamp:
Before-state observation:
Dependency impact and consumer acceptance check:
Recovery prerequisites / backup identity / restore verification:
Authorized intent and attempt recorded before execution:
Execution start:
Observed outcome / receipt:
After-state and served revision:
Consumer functional check:
Acceptance owner and disposition:

Do not store secrets in these records. Reference the approved delivery mechanism. After a correction, refresh affected evidence and bind authorization to the revised candidate.

Interrupted execution

State: outcome unknown until observation resolves it
What may have happened:
Last durable operation and attempt identities:
Target observation and timestamp:
Was the effect applied, partially applied, or not applied?
Can the destination deduplicate this same logical operation?
Can stale workers still act? How is their authority rejected or revoked?
Next action: record success / resume known step / recover / ask for decision
Reason and evidence:

A timeout is not proof of failure. Do not replay an uncertain external effect blindly. A lease does not itself prevent a stale worker from writing. Some data migrations require restoration or forward repair rather than binary downgrade.

Small weekly operating review

Accepted outcomes:
Oldest review/integration work:
Repeated corrections and likely root causes:
State or documentation drift:
Recovery problems observed:
Operator effort and avoidable interruptions:
Model, compute, and service cost:
One improvement to try:
Rule or service to simplify / retire:
What would show the improvement worked: