Part {n} of 8 in The Last Mile of Enterprise AI, a series on why AI stalls between pilot and production, and how a small embedded team (a tech lead plus a pod) closes the gap.
The industry has a name for the kind of team this series describes. A forward deployed engineer is an engineer who works inside the customer's business instead of at a distance from it, owning an outcome instead of a ticket queue. The role began at Palantir and has become the most talked-about job in enterprise AI. This series describes what such a team does, post by post, and argues that a small senior pod can do it remotely.
Most companies say their AI has a human in the loop. Few can say which human, at which step, looking at what, with the authority to do what. Without those answers the phrase is a disclaimer. With them it is the most useful engineering decision in an AI deployment.
Why the loop exists at all
Today's models are impressive and uneven. They complete long tasks well most of the time and fail in ways that do not announce themselves. An agent does not crash when it is wrong. It produces a confident, well-formatted wrong answer. For any action that touches money, customers or records, someone has to catch that, and for now the someone is a person.
Both extremes fail
Full autonomy in a high-stakes setting produces incidents. Full supervision produces nothing, because it removes the benefit. One engineering guide makes the arithmetic plain: an agent handling 10,000 tasks a day under approve-everything rules needs 10,000 human reviews a day.
And reviews at that volume are not real reviews. One agent builder describes the problem from experience: by his fiftieth approval he had stopped reading and was only clicking. A gate that everyone clicks through is worse than no gate, because it creates a record of oversight that did not happen.
Three positions, not one
The useful vocabulary has three settings.
- In the loop: the agent stops and waits. Nothing happens until a person approves. This suits rare, costly, irreversible actions.
- On the loop: the agent acts, and a person monitors and can step in. This suits frequent, medium-risk work where mistakes can be undone.
- Out of the loop: the agent acts alone, and people look at samples and metrics afterward. This suits high-volume, low-stakes, well-measured work.
Reading a document needs no gate. Drafting a reply may need none. Sending it to a customer may need one. One practitioner's short list of actions that should always wait for a person: deploying to production, sending external messages, moving money, deleting data and changing permissions. The common thread is reversibility. If you cannot undo it, a person approves it.
What a real gate contains
A pop-up that says Approve? is not a gate. A workable definition from one design guide: a stateful checkpoint that pauses the agent before a consequential action, hands the reviewer enough context to approve, reject, narrow or roll back, and records the decision for audit.
- Context. The reviewer sees what the agent wants to do, why, on what evidence, and what it is unsure about. If the reviewer has to redo the work to check it, the gate has saved nothing.
- Options beyond yes and no. Edit and approve. Approve this part only. Send back with a note. Escalate to someone senior.
- A durable record. A pending approval is work in a queue, not a message that disappears. It survives a shift change, and it leaves a trail.
Where to put the gates
Three questions decide it. How bad is the worst outcome? Can it be reversed? How confident is the system on this particular case?
The third is where engineering pays off. A well-built system routes only the uncertain or unusual cases to people: the invoice whose total does not match its lines, the claim that falls outside policy, the document type it has never seen. The routine 90% flows through, and reviewers spend their attention where it changes the outcome.
The part most teams miss
Every human decision at a gate is a labeled example. When a reviewer corrects an extracted field, that is a training label. When they reject an action and say why, that is a test case. A deployment that discards these decisions throws away the most valuable data it will ever produce: examples of its own mistakes, on its own documents, corrected by its own experts. A deployment that captures them improves every week.
That changes what the loop is for. The human is there to stop errors today, and also to teach the system so that fewer cases need a human next quarter. Oversight should shrink over time, on evidence. A sensible rule is to move a task from in the loop to on the loop only after it has passed review at a set rate, for a set period, on a set volume.
The state of practice
In production today, people are mostly still in the loop.
A June 2026 study of 634 enterprise AI teams found mandatory human review in two-thirds of production agent deployments. Governance lags behind: Deloitte's 2026 enterprise survey found roughly one in five organizations with a mature model for governing autonomous agents.
What a senior pod does here
A tech lead maps the workflow action by action and assigns each one a loop position and a trigger. Engineers build the review queue: the screens, the context panels, the routing rules, the audit log. The client's own experts staff it, because they already know what correct looks like. The pod writes the review guidelines with them and tracks how consistently reviewers agree, so a drop in agreement shows up as a number instead of a surprise. Every decision flows back as data.
The hard part is not the screens. It is deciding which actions need a person, and making each review fast enough that the experts actually read what they approve. That is design work, and it is where senior judgment pays off.
The rest of this series builds on that queue. Reliability, productivity, safeguards and custom models all draw on the same stream of human decisions.
Next week: Reliability: from a demo that works to a system you can trust.