Deciding when to trust agent output

Raising an agent's autonomy is a bet that its unsupervised work will hold the same bar as its supervised work. The bet should rest on evidence, not on the vague sense that "the agent seems good lately". Task Machine generates that evidence as a side effect of normal operation, and this page shows where to find it and how to read it.

Verifier steps check the work before you ever see it

The first layer of evidence is mechanical. A verifier step inside a workflow checks output against criteria you defined — the draft matches the voice guide, the report covers every agreed section, the research cites its sources — before the run moves on. That does two things for trust. It catches weak work early, so what reaches your inbox has already cleared a bar. And it turns your quality standard into something written down and applied every run, so "the output is good" stops meaning "I liked the last one I read" and starts meaning "it passes the checks, every time". When you later reduce your own reviewing, the verifier keeps checking. Your standard does not loosen just because your attention moved elsewhere.

Writing verifier criteria for non-code work

Code has tests. The rest of the work needs its bar written down just as concretely, and the discipline is the same: a criterion is a checkable statement, never "is it good". For a content draft, the checks are that every link resolves, every claim carries a source, and the text holds to the voice document — named terms used, banned phrasings absent. For a report, the totals reconcile with the numbers they came from and every agreed section is present. For research, each finding says where it came from, so you can spot-check the one that surprises you instead of taking the whole document on tone. For an outreach draft, the name, company, and details match the research it was built from, and no placeholder survived into the text.

The easiest way to write these is backwards from your own corrections. Whatever you fixed in the last few reviews is, by definition, a failure the verifier should have caught — turn each repeated fix into a criterion, and that class of mistake stops reaching you. A verifier built this way is your reviewing, mechanized: it holds the bar on every run, at every autonomy level, whether or not you read the output that cycle.

Run history shows what actually happened, step by step

The second layer is visibility. Every workflow run records what each step did — what it received, what it produced, where it paused, what a verifier found. When an output looks off, you do not have to guess where it went wrong: you open the run and read the step where it did. This matters most in the early weeks, when you are deciding whether misses are random or systematic. An agent that fails in one identifiable step is an agent you can fix — tighten the instruction, add a check — and a fix you can verify on the next run. An agent whose work you only see at the end is one you can only grade, not improve.

Approvals leave a decision record you can read back

The third layer is your own trail. Every approval you make from the inbox is a recorded decision: what was proposed, what you decided, when. Read back over a month of them and you have the honest history of an agent's work — how often you approved unchanged, how often you sent something back, whether the corrections are repeating or shrinking. That record is a far better basis for an autonomy decision than memory, which overweights both the best draft and the worst one.

All three layers land in one place, because tasks are the papertrail. The task timeline holds the run, the questions, the approvals, and the final output in one ordered history, so "how has this agent actually been doing" is a thing you look up, not a thing you recall.

A rejection with a reason is a correction that sticks

When you send work back from the inbox, the reason you attach does more than shape the next attempt on that task. It feeds the agent's memory, so the same agent carries the correction into future runs — and when a correction is really about your company rather than about one agent, you put it in the knowledge library, where every agent reads it. That is the difference between rejecting and teaching: "no" alone buys you one better revision, but "no, because our audience is operators, not engineers" changes every draft after it. Over a month, the rejection reasons you wrote become the most precise record of your standards anywhere in the workspace — and the rate at which you stop needing to repeat them is itself trust evidence, the same kind the rest of this page reads.

Repeated clean runs are the signal to raise autonomy

The evidence converges on a simple rule: raise autonomy when the record shows repeated clean runs — verifiers passing, approvals going through unchanged, no corrections in the timeline — across enough cycles to rule out a lucky streak. Not after one great output, and not on the calendar. And the same record works in reverse: when clean runs stop being clean, the timeline shows you exactly when and where, and stepping the autonomy level back down is one deliberate move, not a crisis.

Trust built this way compounds. Each job that earns autonomy frees the attention to bring up the next one — which is how a single playbook grows into an operation, the subject of the final page in this section.