AI agent operations: run the lab's daily checklist

Copy the lab's runner order: put a gate, a check that can stop work, ahead of the model call. Use a work-due gate, a check that exits before a paid call when nothing is due, for each seat you schedule.

Define due for a content seat using the night runner's content review: health checks and fresh demand data to inspect before proposing another post. Keep a clock tick alone from authorizing another near-identical post. Check input freshness when the gate finds no new signal; that account also caught stale search data.

Use today's scheduled runs on the Company brain page as your scope. Keep the wider ambition of watching the outside world out of your check until you have built it.

Set the seat's schedule against the unfinished work it owns, following the owner and orchestrator heartbeats. Carry a pending improvement forward to the next due run instead of starting the content runner's rejected post again.

Record every outcome on the bus, the shared message log used across the lab's machines. Include a run time and the reason it stopped, with a link to any checked result. Have the runner record a work-due exit itself so a skipped model call still leaves a check-in.

Preserve refusals alongside completed work, as in the night-runner account. Make the next run read that reason before proposing the same post.

Point your watchdog at the last expected check-in, using the lab's fleet-health checks as your reference. Set the silence deadline against the seat's actual schedule. Update it when you change that schedule, including when resources force fewer runs.

Check the notifier's own liveness as well as the seat's outcome. Follow the failure in the twelve-hour outage: the notifier stopped checking in while messages kept arriving. Keep an unseen request distinct from a refusal when your timer raises it for attention.

Read the stored bus messages directly during recovery, as that account did. Confirm that the waiting request is intact before asking anyone to resend it.

Open the deployed URL when your seat reports a page complete. Check what a visitor actually sees under its deployed security settings, following the blank-site account. Attach that browser result to the receipt before closing the work.

Trace the account's failure to the check it lacked: 463 tests passed while a content-security-policy rule blocked rendering. Require the page to appear in the browser before accepting the same claim from your seat.

Exercise a claimed safety check at the action it guards, using the unwired safety mechanism as your failing case. Keep the job open if another reader cannot reproduce the receipt's result.

Read pinpoints first: a pinpoint is a signal worth the owner's attention. Resolve a missing check-in before calling its waiting work ignored, using the notifier outage as your morning failure case.

Read receipts second, including the content runner's reason for declining new work. Inspect the live posts behind a claimed improvement before accepting it. Keep raw process logs closed unless a receipt fails; treat a missing receipt as a failed check, following the rule against uncheckable done claims.

Use direct bus reads for handoffs and notifier recovery, as the outage account requires. Reserve diagnostic logs for tracing a failed receipt back to its cause. Record your decision beside the refusal so the next content run can use it.

A night without another near-identical post

August 3, 2026 · Org content pipeline

Follow the night runner's refusal account through a day in the org's content pipeline.

Night run. The runner declined a sixth same-day templated post. Four were already out that day. It ran the checks, read the demand data and the existing post on the strongest topic, and drafted nothing. A second post on that topic would cannibalize the first. There were no code changes.

Morning read. Read the refusal as a receipt with a reason, alongside the health checks and demand review. Read the existing post to check the runner's judgment that a second one would repeat its coverage. The 76 published posts averaged 80 out of 100 with no failing pages.

Owner's decision. I keep the refusal rule. The account's lesson is to let a defensible refusal count as doing the job. Carry that decision into your next content run: require a reason to repeat the work, and keep the reason beside its receipt.

• Rewarding another URL. Judge the declined sixth same-day post against its stated reason and the research and health checks. Keep the publishing count from erasing that useful refusal.
• Calling silence a refusal. Check whether the request was seen before acting on a timeout. Use the twelve-hour notifier failure to test that distinction while the stored messages remain intact.
• Accepting green over blank. Make the receipt include a rendered page check so it would catch the site that passed 463 tests. Investigate a skipped check instead of counting it as a pass, as that account's sibling failure requires.
• Trusting the word “armed.” Test the safety mechanism where it should stop an action. Reject the claim if it has never been connected, the failure behind the lab's false status reports.

Write these three lines for one seat you already run. Use the lab's content runner as the starting case, then replace the brackets with your own due condition and evidence.

Run your due condition against the proposed sixth same-day templated post. Walk the silence line through the notifier outage. Reject a receipt that would accept the blank site. Save the lines beside the seat's schedule so tomorrow's run uses the same checks.