Close the Loop
It looks like a favour you do for the AI. It is a demand the AI makes of you.
Give a capable person a task and they do something you rarely notice. They check their own work. They run it, they look at it, they catch the obvious mistake before they hand it over. We do it so automatically we forget it is a step.
AI does not do this unless you build it a way to.
That is the part of agentic AI nobody puts on a slide. We talk about how much it can do on its own, how much you can hand over. But handing over the doing is not the hard part. The hard part is that the AI cannot tell whether what it did was any good, not unless you give it a way to find out.
The loop
This is what I have started calling closing the loop.
When AI writes code, the closed loop is simple to picture. It writes the code. It writes a test. It runs the test. The test fails, so it knows the code does not work yet. It goes back, edits the code, runs the test again. And it keeps going round that loop until the test passes. Only then does it know the job is actually done.
The same idea applies to almost anything, once you look for it. If AI is building a deck, the loop is a look at the rendered slide to catch what broke, the text that overflowed the box, the chart that came out wrong. If it is writing an article, the loop is firing a set of reader agents at the draft and reading what comes back. This article went through exactly that. Two readers, told to be blunt, telling me where it dragged and what they did not believe. The shape is always the same. Do the work, check it against something real, feed what comes back into the next pass.
So the discipline is this. For every task you hand to AI, you have to find or invent a way to close the loop. Not as an afterthought. As part of the task.
A demand, not a favour
Here is what took me a while to see. Closing the loop sounds like something you do for the AI. A favour. A bit of plumbing you set up so the tool can run.
It is the opposite. It is a demand the AI makes of you.
Because to close the loop, you have to be able to say, in a way a machine can check, what done and correct actually means. A passing test. A clean layout. A reader who got the point. In every case you have to make your definition of success concrete enough that something other than your own gut can confirm it.
That turns out to be the hard part. Far harder than any prompt.
Done was always a feeling
And here is the part I find uncomfortable. Most of us have never done this, not even for our own work.
Be honest about how done usually gets decided. It looks right. It reads well. I am happy with it. The finish line lives in your head, unspoken, and you cross it by feel. That was fine as long as you were both the worker and the judge. The standard never had to leave your head.
Hand the work to an agent and the arrangement breaks. The agent can do the task. It cannot reach the standard you never wrote down.
I think this is why so many people say AI does not work for what they do. The real situation, often, is that they were running an open loop all along. Grading themselves on instinct, and getting away with it, because no one ever made them name the instinct. AI did not introduce the gap. It just stopped politely pretending the gap was not there.
We knew this as delegation
If this feels familiar, it should. It is exactly what good delegation always looked like.
When you hand something to a person, you have two choices. You can give them a list of steps to follow blindly, which rarely works and never scales. Or you can give them a clear goal and a clear definition of what hitting that goal means, and then let them work out how to get there. The good version was always the second one. The person loops on their own until the goal is met.
Closing the loop with AI is the same idea, pointed at a new kind of worker. A goal it understands, a definition of done it can check itself against, and the freedom to keep going until it gets there. We already knew how to do this. We just did it with people, and most of us were not very good at it even then.
The wrong finish line
There is a catch, and it is a sharp one.
With a person, the loop is slow. They go away, they work, they come back, and only then do you find out how it went. That slowness is annoying, but it hides a gift. It gives you checkpoints. You catch a wrong direction at the one week mark, because the person surfaces, and you move the target before much is wasted.
With AI the loop is fast and nearly free. It can write, test, fail, and rewrite many times over while a person is still reading the brief. That is the whole promise. But speed cuts both ways. The agent will sprint to whatever finish line you drew, and it will sprint to the wrong one just as happily as the right one.
I saw this on a team recently. The loop closed perfectly. The code ran, the results came back correct, the tests passed. By every measure that was actually written into the loop, the job was done. Except one measure was missing. Nobody had checked for cost. The feature quietly fired close to a million API calls against an expectation of ten thousand before anyone noticed. The AI hit the finish line exactly. The finish line was in the wrong place.
What checks the loop?
Which leaves a harder question than the one we started with.
When a team ships thirteen thousand lines of code in a week, nobody is reading every line. The old way of trusting work, reviewing it yourself or trusting the track record of the person who did it, does not survive that volume. So the trust has to come from somewhere else. It comes from the loop. The passing test is the trust. You are no longer trusting the code, or even the AI. You are trusting the thing that checks them.
And that quietly changes the most important question you can ask. It used to be, is this code good. Now it is, is this test actually testing the right thing. A weak test that passes is far more dangerous than weak code that fails, because the weak test turns bad work into trusted work without anyone noticing.
So the job moves up a level. Off the work itself, and onto the thing that decides whether the work is done. Most of us are still reading the output. The harder and more useful skill now is checking the loop. Because once you trust the loop, you stop looking. And whatever the loop forgot to check is exactly what will get through.
Which is where the honest version of this gets uncomfortable. If I cannot trust the work because there is too much of it, and I trust the loop instead, then what checks the loop? It is the same problem, one level up. The volume that broke manual review of the code will, sooner or later, break manual review of the tests too.
I do not have a clean answer to that. I am not sure there is one. But here is what I think is true. The judgement that used to be spread thin across every line does not disappear. It concentrates. It moves off the thousand small questions, is this line right, and onto a few large ones, is this the right thing to be measuring at all. There is less of it to do. Every piece of it matters more.
So the skill that becomes rare and valuable is not reviewing faster. It is knowing what good actually means, clearly enough to put it into a check that someone else can trust. That was always the real skill. The volume just made it impossible to fake any longer.

