When Nobody Is Watching

What leaves with the supervisor? Safe unattended work requires failure to be bounded, visible, recoverable, and unable to quietly become success.

What leaves with the supervisor?

An agent completes a task successfully while somebody watches, and the work can feel remarkably autonomous. Large portions of what would previously have been manual work have been handed over to the machine.

It researches a question, changes a system, handles a customer request, or writes some code. When it misunderstands something, the person nudges it back on course. When it encounters an exception, the person decides what to do. When it claims to have finished, the person checks whether the result is convincing.

Then the person closes their laptop.

The model has not changed. Its tools have not changed. Its instructions may not have changed. The system has changed. Its interpreter, anomaly detector, circuit breaker, recovery coordinator, and final judge have all left.

An agent capable of performing work is not yet a system capable of governing that work when nobody is continuously present.

Unattended work requires a system in which failure is bounded, visible, recoverable, and prevented from quietly becoming success.

We need to ask two questions: can the agent do the work, and who or what will take responsibility for the supervising person's functions when they leave?

The invisible supervisor

Consider a customer support agent allowed to issue refunds. The agent receives a request, checks the account, interprets the policy, and proposes an amount. During a supervised trial, a person notices that the customer has already received a partial credit. They correct the amount before the refund is sent.

The visible output belongs to the agent. The safe outcome belongs to the whole system, including the person who caught the exception.

People perform this hidden work in many agent interactions. They maintain the original intent while the conversation grows. They notice when a plausible answer addresses the wrong question. They judge whether a source supports a claim, whether an action carries more consequence than expected, and whether a failure can be retried. They interrupt loops that remain active without making progress. They remember details that never made it into the prompt.

Interactive evaluations often credit these functions to the agent because the person does not produce the final artefact. The person's contribution becomes visible only when they leave.

A successful supervised trial establishes the performance of a combined system. It does not establish that the same work can run unattended.

Remove the person and those responsibilities need new owners. If they remain unassigned, the system has less control even though the agent retains the same capability.

Capability lets an agent travel further

Longer instructions, more tools, and better recovery from local errors let an agent complete more work before asking for help. They also let the agent make more linked decisions before anybody checks the result.

A capable agent can carry a mistaken assumption through research, planning, execution, and evaluation. It can exercise more authority, consume more money, and create a more convincing account of incorrect work.

Fifty successful ordinary refunds provide evidence that the agent can handle ordinary requests. They do not establish authority for unusually large refunds, conflicting policies, or incomplete account histories.

Capability determines how far an agent can travel. It does not determine where it is allowed to go, how anyone knows it arrived, or what happens when it leaves the road.

The missing functions need owners

An unattended system needs to assign the functions previously supplied by the person. The mechanisms will vary by domain, but the responsibilities recur.

Responsibility	Question the system must answer
Purpose	What end was delegated, and who may change it?
Authority	What may the agent read, change, spend, or communicate?
Interpretation	Which ambiguity may it resolve, and which requires a person?
Evaluation	What evidence establishes that the outcome was achieved?
Control	Which evidence permits or refuses the next consequential action?
Recovery	What happened before an interruption, and what is safe to do next?
Accountability	Which work was accepted, completed, parked, or left outstanding?

Removing continuous supervision does not mean every responsibility moves into code. People still own purpose, risk acceptance, and judgements the available evidence cannot settle. Code can enforce repeatable decisions, while evaluators test completion claims and durable records preserve interrupted work.

Each responsibility needs an owner and a defined response when that owner cannot establish an answer. Missing evidence should not become completion. Unknown state should not become permission to retry. Ambiguity outside the delegated boundary should return to a person with the decision made clear.

Trustworthy systems still fail

Expecting every result to be correct would make trust impossible for any fallible system, including one operated by people.

Trust comes from knowing what failure can do and how the system responds. For the refund agent, a sensible operating boundary might limit the amount, require an external record of the transaction, refuse accounts with inconsistent history, and send policy exceptions to a person. The agent can still misunderstand a request. The surrounding system limits the consequence and keeps uncertainty from becoming an approved refund.

The same failure pattern appears elsewhere:

A research agent should not turn missing support into a sourced claim.
A recruitment agent should not convert an ambiguous preference into a hidden selection rule.
An operations agent should not treat a command completing as proof that the intended service state was reached.
A coding agent should not treat passing tests as proof when those tests do not cover the agreed outcome.

A system is safe to stop watching when its failures are bounded, visible, and recoverable, and when a failure cannot quietly pass as success.

Governance enables autonomy. A spending limit lets an agent act without approval on every small transaction. Independent evaluation lets work complete without a person reading every step. Recovery records let a task run longer than one session. A clear path back to a person lets routine cases continue without scheduling a supervisor for all of them.

Every control should let the agent take on more useful work safely. A control that adds friction without containing a named consequence does not help the system earn trust.

Human attention changes shape

Discussions about autonomous agents often ask whether a person remains "in the loop." That phrase compresses several kinds of human involvement into a yes or no answer.

There is a material difference between continuous supervision and exception-driven intervention.

During continuous supervision, a person stays present in case their judgement is needed. During exception-driven intervention, the system proceeds while the work remains within its authority and the evidence supports continuing. It returns when a decision exceeds that boundary.

flowchart TD
    A[Agent works] --> B{"Within authority and supported<br>by current evidence?"}
    B -->|Yes| C[Continue]
    B -->|No| D[Preserve the work]
    D --> E[Ask for a decision]
    E --> F[Resume, change bounds, or stop]

Agentic work cannot be treated as a fixed sequence. An agent interprets instructions, assesses possible actions, and responds to changing conditions. It may pursue the requested outcome by an unexpected route, or ignore the request and set its own path and destination.

Cycle racing offers a useful analogy. A race is unpredictable, but it unfolds within established rules. Riders do not ask commissaires to approve every move. Commissaires oversee the competition, interpret and apply its rules, and decide how incidents should be handled. The race continues until something requires them to act. Human control lies in the rules, oversight, and response to exceptions. British Cycling describes this role as managing sporting control to keep competition safe and fair.

The person still owns the consequential decisions. Their attention is no longer scheduled around routine execution.

Exception-driven intervention only works when the request for attention is useful. "Something went wrong" transfers the investigation back to the person. A useful escalation states what the agent was trying to achieve, what happened, what remains safe, and which decision is needed.

The goal is a system that knows when it needs a person and can preserve the work until that person arrives.

Autonomy belongs to work

How much you can trust an agent depends on what you ask it to do. The same agent may summarise public research without supervision but require approval before sending a customer communication. A coding agent may update documentation unattended but need close supervision for authentication changes.

Trust becomes specific when a team names one kind of work and defines what a good result looks like, what can go wrong, what the agent may do, and what earlier outcomes have shown. Those decisions provide a reasoned basis for choosing how closely the work needs watching.

Recorded outcomes may justify less supervision. A team might begin by watching the agent complete each task, then review only the completed result. Later, the agent may work through a queue and return the exceptions.

Changes to the work, model, tools, credentials, or external systems may invalidate earlier evidence. A false pass or failed recovery may also require closer supervision until the cause is understood.

There is no permanent promotion. Progressive autonomy means changing the level of supervision as the evidence changes.

Exploring unattended software delivery

I have been exploring this problem while building SuperDomestique, formerly known as faff, a system for planning, delivering, and governing increasingly independent software work.

Software delivery is a useful test case because agent actions create durable consequences. An agent can alter source code, exercise credentials, make a chain of product and engineering decisions, choose tests, review its own work, and leave partial changes after a failed run.

SuperDomestique takes its name from cycling's super-domestique: an experienced support rider trusted to stay with the team leader at critical moments and make tactical decisions when the team car cannot. The rider still serves the team's goal, but exercises more judgement and independence than a conventional domestique.

Commissaire takes its name from those cycling officials. Agents and people plan, build, and review the work. Commissaire records their evidence, checks objective rules, and decides whether the work may cross a named boundary. It can reject a malformed verdict or refuse a missing one. It cannot prove that a reviewer's reasoning was sound.

SuperDomestique uses trust levels to state who runs a class of work and when a person steps in:

Level	Who runs the work?	When does a person step in?
L1	The person	Throughout
L2	The agent, one change at a time	At major transitions
L3	The agent, across an eligible queue	When work is ambiguous, blocked, or ineligible
L4	The agent, without scheduled supervision	When a control refuses the run or evidence requires judgement

SuperDomestique uses its own L3 workflow to develop itself. It builds human-selected work unattended, but I retain close control of its product direction and technical choices. A poor decision in the factory could be carried into every project it later builds, so the risk warrants more supervision than the same agent may need for a bounded workload in another project. External projects will provide the independent evidence for L4.

It is important to note that a control in the system's code protects nothing until the team makes it binding where the consequential action occurs. A code-blind evaluator does not become code-blind because the workflow tells it not to inspect the source. The adopter must place the evaluator behind a topological boundary that makes the code physically unavailable. Without that boundary, code blindness is a convention masquerading as a control. Establishing and verifying the required boundaries and controls is part of setting the system up.

Recorded runs show how the system behaved under the conditions tested, but cannot guarantee that the next run will follow the same path. Representative tests, bounded authority, binding controls, recovery, and continued monitoring reduce that uncertainty. They limit what an unexpected result can do and show when the level of trust should change.