AI Agent Operations: Orchestration, Buses, Gates & Receipts

Before the handoff, I use decompose-before-dispatch: at most six yes-or-no checklist items per assignment, with separate sets of files for agents working at the same time. The checklist stays available for verification after the agent returns.

A handoff needs to say what work is waiting, whose judgment is needed, and what evidence to inspect. Putting it on the shared bus lets agents coordinate without routing every request through me. The log keeps the request available after the moment it was sent.

The notifier alerts the recipient. It does not keep the messages stored. If the notifier stops, the recipient still needs a way to read the log directly and pick up the waiting work. The recovery flow below shows that path.

“The shared messaging system went dark for 72 minutes. We lost nothing, but the requests waiting on me looked ignored.” records what happened when the notifier failed. The messages stayed stored, and reading the inbox directly recovered the backlog without asking anyone to resend it.

Each time the loop runs, it needs a decision: check the inbox, check the current evidence, and decide whether to act, wait, or ask for a decision. Write down what fresh evidence makes a job worth repeating. Another tick of the clock does not establish that the business needs another change.

“The smartest thing my night-shift agent did all month was refuse to publish” shows why that matters. An agent declined another near-identical post and improved existing work instead. Other refusals were logged with reasons, including missing signal that turned out to come from stale input data.

Before code: is it worth building?

Identify a real customer and a painful, paid-for job before starting the build. The product owner can stop the bet here. Building ability does not establish demand.

Built right: does the work hold up?

Require evidence that the result is production-ready and tested. Give the engineering owner authority to block progress when the work or its evidence fails.

Will it earn: does the business case hold up?

Require a real customer, a live way to pay, and working unit economics. The commercial owner has a separate veto; an engineering pass cannot override it.

“We gave two different agents the power to block a release — on purpose.” records the rule I use: neither owner can call the product done alone. Both must pass, and the product must be in-market and earning. Checking whether it is worth building first saves us from discovering the missing customer after the code is written.

Match the receipt to the claim. A loaded URL proves the page is reachable; it does not prove a save works. For that, save, reload, and inspect the saved state. A success message proves only that a message appeared.

“A green checkmark that isn't the AI's own word: building a quality check with teeth” records why the checker needs scrutiny too. It produced false failures and exposed checks that worked in isolation without running in the live workflow. Keep unchecked work visibly unchecked, reject an all-waived result, and require evidence before a finding can be marked addressed.

“I don't let my own AI say a high-stakes release is done. A rival AI signs off first” gives the production-ready verdict to a different model family from the builder. A failed review held the release, but the reviewer also made false claims. Reproduce disputed findings. I need evidence strong enough to overrule either agent.

For instructions you can hand to an agent, use the delegation playbook’s acceptance receipt, alongside its charter, stop-list, and handoff templates.

Source note: these AI Guide examples are my published operating accounts. The underlying evidence records do not currently have public artifact links. The notes explain what was checked; they are not a substitute for inspecting your own live result.

In “The shared messaging system went dark for 72 minutes. We lost nothing, but the requests waiting on me looked ignored.”, waiting approvals looked ignored because the notifier had stopped. An escalation timer treated the silence as stalled work. The backlog was intact; the messages were still there, waiting for attention.

1. Check storage and attention separately. Verify that the message exists in the log, then establish whether the intended recipient has seen it. One answer cannot stand in for the other.
2. Keep direct reading available. Agents or a human need a recovery path that bypasses the notifier. The standing habit from the failure was to inspect the log directly instead of trusting alerts alone.
3. Make escalation describe what is known. An unseen request and a considered pass need different responses. Design that distinction into the escalation before a timer turns delayed delivery into apparent neglect.

This is how I want failure contained: the notification can stop without taking the work record with it. The recovery still needs attention, but it does not need the sender to reconstruct the request.