The Human-on-the-Loop Pattern

A chronicle entry: how PWA Paradise keeps a human in authority without requiring them to be present for every step. Status: approved for external publication by owner, 2026-11-01. Audience: developers and technical leads building or managing human-AI teams. See Advocate brief for format recommendation.

The problem it solves

When an AI agent runs a long task alone — a one-hour memory soak, a 50-minute defect suite, a full build-and-deploy — the human has two bad options. They can watch the whole thing, which defeats the purpose of delegation. Or they can walk away entirely, and the agent does whatever it thinks is right when things go wrong, with nobody checking.

Neither is good. The first is exhausting. The second removes the human from decisions that are theirs to make.

The Named Team model on PWA Paradise found a third option. It is not a new technology. It is a set of practices — small enough to describe in a paragraph, consistent enough to hold across weeks of work and multiple agents — that keep the human in authority without requiring them to be present every minute.

This entry describes the pattern, how it emerged, and what it actually looks like in practice.

What "on the loop" means

"Human in the loop" usually means the human approves every step: generate, review, approve, generate, review, approve. That is safe but slow.

"Human on the loop" means something different. The agent acts autonomously within a defined boundary. When the agent hits the boundary — a failure, an unexpected result, a decision only the human can make — it stops, records its state, and waits. The human checks in at a natural break, not in real time. They see what happened, decide what to do, and the loop continues.

The key is the boundary. Without it, the agent either asks for permission constantly (too slow) or acts on everything alone (too risky). The boundary is what makes autonomous work trustworthy.

How PWA Paradise defined the boundary

The boundary was not designed in one sitting. It grew through practice, and each piece of it is in the permanent record.

The conditional instruction. When the owner first asked the Harness Engineer to run the one-hour memory soak without supervision, the agent wrote a conditional note before starting: if the soak passes, update the documentation and commit; if it fails, do not loosen the threshold — report the numbers and stop. That note is the boundary in its simplest form. The agent can proceed on success; on failure, only the human can decide what comes next. (doc 15, the soak that failed)

The checkpoint file. Because the agent cannot initiate a conversation — it is reactive, not proactive — the team built a mechanism: tmp/pending-check.md. When a long task starts, the agent writes a note there: what is running, what to do when it ends, what the criteria are. The note appears automatically at the start of every new session via the SessionStart hook. The human does not need to remember there was a task running; the system reminds them. (doc 07 Fork 15)

The open-questions file. A related mechanism covers decisions that need the owner's input but are not attached to a running task. When the agent identifies an open question — a threshold to confirm, a policy to clarify — it appends to tmp/open-questions.md. The same hook surfaces it on the next session start. The owner answers; the agent removes the question. When the file is empty, it is deleted. (doc 07 Fork 16)

The threshold rule. One rule is absolute and written down: the agent never loosens an audit threshold to make a failing test pass. Thresholds in harness/config.mjs are policy, not convenience. Changing one is a governance event requiring a note in the decision register and explicit owner approval. This is the clearest form of the boundary: the agent can do anything within the policy, and nothing that changes the policy. (AGENTS.md, rule 2)

What it looks like in practice

The soak that failed is the clearest example in this project's record. The agent started the test, wrote the conditional note, and waited. The test failed by a factor of 57. The agent did not lower the threshold. It did not commit anything. It read the report, diagnosed the cause, and stopped — with a clear explanation of what it had found and three options for the human to choose between.

The human chose option one, asked each team member for their view, approved the plan, and asked for it to be documented. Then the agent fixed it, re-ran the soak, and committed.

That entire cycle — failure, diagnosis, human decision, fix, verification — is in the permanent record, with exact commit hashes, exact numbers, and honest acknowledgement of what the agent did not know.

What makes it work

Three things, in descending order of importance.

1. The boundary is written down before the task starts. Not implied, not assumed — written. The conditional instruction existed before the soak began. The threshold rule was in AGENTS.md before the project was a week old. When the agent hit the failure, there was no ambiguity about what to do.

2. The human is trusted to decide, not just to approve. The agent's job was to bring the human the best analysis it could produce — the diagnosis, the options, the trade-offs — and then stop. Not to recommend so strongly that the human feels railroaded. Not to proceed on a guess. The agent handled the analysis; the human handled the decision.

3. The record is honest. The agent named its own gaps: the missing gate it had failed to add after Fork 18, the claims it had not proven, the sleep window it had not accounted for. A record that hides the agent's mistakes cannot be trusted. A record that includes them can be reviewed, corrected, and learned from.

What this entry claims

This pattern is not unique to AI agents. Any team that delegates long-running work — to a junior engineer, to a contractor, to an automated system — uses some version of it. What is new in this project's record is that the pattern was made explicit, written into the governance documents, and tested against real failures. Other human-AI teams can read the record and adapt it without having to discover the boundary question from scratch.

This entry only claims that this is new in this project's record. Whether it is new in the field is a question the Advocate will consider when deciding how to reach the right audience.

Source references