What an Agent Seat Actually Completes

The data.

How it was measured.

Every figure is read from the organization's committed per-seat run ledger (docs/org/stats/<seat>.jsonl, aggregated into public/autonomy-ledger.json by generate-stats.cjs at every commit). A run is one scheduled or dispatched execution of a seat's workflow; the ledger row is written by the workflow itself, not by the agent.

Completion means the run's output survived the workflow's completion gate (a check of how the agent's run ended: its exit, its result and its turns against its cap), the guard gauntlet, and the commit. Since decision D-0061, in September 2026, the completion line a seat prints is recorded as its claim rather than required; runs before that decision also had to print it. A run whose output the guards refused is a failure. Rows recording that no run happened (skip: nothing to do; halted: a kill switch; infrastructure: the org could not run) are counted separately and sit on neither side of the rate.

A discard is a file the agent changed outside its effective keep set, erased before the commit rather than shipped. It is an aggregate counter across runs and a different unit from a failure: it says the agent reached outside its lane, not that its work was rejected.

The baseline is the ledger as first published on Aug, 11 2026 (30 runs, 80.0% completion), frozen on purpose and never regenerated, so every later reading is measured against the same origin rather than against a moving average.

Failures are printed, never netted out. The rate is completions divided by runs, and both numbers are on the page.

What this does not show.

• One organization, nine seats, one workflow shape. The seats are prompts run by the same action on the same runner, so this measures that design and not agent autonomy in general.
• Passing the completion gate is not the same as the output being good. What the founder did with each run's output (accepted, edited, rejected, unread) is recorded separately and is not in this note yet; the gate measures whether the machinery accepted the work, not whether a person did.
• Small numbers. Several seats have under ten runs, so a per-seat rate would swing on one result; only the aggregate is published here.
• The ledger records what the workflow wrote. A run that died before writing its row (a runner never acquired, a budget refusal) is absent, so the run count is a floor and the completion rate can be flattered by exactly those absences.
• No trend is claimed from the baseline comparison. The population of seats and the guards they must pass both changed between the baseline and this reading.

Revisions.

This URL is permanent. When the data is refreshed the version bumps and a row lands here, so a citation made today still resolves to the finding it cited.

Back to all research