Human-in-the-Loop Design for Agentic Development Pipelines

Agentic pipelines don't fail because agents are dumb. They fail because nobody decided, on purpose, where the human is supposed to step in. Most teams bolt approval steps onto a pipeline after it's already running, treating oversight like a compliance checkbox instead of an actual engineering problem. That's backwards. The right intervention points, approval gates, and autonomy levels have to be designed in from the start, or you end up with a pipeline that's either dangerously loose or so bottlenecked nobody wants to use it.

Here's the shift that got everyone here: LLMs used to sit and wait. You'd prompt, they'd answer, done. Agents don't wait. They plan, act, check their own work, and loop back around, often across an entire dev lifecycle. That means an agent today can chain together multiple development actions across a workflow, all without a human typing a single follow-up instruction. That's a real capability jump. It's also exactly why "add a review step at the end" stopped being good enough. Agents working across your IDE, your terminal, Slack, GitHub, and your cloud provider rack up decisions faster than any human glancing over dashboards can realistically track. And things like permissions, sandboxes, and audit logs? Those only work if you planned for them before the agent started running. Try to retrofit them later and you'll find the seams show.

The trust gap shows up in the adoption numbers. Deloitte found that while roughly 30% of organizations are exploring agentic AI, only 11% are actually running it in production. That's not a small gap, and it's not purely a capability problem. It's a control problem. Companies don't trust their pipelines to know when to stop and ask.

What the METR productivity finding reveals about unsupervised autonomy

Start with the number, because it's the kind that stops a conversation: experienced developers using AI coding tools were 19% slower than developers working without them. These same developers had predicted they'd be 20% faster. That's close to a 40-point gap between what people expected and what actually happened.

This wasn't a study of beginners messing around on toy projects. METR ran a randomized controlled trial: 16 developers, 246 tasks, real and mature codebases, and these were people with roughly 5 years of experience on those exact projects. They were using tools at the frontier of what was available between February and June 2025. In other words, skilled people, real work, current tools. And they still got slower.

Why? The paper doesn't say outright, but the shape of the result points somewhere specific. When an agent takes off in the wrong direction, someone has to catch it, explain what went wrong, and re-prompt. That review and correction cycle eats more time than the agent saved by generating code fast in the first place. If there's no structured point built into the workflow where a human is supposed to check in, that oversight doesn't disappear. It just becomes unplanned, unbudgeted review work that piles onto the developer's day without ever showing up as a line item.

Compare that to enterprise teams that built structured adoption around the tool, where organizations have reported meaningful gains in code throughput and pull request cycle time. Same category of tool, wildly different outcome. What's different isn't the AI. It's that those organizations built structured adoption around the tool instead of just handing developers raw autonomous access and hoping for the best.

Put those two studies side by side and the lesson gets pretty clear: the question was never "should agents get autonomy." It's "where do you let them run free, and where do you make them stop and ask first."

The HITL vs. HOTL distinction and why it is a design choice, not a spectrum

Two models get thrown around in practitioner writing on agentic AI, and it's worth being precise about both.

Human-in-the-Loop (HITL): the agent hits a checkpoint and stops. It waits for a human to say yes before it moves forward. The human is physically inside the loop, blocking progress until they act.

Human-on-the-Loop (HOTL): the agent just runs. A human is watching, ready to jump in if something looks wrong, but the agent doesn't wait for permission at each step. Oversight is ambient. It's there, but it's not a gate.

The mistake most teams make is treating these two as if they're the same dial, just turned to different settings, less autonomous on one end, more autonomous on the other. They're not. They're different tools built for different situations. A single pipeline might reasonably use HITL at one stage and HOTL at a completely different stage, and that's not inconsistency. That's good design.

So what's the actual question you should be asking at each stage? Simple: if the agent makes the wrong call here, entirely on its own, what does that cost? And who's positioned to catch it, and when?

Get this wrong in one direction and you waste everyone's time: putting a HITL gate in front of a low-risk, fully reversible action, like renaming a variable or fixing formatting, just trains people to click "approve" without looking. Get it wrong in the other direction and it's worse: leaving a HOTL setup on something irreversible, like a production deploy or a credential rotation, means the team has accepted a real risk without ever actually deciding to accept it.

This section isn't telling you which one to pick yet. It's just making sure you've got the vocabulary and the logic straight before the next section, where the actual mapping happens.

How to map intervention points to task risk and reversibility

Forget task complexity for a second. That's not the variable that matters most. The variable that matters is reversibility. Can this be undone easily, and if it can't, how far does the damage spread?

• Low risk, reversible: code generation inside a branch, writing tests, linting, drafting docs. Let the agent run. Review the output when it's convenient, not before it happens.
• Medium risk, partially reversible: opening a PR, updating a dependency, refactoring code that touches more than one service. Put the checkpoint before the merge, not before the agent starts working.
• High risk, irreversible: schema migrations, production deploys, anything touching secrets or credentials, API calls with real side effects on another system. This gets a hard HITL gate, no exceptions, and the approval has to happen before execution, not after.

There's a principle from hardware design AI research worth borrowing here, sometimes called "Architect-in-the-Loop." The idea is that the human isn't just there to review what the agent produced. The human is a collaborator at the spec stage. If the task has ambiguous constraints, those get resolved by a person before the agent starts, not after the agent has already run off in the wrong direction and someone has to clean it up.

Translate that into a dev pipeline and the takeaway is straightforward: put human input at the front, when requirements, scope, and acceptance criteria are being defined, and you cut down on the mid-run corrections that quietly eat up review time later. Capital One's approach reflects this kind of thinking. Rather than handing agents broad autonomy across the board, the company has deliberately started at the low end of the risk spectrum, picking use cases that matter but are contained enough to actually learn something from.

What most teams skip is the boring part: actually writing down which pipeline stages are reversible and which aren't. Without that map, intervention points get placed by gut feeling. And gut feeling is not a design process.

Dynamic autonomy: adjusting agent independence as trust and context change

A fixed autonomy setting is wrong twice. Set it for average risk and it's too tight for the routine stuff, wasting everyone's time with unnecessary check-ins, and too loose for the genuinely novel or high-stakes stuff, where it should be tighter than default.

Research presented as Hedwig, at the first ACM Conference on Agentic and AI Systems (CAIS '26, May 2026), tackles exactly this. The system adjusts autonomy for coding agents in real time, based on the type of task, how much the developer trusts the agent for that kind of work, and the risk involved. The oversight here is local: it's the individual developer's judgment and context steering how much rope the agent gets on a given task, not some company-wide policy document.

What does that look like day to day?

• Per-task sliders: the developer sets, right when assigning the task, how far the agent can go before it has to check back in.
• Trust that accumulates: an agent that's nailed a certain kind of task repeatedly earns more room to operate on that task type. A new kind of task resets it back to a tighter default. Trust isn't global. It's earned per category.
• Interrupt thresholds: if the agent hits something outside its task spec, it's built to pause and flag it, not quietly make a judgment call and hope for the best.

JLL offers a useful real-world data point on what happens when you don't build this in carefully. The company has been running dozens of agents (34, by their count) in discovery and development, and JLL has noted that AI agents supporting software development actually created more work for humans managing those systems. That's the sneaky cost of static autonomy at scale: the management overhead grows even as the agents get more capable.

For any of this to work, the tooling has to make the current autonomy setting visible. Not buried three menus deep in a config file. The developer needs to see it, adjust it easily, and get a log of what the agent did under that setting. Otherwise "dynamic autonomy" is just a feature nobody uses because nobody can find it.

Approval gates in practice: what HULA and real deployments show about where friction belongs

Atlassian, working with researchers from Monash University and the University of Melbourne, built something called HULA (Human-in-the-Loop LLM-based Agents), presented at ICSE 2025. It's now running internally inside Atlassian JIRA. The framework lets engineers shape and guide the LLM's coding plan and source code for a given task, rather than just reviewing what comes out the other end.

HULA is structured so each agent owns its own objective and works cooperatively alongside human agents, rather than everything routing through one central decision point. Atlassian's engineers have reported that this cuts down development time and effort, especially at the start, when a coding plan first gets drafted and the initial code gets written for straightforward tasks. Worth being honest about the limits too: code quality still trips up in some cases. The gate catches a lot. It doesn't catch everything.

The real insight from HULA isn't the tooling, it's the placement. The approval gate sits on the coding plan, before any code gets generated. Humans shape the plan first. Then the agent gets to run with it. That's a fundamentally different move than reviewing a finished product and hoping you catch the problem before it ships.

Salesforce ran into the opposite lesson the hard way. It launched an agentic support experience and found customers were asking questions the agent flat-out couldn't answer, with responses coming back too slowly. Salesforce has openly said there was "a lot to learn" from that rollout. The fixes came after launch, in response to what broke in practice rather than through intervention points planned in advance. Since making those corrections, the agent has handled more than 2 million interactions.

Line these two cases up and the pattern is obvious: approval gates work best sitting at decision forks, like plan approval, scope confirmation, merge review, not stuck at the very end as an output checkpoint. Reviewing an output after the agent already executed a bad plan is the expensive way to catch a mistake. You've already paid for the work.

There's an anti-pattern worth naming directly: gates that fire constantly on decisions that don't matter much train people to hit approve without reading. At that point the gate isn't control anymore. It's theater. The design heuristic that actually holds up: an approval gate should present a decision the developer can make quickly and correctly, which means the agent has to surface the relevant context at that gate. Not just throw up a button that says "approve?" and call it oversight.

Permissions, sandboxes, and audit logs as structural controls, not afterthoughts

An approval gate only means something if the agent can't simply route around it. Give an agent broad enough permissions and the "gate" becomes a suggestion it's technically capable of ignoring.

Permissions. Agents should get the minimum access their assigned task actually needs, not the developer's full set of credentials by default. Read access, write access, and deploy access are three different things and should be granted per task, not blanket-applied to an agent's identity across the whole pipeline. Tools built around protocols like MCP (Model Context Protocol) make this kind of scoped, programmable permission possible. That's infrastructure work, not a policy memo.

Sandboxes. Any time an agent is running tests, executing a script, or hitting an API, that should happen somewhere isolated, where the side effects stay contained. Getting out of the sandbox and into production should require an explicit, deliberate promotion step, which is itself another intervention point worth designing carefully.

Audit logs. Every action an agent takes needs to be logged with enough context that someone can reconstruct why it happened, not just a record of what happened. And here's the catch: HOTL monitoring, the "watch and step in when needed" approach, only works if a human can actually read that log in reasonable time. A log that requires an engineer to spend an afternoon parsing it defeats the purpose entirely. These logs also feed directly into the trust-accumulation piece of dynamic autonomy. You can't responsibly widen an agent's independence without a track record to base that decision on.

McKinsey's research adds some useful scale to this: 88% of companies report using AI in at least one business function, but only around a third have started scaling it across the enterprise. Agents operating in silos, without shared permission structures and shared audit infrastructure, get harder to govern the more of them you add. That's not a hypothetical. That's what happens when growth outpaces the plumbing.

Cost belongs in this same bucket. Token spend from agentic tools is not the rounding error it used to be. An agent running loose without a spend cap isn't just a budget annoyance. It's a structural risk sitting right next to the permission and sandbox risks.

Configuring agents for your pipeline: rules, prompts, and autonomy parameters

Three layers actually determine how well human-in-the-loop design holds up in practice.

Rules and constraints. What's the agent flatly not allowed to do without asking first? This has to be defined ahead of time, not inferred by the agent on the fly. Concretely: explicit deny lists (no deploying to production, no deleting data, no pushing straight to main, no calling external APIs with real side effects, unless a human signs off). Scope boundaries (which directories, services, or systems is this agent even allowed to touch for this task). Escalation triggers (specific conditions that make the agent stop and ask instead of guessing and moving on).

Prompting for intervention. How you instruct the agent shapes whether it hides uncertainty or surfaces it. Ask it to show its plan before it executes, not just report back once it's done. Ask it to flag explicitly when it's operating outside the task spec or heading somewhere irreversible. There's a real difference between an agent saying "I finished this" and one saying "I made a judgment call here, and you should look at it." The second kind is far more useful, even though it sounds like it's doing less.

Autonomy parameters. How much can the agent do on its own before it has to check in, and does that change depending on the type of task? This is where the dynamic autonomy thinking from earlier actually gets implemented, not just discussed.

The Architect-in-the-Loop principle applies directly here too: the specification a developer hands the agent is itself a form of control. A vague instruction leaves gaps, and agents fill gaps with their own judgment, whether anyone wanted them to or not. A precise specification shrinks that surface area before the agent ever starts working.

One more wrinkle worth flagging: multi-agent pipelines, where one agent hands work off to another. Each handoff is its own decision point, with its own risk profile, and it deserves the same scrutiny as any human-facing gate. An agent quietly trusting another agent's output, with no checkpoint in between, is just autonomy risk wearing a different costume.