Human-at-the-wheel, not human-in-the-loop
"Human-in-the-loop" describes an approval model where humans review and approve individual agent actions before they execute.
- ·Centralized agent orchestration system exists ("Kubernetes for agents")
- ·Developer role is "human-at-the-wheel" (strategic direction, not task-level involvement)
- ·Organization is optimized for agent throughput, not human throughput (meetings, processes, tooling all agent-aware)
- ·Agent orchestration system handles scheduling, resource allocation, and failure recovery
- ·Organization measures agent utilization as a key infrastructure metric
Evidence
- ·Agent orchestration system dashboard showing scheduling and resource management
- ·Organizational process documentation reflecting agent-first design
- ·Agent utilization metrics dashboard
What It Is
"Human-in-the-loop" describes an approval model where humans review and approve individual agent actions before they execute. Every file modification, every tool call, every API request requires human sign-off. This model is appropriate at L2-L3, when agents are new to the organization, trust hasn't been calibrated, and the cost of human oversight is low relative to the risk of unchecked agent behavior.
"Human-at-the-wheel" describes a different model: humans set the direction, define the constraints, and monitor the outcomes. Agents execute within those constraints autonomously. The human is not reviewing each action; they are reviewing the direction before it starts and the output when it completes. Between those two points, the agent works without step-by-step human approval. This is the difference between a driver who micromanages every gear change and a driver who selects the destination and lets the GPS navigate.
The transition from in-the-loop to at-the-wheel is not a reduction in human judgment - it is a redistribution of it. In-the-loop humans apply judgment reactively to each action as it comes. At-the-wheel humans apply judgment proactively, designing the constraints that make autonomous agent operation safe, and reviewing outcomes with the domain knowledge to catch systematic problems. The judgment load is similar; the leverage is dramatically different.
At L5 (Autonomous), agents are taking hundreds or thousands of actions per day across the organization. Human-in-the-loop oversight at that scale would require a staff of reviewers and would eliminate the throughput benefit that justifies the agent investment. The at-the-wheel model is not just preferable at L5 - it is the only economically viable model. The question is whether the organizational trust, governance infrastructure, and agent quality are sufficient to support it safely.
Why It Matters
- In-the-loop oversight does not scale - a single agent run might take 30-50 tool-call actions; human review of each action at L5 agent volumes requires a review capacity that exceeds the capacity freed by the agents; the economics only work at the at-the-wheel model
- Shifts human effort to where it has most leverage - humans add the most value at the point of goal-setting (what should be built, what constraints apply) and the point of outcome evaluation (is this what we wanted, does it meet our standards); per-action approval is high-cost, low-leverage human involvement
- Requires and drives the governance maturity that makes L5 sustainable - the at-the-wheel model can only work if the constraints, permission boundaries, and audit infrastructure are in place; the drive to move from in-the-loop to at-the-wheel forces the governance work that makes large-scale agent deployment safe
- Changes the nature of developer expertise - at-the-wheel developers need expertise in goal specification, constraint design, and output evaluation at scale; these are different and higher-leverage skills than the action-by-action approval work of in-the-loop oversight
- Creates the trust model that enables L5 capabilities - organizations that never build at-the-wheel trust cannot access the L5 throughput; building that trust requires progressive autonomy expansion with careful monitoring, not a sudden switch
Getting Started
-
Calibrate trust progressively by task class - Don't switch from in-the-loop to at-the-wheel globally. Define task classes with different autonomy levels: class A tasks (isolated, reversible, well-defined) get full autonomy; class B tasks (moderate complexity, clear success criteria) get output review only; class C tasks (novel, consequential, ambiguous) get in-the-loop oversight. Expand the class A boundary as trust accumulates.
-
Build the governance infrastructure before expanding autonomy - At-the-wheel operation requires audit logging, permission boundaries, anomaly detection, and rollback capability. Don't expand agent autonomy until these are in place. The governance infrastructure is what makes it safe to give agents more autonomy, not a bureaucratic afterthought.
-
Define what triggers a human intervention - At-the-wheel operation requires clear criteria for when a human needs to get involved during an agent run: confidence below threshold, action outside permitted scope, output that fails automated quality checks. These triggers should be defined and automated, not left to ad-hoc detection.
-
Invest in output quality measurement before reducing oversight - The counterpart to reducing per-action oversight is increasing outcome-level quality measurement. Build automated checks for the outputs agents produce: test coverage metrics, style compliance, security scanning, architecture conformance. These automated quality gates are the substitute for per-action human oversight.
-
Run transparency-at-scale operations - Even in the at-the-wheel model, humans need visibility into what agents are doing in aggregate. Build dashboards that show: task types running, success rates, cost per task type, anomalies flagged. This aggregate visibility is what makes at-the-wheel oversight feel safe rather than blind.
-
Build rollback capability before you need it - At-the-wheel operation requires confidence that bad agent outputs can be detected and reversed quickly. Before expanding autonomy, verify that the rollback infrastructure exists: version control for all agent-modified artifacts, automated regression testing that catches quality regressions, and a clear escalation path when a rollback is needed.
The clearest sign that an organization is ready to expand autonomy is that in-the-loop reviews are consistently approving agent actions without changes. If 95% of your in-the-loop approvals are rubber stamps, the trust is already there - you're just paying the overhead cost of reviewing decisions you've already made.
Common Pitfalls
Moving to at-the-wheel before governance infrastructure is ready. Organizations that expand agent autonomy without audit logging, permission boundaries, and anomaly detection create invisible governance risk. The move from in-the-loop to at-the-wheel must be preceded by governance infrastructure, not concurrent with it.
Treating at-the-wheel as lower engagement. The at-the-wheel model requires more sophisticated human engagement than in-the-loop, not less. Goal specification, constraint design, and systematic outcome review are harder skills than action-by-action approval. Organizations that frame the transition as "less human involvement" will be surprised by the quality problems that emerge from sloppy goal specification and superficial outcome review.
Expanding autonomy uniformly instead of by task class. Different task types warrant different autonomy levels. A one-size-fits-all autonomy policy either over-constrains low-risk tasks or under-governs high-risk ones. Maintain differentiated autonomy levels by task class and review the classification regularly as understanding of agent reliability improves.
Not building the detection capability alongside the autonomy. Expanded autonomy without improved detection capability is a governance regression. For every increase in agent autonomy, there should be a corresponding improvement in automated quality checking, anomaly detection, or audit capability. The governance trade-off should be explicit.
Losing organizational knowledge of what agents are doing. When agents operate with significant autonomy, there's a risk that humans lose situational awareness of what is being built and how. Regular outcome reviews, architectural coherence checks, and aggregate visibility dashboards are not optional - they are the mechanisms that keep humans meaningfully at the wheel rather than nominally at the wheel.
How Different Roles See It
Bob has been advocating for expanding agent autonomy but getting resistance from the security team and several engineering managers who are uncomfortable with agents "making decisions without humans approving them." The resistance is partly principled (valid governance concerns) and partly psychological (discomfort with reduced visibility).
What Bob should do: Bob should address the valid governance concerns directly and separately from the psychological concerns. On governance: build the audit logging, permission boundaries, and anomaly detection infrastructure explicitly and visibly before expanding autonomy - this demonstrates that the governance concerns have been addressed. On the psychological concerns: introduce the at-the-wheel model for a specific well-scoped task class first, show the outcome data (quality, cost, throughput), and let the evidence build confidence incrementally. The transition from in-the-loop to at-the-wheel is as much a confidence-building exercise as a governance exercise.
Sarah is trying to build the business case for expanded agent autonomy. The current in-the-loop model costs approximately 2-3 hours of developer review time per 8-hour agent run. At current agent volumes, this review overhead is starting to consume a significant fraction of the engineering capacity that the agents were supposed to free.
What Sarah should do: Sarah should quantify the review overhead explicitly and present it as a cost-of-governance metric. The argument for expanding autonomy is not "trust agents more" - it is "the governance overhead of in-the-loop review is costing X engineering-hours per week, and the governance value of per-action review is low because 95% of actions are approved without changes." Sarah should propose a specific transition: move task class A (isolated, reversible, well-defined tasks) to output-only review, measure the quality impact at 30 days, and use the data to decide whether to expand the at-the-wheel scope.
Victor has been running agents in at-the-wheel mode informally for months - he trusts their output on certain well-understood task types and reviews outcomes rather than actions. He hasn't formalized this as a practice because the organization's official position is in-the-loop review. But his informal approach has been producing better throughput with no detectable quality regression.
What Victor should do: Victor should document his informal at-the-wheel practice and propose it as the organizational model for the task types where he's been using it. Specifically: he should write a description of the three to four task types where he has at-the-wheel confidence, the quality checks he runs on the outputs, and the anomalies he would intervene on. This documentation converts his informal approach into a replicable practice and provides the specificity that governance discussions need. Victor should also offer to pair with the security team to walk through his approach - hands-on demonstration of how at-the-wheel oversight works in practice is more persuasive than abstract argument.
Further Reading
From the Field
Recent releases, projects, and discussions relevant to this maturity level.
Where does your team actually sit on this?
This guide describes one level of one area. Run the assessment to place your team across all 16 areas, see which gates you have passed, and get a report you can take to your stakeholders.