Work & verification

The user-facing word is task. Underneath, three nouns carry everything: a Work is one ask, a Target is that ask on one repository, an Attempt is one agent execution against a target.

The lifecycle

pending → claimed → preparing → running ─┬→ verifying → succeeded ─┬→ queued_for_merge → merging → merged
                                          │                         │
                                          ├→ failed / cancelled     └ (integrate=false: terminal here)
                                          └→ waiting_human → running        verifying → unverified

Two details do a lot of work. Terminal depends on intent: succeeded is only terminal for non-integrating work — an integrating target isn't done until the merge queue lands it, so nothing downstream releases on unmerged code. And waiting on a human is a state, not a hang: an agent that needs input parks the target, the question enters an attention queue with per-urgency SLAs, and a decider model can auto-answer the non-critical ones when you're away.

Modes are the org chart

Mode	Role	Writes
`plan`	decompose an ask into a task DAG — write-sets, `blocked_by` edges, sizes	nothing
`run` / `implement`	build; implement carries commit discipline and L2 verification	repo
`review` / `audit`	ranked findings with file:line and a verdict	nothing / notes
`verify`	adversarial re-check of another attempt's claims — build it, run it, click it	nothing
`supervise`	judge a settled batch: scores 1–5, done or revise	notes only
`greenfield`	from-scratch projects in a virtual repository	new project
`retro` / `curate` / `explore` / `intake` / `docs` / `maintain`	memory, triage, and upkeep	varies

A mode fixes the preamble, the allowed tools, the default budget class, and — the part that makes results machine-readable — a JSON schema the executor enforces on the agent's final message. A reviewer can't return a verdict-shaped paragraph; it returns a verdict.

The four verification levels

Level	Question	Checked by
`L0`	Do the claims match git reality — files changed, commits made, scope respected?	the platform, mechanically
`L1`	Do the repository's declared checks pass?	the platform re-runs them; the agent's word doesn't count
`L2`	Does the thing actually work?	a separate verify agent with no stake — rebuilds, runs, exercises UI in a real browser
`L3`	Should this stand?	a human

An attempt that fails its level lands unverified, with the reason recorded — not silently retried, not optimistically merged. The 10-apps overnight run that scored 0/10 verified was these rules doing their job on Forge itself.

Parallelism without collisions

Tasks declare write-sets — path globs — which the scheduler holds as leases per repository; lockfiles are an implicit exclusive lease. Dependency edges (on:success or on:terminal, with stacking hints for branch-on-branch work) order what must be ordered; everything else runs concurrently up to the worker's limit. The merge queue is the final serializer: rebase, re-check, land.

Autonomy is a slider, not a switch: ask · checkpoint · notify · auto, resolved per work from the ask, the routine, and the project — and a spawned task never runs more autonomously than whatever spawned it.

Next: The library & tools — where the words live.