Delegating Real Work to AI Agents and Verifying It

I want the first delegation to teach me whether the agent can carry a job through and whether I can judge the result. A vague instruction to “improve things” gives neither of us a useful boundary. Pick existing work with known inputs and a result you can point to.

This is the principle behind the trust curve: verified performance earns a wider scope of action.

1. Choose what to check. For example, ask for a review of a defined set of published pages against a checklist you supply. Use this as a starting exercise. It does not describe a past run.
2. Define what comes back. Require the page, the observed issue, the evidence, and a proposed correction for each finding. A review with no findings must still say what was checked.
3. Set limits on what it may do. For this first exercise, authorize inspection and proposed changes. Require a decision before changing the published pages. If inputs are missing or the criteria are unclear, require the agent to ask for a decision.
4. Inspect before expanding. Compare the receipt with the checklist, resolve disputed findings, and correct the charter where it left room for guessing. Only then consider authorizing the next kind of work.

For the review stages, see the trust curve.

The guide’s short charter is the starting point. I would fill in the version below before a recurring job runs. Replace every bracket with a decision; a limit left blank is still a decision someone will have to make while doing the work.

Read it back as the reviewer: could you reject a plausible but incomplete result using this contract? If not, tighten the acceptance check. I need the boundary clear before the agent encounters it.

1. Write the claim and its check together. If the claim is “the change was saved,” the check is save → reload → inspect the saved state. A message saying “saved” does not answer that question.
2. Ask for a receipt per criterion. Require the actual result, how it was inspected, and where the evidence is. Missing evidence stays unchecked; waiving every check cannot produce a pass.
3. Give the reviewer authority to hold the release. In my model, a different model family challenges the builder’s production-ready claim. Give it the original criteria and authority to hold the release.
4. Resolve disagreements by repeating the check. Re-run the disputed check against the relevant result. Record false findings as well as real defects, and require evidence before clearing either.

“I don't let my own AI say a high-stakes release is done. A rival AI signs off first” records a held release and findings the reviewer got wrong. “A green checkmark that isn't the AI's own word: building a quality check with teeth” shows why the checker itself needs scrutiny and why missing evidence must remain visible. Verification still takes work; I focus that work on the outcome and the disputed claims.

Source note: these AI Guide examples are my published operating accounts. The underlying evidence records do not currently have public artifact links. The templates here translate that model into instructions to try; they are not a guarantee of reliable execution or a substitute for inspecting your own live result.

I do not want the schedule to become a publishing quota. Put near-identical output and maintenance with no new signal on the stop-list. Name the trigger that would justify action: a changed source, a newly observed problem, or another specific change relevant to the job. Check that the inputs are current before treating missing signal as evidence that nothing needs doing.

“The smartest thing my night-shift agent did all month was refuse to publish” records refusals of repetitive work and a missing signal traced to stale inputs. Review these records alongside shipped work. A refusal needs a defensible reason; an empty status gives me nothing to inspect.

1. Name the next area of work. Write what the new owner takes over, where its authority ends, and who receives its result. Resolve overlapping ownership before work starts.
2. Write the handoff. Put the requested decision and evidence on the shared bus. The next owner should be able to inspect the request without asking me to reconstruct the conversation.
3. Keep the judgments independent. Give engineering and commercial owners their own vetoes. Ask whether the work is worth building before execution; a technical pass cannot settle whether it will earn.
4. Check storage and attention separately. Confirm the handoff stays stored, then confirm the recipient saw it. Keep a way to recover by reading the log directly. Distinguish an unseen request from a considered pass.

“We gave two different agents the power to block a release — on purpose.” explains why neither owner can call a product done alone. Under my operating rule, it must also be in-market and earning. “The shared messaging system went dark for 72 minutes. We lost nothing, but the requests waiting on me looked ignored.” records recovery from a surviving log. That recovery depends on the durable store remaining intact.

Use the operations hub for the bus and recovery mechanics, and the guide for the human’s responsibility. Adding owners does not remove mine.