Your agents gave you homework

Take an invented morning: six small SaaS changes from your agents, each marked “done”. A credit-purchase handler, a CSV export, an account check, an empty-state metric, a daily reminder and a cancellation message. Before any of them can ship, someone has to work out what passed, what failed and what nobody checked. That work comes back to you.

The opportunity I see is to make more of the checking happen before the handoff, and keep the decisions that really need you. A finished generation is not a finished task. The useful system does more of the repeatable work before asking for your attention.

This is a field note for people already building with agents. The examples are original teaching code, and no live model is called.

“Done” left six things to investigate

Each change arrived with the same completion message. Those messages are invented for this example, and on their own they don’t establish whether any required behaviour holds. A declared check route makes the next step explicit.

Don’t buy the same kind of thinking for every job

A full-stack build mixes construction, interpretation, exact facts and authority. Sending every part to a large model, or every unresolved part to you, is a choice rather than a requirement. Don’t pay a model to do declared arithmetic.

question: Does the draft promise a refund?
input: draft + the approved policy excerpt
answers: supported | contradicted | unclear
next step: review when evidence is missing

A failed check is more useful than an unnamed worry

The point is to stop making you rediscover what the agent can already test, and to keep the question precise when the answer really needs you. Here is the credit handler taken through four kinds of work:

1. Task contract, before the build. Say what finishing means: outcome, data, permissions and missing decisions. For the credit handler, a verified purchase grants once and a new purchase still grants credits, so two notifications must not double the customer’s credits. The agent gets the outcome, not a vague request for “robust code”.
2. Builder and executable checks, before the handoff. Let failure return to the builder with its input retained. The replay check on a repeated buy_42 returns 200 instead of the expected 100. The agent can inspect that exact case, repair it and rerun within the agreed budget. You do not need to repeat the same investigation first.
3. Bounded judgement or clarification, when the rule is missing. “Daily at 9am” is missing a timezone, and a test cannot discover the business’s intended answer by itself. Ask whose timezone matters instead of inventing one and calling it verified. “Unclear” is a useful result when evidence is absent.
4. An inspectable handoff, at the boundary. Give me the revision, the check command, the actual result and what remains open. If another builder takes over, it starts from that record. A proposal is not a deployed operation: approval and deployment are still separate decisions.

This route does not assume that an agent can resolve every failure, or that the author of a check should control its release gate.

Where it holds on your tasks, the next morning changes: fewer investigations from scratch, clearer decisions and checks another builder can inherit. That could create room for another feature, a customer conversation or an evening without repair work. It is an opportunity to measure, not a result this demonstration has established.

The available parts changed, and the acceptance problem didn’t

Better construction tools and specialised decision interfaces make more allocations possible. The useful question is which allocation removes work on your actual task. Three dated sources frame it:

• 11 February 2026: build the feedback environment. OpenAI’s team account puts repository knowledge, checks and control around agent construction. It is a first-party account and evidence of a working approach in that team, not a productivity promise for ours.
• 23 June 2026: more instructions can add cost without helping. The revised AGENTS.md study, a version-2 preprint and counterevidence here, found no general task-success improvement in its tested settings, with higher inference cost. Do not turn this article into a huge compulsory context file.
• 16 September 2026: a bounded judgement need not be a long answer. Vercel introduces Jev’s typed decision interface, which adds a candidate for routing and assessment. It is a provider announcement, not a local benchmark. Whether it beats your existing model after review and fallback is still a test.

The next expensive failure is a chance to stop paying for the same investigation. Capture its input and expected behaviour while you understand them.

Can this give you part of the day back?

Move the assumptions. Count setup, the review still needed and the difficult cases. Lower token spend is not a win if it quietly buys more of your time.

For you, the gain would be less reconstruction: you open the result and the failed case, rather than search for what “done” was supposed to mean. For your agent, it is a useful next move: retry a known failure or ask one grounded question, with a budget and stopping rule to prevent an endless loop. For the business, it means comparing complete routes. Value model calls, setup and your work separately. Released capacity pays off only if it is useful.

A check is exact; a judgement has a distribution

The cost argument depends on which part is reliable. These two optional worked examples keep uncertainty, arithmetic and permission separate.

Measure the work left at the end

I care less about how many agents ran than how much useful work is left at the end. A smaller pile of unresolved decisions would be worth more than a longer list of confident completions.

Start with one task. Measure all the work before and after. Keep the route only if the result and the economics hold up.

Part 2, The bug shouldn’t need you twice, makes one recurring failure reusable.

For coding agents: a handoff you can inspect

You get the work, the evidence and the decision that still needs you. Your agent gets a route to check and repair its own output before asking for help. The instruction below is editable and needs no account or sign-up.

Nothing is sent or collected. Edit this before reusing it.

The kit is local teaching code plus instructions. It does not install a host skill, evaluate arbitrary code or protect a check the builder can rewrite.