What leaves the human loop
One test decides what an agent can own — whether the input can be delivered into an interface. Three data cases and three ways out-of-the-loop fails.
Updated 2026-10-304 min read
Arguments about automation usually turn on model capability: can it read this, can it reason about that, how does it do on the hard cases. The division of labour between a person and an agent is not settled there. It is settled by one question: can the input this task needs be delivered into an interface? If it can, the task can leave the loop. If it cannot, the task stays with a person, however capable the model is.
Note what the test answers. It answers who does the work, not whether the AI is good enough. A task can sit well inside a model's ability and still be a poor candidate for leaving the loop, because the context it depends on lives somewhere the interface cannot read.
Five inputs that never make it through
The inputs that cannot be delivered form a short list. Notes stuck to a physical environment. Judgement carried in dialect and spoken shorthand. The real-time reaction between two people in a room. The difference between the documented process and the executing one. Metaphors and half-sentences left behind in old documents and by people who have already left.
Every item is a context problem, not an intelligence problem. None of them says the model is too weak. Each says the interface cannot see the thing the judgement depends on.
Three cases
Structured inputs — regular tables, messages, fields, protocols — are readable, processable and monitorable. They can leave the loop today.
Unstructured inputs — handwritten notes, private spreadsheets, dialect, muscle memory — have to be made explicit first. That making-explicit is the actual work, and it is the part most often under-priced, because it looks like documentation and behaves like engineering.
Pseudo-structured inputs — regular in form, describing the SOP version rather than the executing one — have to pass a version comparison before anything is built on them. Skip that step and the automation runs perfectly on a process that does not exist.
Three failures, one structure
The three canonical out-of-the-loop failures are easy to state. The automatic approval misses the one item that should never have been approved. The automatic quality check misses the one rework ticket that signals a broken batch. The automatic alert misses the one 2 a.m. event that mattered.
Different tasks, identical structure: in each case the context that would have caught it appears only on the exception path, and the exception path was never captured in the interface. The model was not too weak. The interface was too narrow.
That has a direct consequence for how these systems get built. The happy path is where you test, because the happy path is where the examples are. The exception path is where you fail, because the exception path is where examples are missing by definition. The precondition for going out of the loop is therefore not accuracy on a test set. It is that the context the judgement needs has been fixed somewhere the interface can read before the person steps out.
The human in the loop that is not one
A confirmation button is not a control. When approval requests arrive faster than a person can think about them, approval becomes a reflex: Anthropic telemetry reports that users approve around 93% of permission requests, which describes attention running out rather than trust. The fix is not a sterner warning. It is to move the boundary into the system — default deny, and let the exceptions be the thing that asks for a person — rather than to rely on a human noticing.
The question to put to any "human review" step is what that human would have to know in order to disagree. If the answer is "everything the system knows", the review is decoration.
The unit: a seat
The unit of staffing is not a person and not an agent but a seat: one human plus one paired agent. The four layers are worth keeping straight, because their replaceability differs. The soul is the judgement and the memory that can be carried; it is not replaceable. The bone is the task structure, the criteria and the eval set; it can migrate. The flesh is the specific skills and toolchain; it can be replaced. The skin is the interface and the channel; it can be replaced too.
The rule that follows is short: shells can be swapped, the soul has to stay. An agent rebuilt on a new model, having lost the criteria and the eval set, is a new hire with no memory, whatever the benchmark says.
Context, in five standards
Whatever context is fixed into the interface has to be relevant to the judgement, sufficient for it, isolated so that one task's failure cannot contaminate another's state, economical enough that its cost is counted, and traceable back to a source. These five are the quality bar for the extraction work. They live inside the delivery method rather than beside it — the five-stage delivery method is where each one gets checked.
The test, in practice
Write down the inputs the task needs, one per line, and against each name where it currently lives. If any line reads "in her head", "in the group chat", or "in a document that no longer matches the work", that input cannot leave the loop yet — and shipping anyway is not automation. It is deleting a checkpoint and calling the deletion a speed-up.
Sources and further reading
- Dashen.Wang、黄小木(Jayce Huang)、Roland Wayne《FDE 现场工程手册》 — CC BY-SA 4.0;本节为改写与评注,改编部分同样以 CC BY-SA 4.0 提供
- 范冰《FDE 前线部署工程师》:观点启发自其降门槛手法与所转述的 Anthropic 权限批准遥测,未取原文表达
This article is original analysis by FDE Wiki. Frameworks and case material that originated elsewhere are credited below.