Get posts like this directly in your inbox.
Subscribe on SubstackHuman-in-the-loop isn't a limitation. It's the architecture.
Last week I wrote about the context problem from the architecture side: more information doesn't automatically produce better output, and a well-built agent needs the right context at the right time.
So - if an agent has good context, can take actions in your platforms, and is producing work that always looks pretty convincing, who is actually checking the work?
Most people still answer that question like it's one big binary decision:
"Do we give AI read or write access?"
I don't think that's the right question.
Drafting a client email is not sending it. Creating draft plans is not the same as writing contracts. Granular optimisations are not the same as turning marketing spend on or off.
Those are different tasks with different levels of risk, reversibility and client visibility. They should not all sit under one giant permission setting.
The wrong mental model
The common thinking currently goes something like this:
"Human-in-the-loop" is a safety net. That last check you keep in place "until the models get good enough" to totally remove humans from the process (if you believe LinkedIn AI fans).
That's not the right way to think about it at all.
Human-in-the-loop isn't the awkward person-based bit you are racing to automate away. It's the underlying architecture that makes the whole thing usable in real life in the first place.
If you run any business, your clients are not paying you because you have access to the same AI model as everyone else. They are paying you for judgement, accountability and the ability to make the right call when something is messy, ambiguous or high stakes.
That doesn't disappear just because the actual implementation work can be done faster.
In fact, it becomes more important. The better these AI tools get, the easier it is for them to produce something polished, plausible and wrong. A smart looking report or dashboard is not the same thing as a good one. A professional looking contract is not the same as an effective one.
The human role is not just "approve it at the end." The human role is what gives the AI output weight.
That's why I don't think full autonomy is the right goal for most companies. There may be cases where it makes sense, but as a model for your whole service, it misses the point. The point is not to remove humans, it's to let them do more high value "human" work, while the repeated tasks that don't require human judgement or skill are taken away.
Where the real value is: seeing the working
The big point here is visibility.
Most of the "human-in-the-loop" conversation right now treats the human as a checkpoint at the end. The agent does its thing, produces a finished output, and then a person either approves it or rejects it.
That is not a human in the loop. That is a human at the end of the loop. Big difference.
The black box problem
Think about how most AI tools work today. You give it a prompt, it "thinks" for a bit, and then it returns something. A report. A recommendation. A campaign plan.
If the output looks good, you approve it. If it looks off, people usually do one of three things: Try to work out where it went wrong; Ask it to "try again but different"; Start again from scratch.
That is the "black box" model. And it has the same problem whether the output is a paragraph of text or a set of actions to take: by the time you see that result, all the decisions have already been made.
Every assumption the agent made along the way - which data it used, which business context it leaned on, which trade-offs it resolved - those are all baked in. You are not reviewing the thinking. You are reviewing the conclusion.
That works fine for low-stakes, easily checked tasks. It falls apart for anything that requires more judgement.
What "in the loop" should actually mean
The most useful agent systems I've built work differently. They don't hide the process and reveal the output. They show the process as it happens.
Here is what that looks like in practice:
The agent starts working and you can see what it is doing. You can see which documents it pulled, which data it referenced, what reasoning it followed, what trade-offs it made.
If it is drafting a client update email, you can see it pulling the latest performance data, referencing the last client conversation, choosing a tone. If it is building a search ad campaign, you can see which keywords it grouped together and why, which match types it chose, what budget split it is proposing.
And you can intervene at any point, not just at the end.
If you spot it referencing the wrong client brief, you can correct it early on in the process. If you notice it missed a constraint the client mentioned last week, add it in while the work is still taking shape.
That is a human in the loop. Not approving a finished output from an opaque process, but actually participating in the process while there is still the chance to shape it, without doing all the manual work.
Why this matters
I keep coming back to this because it changes what "trust" means in practice.
In the black box model, trust is binary. You either trust the output enough to approve it, or you do not. And if you do not, you have very little information about why it is wrong, so fixing it is slow and frustrating.
In the visible-process model, trust builds incrementally. You watch the agent work. You see it making sensible decisions. You correct the ones that are off. Over time, you learn where it is reliable and where it needs guidance - not from testing outputs after the fact, but from actually observing the working.
This is also how you'd typically build trust with a new human colleague. You don't hand someone a brief and then judge them solely on the final deliverable. You work alongside them, see how they think, help them course-correct in real time. And they earn more autonomy over time.
Specific permissions still matter. Giving agents access to draft mode is useful. But the real shift is not "can it draft instead of just recommend?" The real shift is "can I see how it got there, and can I jump in when it matters?"
The coding agent blueprint (again)
This is already standard practice in the tools developers use every day.
When I use Claude Code, I do not type a prompt and wait for a finished answer. I watch it work. I can see it reading files, considering approaches, writing code, running tests. If it starts heading in the wrong direction, I stop it and redirect. If it makes an assumption I disagree with, I correct it mid-flow.
The output is better because I was involved in the process, not because I reviewed it at the end (which is how a lot of software is being built right now...).
The same patterns apply outside of code:
- An agent drafting a client report should show which data sources it pulled and which narrative it is building, so you can redirect the framing before it writes 2,000 words in the wrong direction.
- An agent restructuring a search ad campaign should show its proposed keyword groupings and rationale before it builds out every ad group, so you catch structural issues early rather than redoing finished work.
- An agent writing a contract should show which templates and precedents it is referencing, so legal can flag problems at the foundations rather than in the final draft.
The pattern is the same every time: make the process visible, let humans intervene early, and the output quality improves dramatically. Not because the model is smarter, but because human expertise is actually being applied where it matters most - during the work, not after it.
What this means practically
If you are evaluating agent tools right now, I would add one question to your list:
Can I see how it got to the output?
Not "does it have an audit trail?" - that is a compliance feature. I mean: while the agent is working, can I see its reasoning, its sources, its decisions? Can I step in and correct something before it becomes a bigger problem?
If the answer is no, you are stuck just reviewing conclusions rather than shaping the process.
And if the answer is yes, then the agent permission level question mostly answers itself. You can start with more autonomy in areas where you can see the working and trust the process. You keep tighter controls where the stakes are higher.
Good context gives the agent a better shot at being right. Visible process lets the human catch it when it is not. And that combination makes the whole thing actually work in real life.
That's what I mean when I say human-in-the-loop is the architecture, not the limitation. The human is not there because the AI is not good enough. The human is there because their expertise, applied at the right moment in the process, is what makes the output trustworthy and valuable.