Seven stories

How work moves through the system

Seven short stories, cast by role. Each follows one piece of work between the owner, the agents and the tools, and marks every point where the owner says yes.

A way of organizing work is easy to agree with in the abstract. It is clearer in motion. Here is how the system handles a bug report, a feature, a migration that will not finish, a production incident, a requirement that changes under a running agent, a week of inbox that mostly goes nowhere, and an agent earning the right to work alone.

Each story follows one piece of work, step by step. Every step names who takes it — the owner, an agent or a tool — and lands on the record under that name. An agent may be a person on the team, a contractor or an AI model; the process is the same. A gate marks each point where the owner says yes; everything else runs unattended.

The command that lied about success

A failed clone exits zero and CI goes green. The fix runs from one inbox line to a pinned release, and the fixer never writes the test that judges it.

A fleet-sync command prints a clone failure and exits zero, so continuous integration goes green on a run that skipped a repository. The owner puts one line in the inbox. A triage agent classifies it as a bug from classes that already exist, and a framing agent states the problem before any fix, so the fix is judged against the problem, not against itself.

The specification holds one requirement, one check and a two-condition definition of done. The owner’s acceptance of it is the commitment. Then, before any fix is briefed, an independent oversight agent writes the regression test under a separate brief and shows that it fails on the current code.

Only then does a fixer agent receive a sealed brief and work in a scoped workspace; the harness, not the fixer, signs what comes out. CI runs two of the three possible checks, and the skipped one stays visible on the record. The owner validates the result against intent and accepts publication. The last step, pinning the new version into the toolset, needs no approval: it names the previous pin as its way back.

What it shows

The fixer never writes the test that judges the fix — and the record shows who did.

The plan that was wrong

Five pieces, built partly in parallel, every one verified. Then the records show a dependency nobody planned — and the defect is filed against the plan, not the code.

The owner notices another tool scraping a command’s human-readable output with regular expressions, and asks whether everything could speak JSON. Framing sharpens it: output meant for people is being parsed by programs, so every change of wording is a breaking change nobody declared. An investigation timeboxed at one hour (40,000 tokens, for an AI agent) finds seven call sites.

The decision keeps its two losing options, each with the reason it lost: per-command JSON would drift into three encodings of one record, and a template is still text to parse. The chosen approach, one shared encoder, is split into five pieces: the encoder first, three subcommands fanning out from it in parallel, and one aggregate after. The plan names who answers for the join where three pieces wait on one.

Every piece passes verification. Then the records show something no one planned: one run read a record type that a sibling had just added. The plan says the two are independent; the drift, derived by comparing the plan with what each run actually read, says otherwise. The finding is filed against the plan, not the code: the record type belongs in the encoder.

What it shows

A defect can live in a plan. Because every run records what it read, the records catch it.

No end in sight

A migration estimated at a day keeps going. The harness counts, a limit stops it from outside, and the owner who asked for it chooses what comes next.

An AI agent’s migration is estimated at one day — 400,000 tokens — with a rule written into the plan: reconsider past one and a half times that. Before any work, the owner makes the harness, not the agent, the one that counts what is spent. A self-reported count proves nothing.

The first run hits its own 300,000-token budget and stops quietly: blocked, budget exhausted, with the parser done and 41 of 112 rules ported. A second run starts. At 610,000 tokens the work as a whole crosses its 600,000 limit, and the run is stopped from outside, preempted, citing the observation that crossed the line. Nobody has to notice, and nobody has to decide to stop it.

With two of six done conditions met, the agent does not rule on whether the work is still worth doing. The owner does, choosing among continue, split or abandon. The choice is to split, with the reason on record: one estimate hid three kinds of work, a switch, a reconciliation and a removal.

What it shows

A run’s budget is a fuse. The work’s limit is a question, put to the owner who asked.

Rolled back in ninety seconds

A deploy breaks a health check. No one declares an incident: the rules derive one, an agent rolls back alone, and the owner admits the standing rule the agent puts forward.

A service runs under a liveness probe. A new version goes live with no approval, because it names the running version as its way back. Its target is known healthy from a probe result recorded before the deploy; a pass recorded afterwards would not count.

One minute later the probe fails, and fails again. No one declares an incident, and no record says “incident” at all. The rules derive it: an unhealthy target, after a deploy, with a way back on record, means a rollback is due. An agent rolls back without asking anyone, citing the two failures, and service is restored in about ninety seconds.

The postmortem rules the failure a defect, and the agent puts forward a standing rule: every production deploy is canaried first. A new rule changes what everyone may do, so it waits for the owner, who admits it later that morning; it binds only acts after that moment. The delivery measures, one failed change and ninety seconds to restore, fall out of the same records with no report written.

What it shows

Recovery doesn’t wait for the owner when it can be undone and the reason is on record.

The rules change mid-flight

While a run is working, its requirement stops being right. The requirement is superseded, not edited — and the run already in flight is salvaged into the next one.

A sync command gives up on the first network hiccup. The committed specification says three retries, one second apart, and a fixer’s run starts. While it is still working, the hosting provider begins rate-limiting clones per host — and fixed-interval retries from a whole fleet would trip that limit.

The owner supersedes the specification with one requiring exponential backoff, capped per host. Nothing is edited. The old specification, its partition and its brief remain as written; a separate, timestamped supersession record changes their standing.

The run already in flight finishes, and its result stays on record. It is not validated against the old intent, which is no longer owed anything. It is salvaged instead: it enters the new brief as an input, and the second run starts from its retry loop. A new run under the old brief, or a late acceptance of the old specification, is refused.

What it shows

Time decides what counts. Work done before the change stands, and nothing done is lost.

Most of what arrives is never built

A week of inbox: rejected against a published reason, linked as a duplicate, parked with a clock, expired with what was learned. One item is built.

One item asks for a change to something outside the system’s remit, and is rejected against a published reason, not on merit: whoever wrote it cannot be asked what they meant, so a rule decides rather than the mood of the day. One bug arrives twice, and the second report is linked as a duplicate. One idea is parked until a date, another until a named condition, because a park without a clock quietly becomes “never”.

A question about how a third-party tool behaves becomes a two-hour investigation. It expires without an answer, and its closure records what was learned: the tool cannot be run unattended, so the unknown is a gap in the environment, not in the question. A successor item carries the question forward instead of spending the time again.

Only the bug goes on to be built. Nothing is deleted: every declined item remains as captured, with its standing derived from the triage record beside it.

What it shows

The record of not doing is as complete as the record of doing. A dead end is a result.

Autonomy is earned

A triage agent’s first three answers are confirmed by the owner and graded later. The fourth, at the same confidence, runs unattended: calibrated by the record, not the agent’s word.

A triage agent answers which kind of work is this? from four declared options — one of them “none of these” — at a stated confidence of 0.9. For the first three items the owner confirms each answer before it counts, because the agent has no track record in that band, and grades each one afterwards.

By the fourth item, three earlier answers in that confidence band have been graded right before it is made, so the fourth runs unattended. The agent says 0.9 every time. What changes is the record.

What it shows

Autonomy is earned from the record, never taken from the agent’s own word.

Twelve lines worth keeping

The rules the stories bear out, said in one line each, every one linked to the story that shows it.

1. A gate belongs where a mistake becomes uncorrectable, not where the work looks important.

   GatesRolled back in ninety seconds

2. Nothing checks its own work.

   EvidenceThe command that lied about success

3. A verification states what it could have checked, not only what it did.

   EvidenceThe command that lied about success

4. A defect can be in a plan, not only in code.

   PlansThe plan that was wrong

5. Parallel work collides where the plan wrongly assumed independence. The records show where.

   Parallel workThe plan that was wrong

6. A budget is a fuse, not a decision.

   BudgetsNo end in sight

7. Work does not rule on whether it is still worth doing.

   BudgetsNo end in sight

8. An incident is a fact derived from other facts, not a status someone remembers to set.

   RecordsRolled back in ninety seconds

9. An agent may put a rule forward; only the owner can make it one. A new rule looks forward, never back.

   GatesRolled back in ninety seconds

10. Time decides what counts. Work is salvaged, not lost.

    RecordsThe rules change mid-flight

11. A dead end is a result.

    RecordsMost of what arrives is never built

12. Autonomy is earned from the record, never taken from the agent's own word.

    AutonomyAutonomy is earned

Each line states a rule of the system. The link under a line opens the story that shows it.