The Agent Never Ran. Neither Did Its Alarm.

On August 31, 2026 the GitHub Actions budget ran out. The agents did not start. Neither did the alarms running beside them. An external heartbeat noticed the missing signal.

The dated governance account records it. There was no run to inspect. That is the failure I want to catch.

For Orbyt Collective, I want “No Hands” to mean useful work without continuous steering. I would limit what a lane can change, require an observable result, and keep an owner for exceptions. The whole company has not been verified to that standard here.

Unattended operation needs evidence about the work that was due, including the work that left no agent transcript.

What am I actually leaving unattended?

I would define a window first: task, allowed resources, deliveries, spending ceiling, owner, and stop conditions. “Keep improving the company” has no inspectable finish.

My proposed lane would save a weekly research digest from approved public sources to a private queue. It could not publish, contact people, change credentials, or widen access. This is illustrative, not a run receipt.

The window grants only the authority already approved for that lane. It does not promote the agent. The seat structure and permission boundaries answer who may act; the window answers what must remain true while the owner is away.

I would keep the operating record short. Its entries would point to the real controls and records rather than create another set of settings that can drift.

These are proposed limits. I would check their enforcement before opening the window. If I cannot be reached, the lane stops new work and holds its draft. It does not publish to rescue a deadline.

How do I count work that never ran?

My expected-work record would live outside the individual agent run. It names what was due even when no process starts. I would reconcile it with scheduler events, execution outcomes, and accepted artifacts. Missing work must become a visible outcome.

The public Orbyt Autonomy Ledger measures completion over recorded runs. It counts skips, halts, and infrastructure outcomes separately and excludes them from that rate. I would not relabel it as delivery of every scheduled obligation.

For a digest lane, I would use a separate denominator: all deliveries due under the agreed schedule. I would mark each as accepted on time, accepted late, failed, blocked, or not observed by the deadline. I would preserve an authorized cancellation as a distinct event with its reason.

I would not quietly remove a missed delivery because the scheduler never created a run. Nor would I count a task cancelled in advance as an execution failure. I would list every scheduled digest, mark cancellations, and show what happened to the rest.

In a synthetic example, six digests are scheduled. One is cancelled in advance. Three arrive on time, one late, and one never starts. A run-only report can omit the last failure.

I would list all six, the cancellation, and the five remaining outcomes. Four accepted artifacts are not five successful deliveries.

The schedule supplies the denominator that the execution log cannot supply alone.

In the governance account, I wrote: “I had not opened the tab.” A dashboard I have to visit is still manual monitoring.

Completion also needs meaning. An empty digest still exists. I would freeze the source list before drafting and check that the draft accounts for each source. One model call would draft it. A second, separate model call would inspect each factual conclusion against the cited passage in that frozen source set. The checker would verify that both verdict and draft were saved at the private destination. A rejected or missing verdict means the delivery is not accepted, even if a file exists. A drafting retry would consume the second call, leaving no automatic acceptance. I would hold that draft for manual review. Artifact existence, quality acceptance, and on-time delivery remain separate observations.

Who notices when the observer disappears?

A worker reporting its own success cannot detect a failure that prevents it from starting. I would give the checker a separate budget. It might still never start. I would pre-arm a timer on a separate provider and budget before opening the operating window. It would hold the scheduled delivery ID and the owner's alert route. If I could not confirm that timer was armed, I would leave the lane manual.

The checker needs its own deadline.

At 09:05, the checker would run. It would compare the scheduled obligation with the queue, the draft, and its acceptance verdict. Without reconciliation, there is no receipt. The checker would send that receipt to the timer. Starting the checker would not refresh the receipt. If the timer had no completed receipt by 09:10, it would email the named owner about the missing checker signal. A checker that sees a missed delivery or cannot read the queue would alert immediately and leave the obligation unresolved. After ten minutes without acknowledgement, the configured backup channel would carry the notice. I would keep the delivery unresolved until I had a verified outcome.

The timer is another dependency. Jobs can share budgets, credentials, and connectivity. I would list those shared paths. I would record channel delivery and human acknowledgement separately. A send event alone proves neither.

Rob Ewaschuk's chapter on monitoring distributed systems (opens in a new tab) distinguishes internal signals from external checks. It treats paging as expensive. I would inspect the delivery and make the alert describe a decision I can take.

Observation needs its own outcome. If the checker cannot read the queue, I would record “not observed,” the last successful completed receipt, and the reason. This lane would hold further consequential work and escalate. A missing checker receipt would trigger the timer even if no checker process ever existed.

I would test with a real recipient. I would compare the timer's send record, the channel's delivery receipt where available, and the owner's acknowledgement. Without acknowledgement, I would test the backup channel too.

I have not run this exercise. I would prevent the checker itself from starting, leave the worker healthy, and inspect whether the external timer's notice reached the owner by the proposed 09:10 deadline. I would then restore the checker and confirm the timer stayed quiet after a completed receipt. I would also cancel a delivery in advance under recorded authority and confirm that the checker did not flag it as a missed start.

Can recovery make the failure worse?

Suppose the digest was saved, but the worker lost confirmation. A blind retry could duplicate it or overwrite a human edit. “Try again” has side effects.

I would reuse one delivery ID. Before retrying, I would inspect its destination and version. I would use a conditional write where supported; a check followed by a write can race.

If the destination cannot prevent duplicates, I would serialize delivery or hold the attempt. A prompt cannot guarantee exactly-once effects. Storage behavior must support the claim.

I would count repairs and repeated verification against the same retry ceiling. Asking another agent to fix the failure would not reset it.

Recovery needs a fresh observation. A retry command is insufficient. If verification remains unavailable, I would stop and preserve the uncertainty. That is the self-healing boundary I can check.

The governance account records another choice: on September 2, 2026 the month-end blackout was accepted for now rather than buying more execution capacity. For this proposed digest, I would accept a visible miss before buying another platform. I would not call the delivery reliable.

I would allow one working day to assemble the lane from existing components. If that proved insufficient, I would keep it manual. This is a proposed budget, not an estimate.

I would count preparation, interventions, and cleanup against the time saved. If they exceed the savings, I would keep the digest manual. An unattended night followed by a morning of repair is an incomplete account.

What to do Next

I would start with one reversible lane and walk a successful delivery through its actual path. I would use a real recipient and destination. Then I would test the failures that invalidate leaving it alone, within the written operating window.

I would suppress the worker start. I would interrupt a save after the side effect but before acknowledgement. I would deny the checker access, prevent the checker from starting, exhaust the retry budget, and request a halt during work. For each exercise, I would record what was observed, what stopped, what persisted, and whether the owner received the required notice.

I would keep a healthy control beside each exercise. A halt test must also show that normal authorized work can proceed. A missing-start alarm must distinguish a real miss from an explicitly recorded cancellation. Otherwise the system may buy apparent safety by refusing to operate.

I would resume only from a reconciled state under the recorded authority. I would preserve the failed attempt, the recovery decision, and the final observation. A clean summary must not erase the work required to obtain it.

This is the “No Hands” standard I want for the Collective: less continuous steering, bounded recovery, and visible exceptions. The protocol here is proposed and unexecuted. The historical receipts support the need for it; they do not establish that every current lane meets it.

I still own the consequences when I leave the chair.

Related reading:

• Governing an agent leadership team the published incidents behind the observation and heartbeat requirements.
• The Agent Org Chart, Hello Collective. the seats and bounded responsibilities behind a proposed unattended operating lane.
• Heal What You Can Prove. bounding automated repair by an observable result.
• Human-in-the-Loop Is Not Enough making ownership an executable responsibility rather than a label.