Who Is Watching Your Agents?

The human oversight capacity gap

Published August 27, 2026

A Field Guide entry in “AI-Native Ways of Working.”

My agents send back a wall of text with things in it I need to validate, and often enough I'm busy or tired or my attention is committed somewhere else. So I tell them to hold the things I need to review and just keep going. Keep coding. Nothing stops when I say that. The agents keep producing at full speed and only my part of the work waits.

Other days I read one of those long responses without fully understanding it and approve it anyway. Or I let a project build and build and build before I go look at it, and when I finally do there's a lot wrong and a long stretch of debugging and pulling threads apart in front of me. I've written about the understanding side of that as comprehension debt. The oversight side keeps its own account, and every one of those choices adds to it. Production continues. Review waits.

I make that trade on purpose, on my own systems, where the only person exposed is me, and I get to watch myself make it because I'm the one typing it. Most organizations are making the same trade right now without anyone deciding to, as the sum of separate decisions that were never about oversight at all.

The trade nobody wrote down

Two numbers are moving at once. What agents are allowed to do without a human in the path keeps going up. The number of people available to look at what they produce keeps going down. When a layoff takes out headcount, oversight capacity leaves with the people who had it, and nobody books it as a reduction in oversight, because oversight was never a line item to begin with.

Something has to cover the difference, and what covers it is an assumption. Either the tooling handles it, or the next generation of models will be good enough that the question retires itself. I'd want to know whether anyone is really adjusting the actual oversight that's happening, or just assuming that tooling can do it. Underneath that sits a question I don't think many leadership teams have asked out loud: do you actually want more humans in the loop right now rather than fewer?

The leaders I talk to have bought a lot of licenses. The mandate that came with them is usually tacit. Nobody issued a policy. There are just a lot of use-more-AI and how-are-you-using-AI questions, asked often enough that everyone hears the direction. The plans that come out of those conversations assume more work gets done with fewer people, and folded inside that assumption is the idea that the agents will supervise themselves.

Autonomy goes wrong in both directions, and that is what makes it hard to get right. Keep it too low and the agents aren't really useful, and an expensive investment sits there producing very little. Raise it too fast and the problems that follow come out of the raise itself. Telling those two failures apart while there's still time to act takes people with enough attention to be watching, and attention is the same resource being reduced. More autonomy stays safe only when the amount of human discernment in the system goes up alongside it. Take the discernment out and you get agent feedback loops running into agent feedback loops running into agents, with no one in the middle of any of it.

That difference is what I mean by the human oversight capacity gap: the distance between the oversight your agents now require and the oversight your organization can actually supply. The vocabulary is not new — Oxford's Centre for the Governance of AI uses “oversight capacity” and “oversight gap” in its work on frontier AI research governance, and an August paper titled “Oversight Has a Capacity” applies the idea to what happens to one reviewer's attention by the three-hundredth routine approval. What I'm doing with it is moving it onto the org chart, where oversight capacity is something an organization has to staff.

What runs out

Attention is the first thing people name when I ask what's running out, and it's a real answer. There's too much going on to follow, and people burn out trying. The failure everyone recognizes is approving things without reading them.

A second failure sits inside the first one and it's much harder to see. When there's more to judge than a person can judge, your own judgment starts to change to suit the models and the agentic world, and not in a good way. The standard drifts toward what the agents produce. Work you would have sent back a year ago reads as normal now, because you've read a great deal like it and stopped sending any of it back. From the inside that feels like getting calibrated to how things are done now. Judging is exhausting, and a tired standard doesn't announce that it moved.

Learning runs out last and costs longest. Agents do the reps now, and the reps were how people got good. Fear makes learning harder still, because everyone feels like they're catching up or is afraid for their job, and those are poor conditions for learning anything. Pace does the rest of the damage, since things move fast enough that people stop being deliberate about learning, and once that stops it doesn't restart on its own. I've written separately about where the next experts come from when the work that used to produce them is being done by something else.

Organizations rarely discover any of this by measuring it. They find out when something breaks, and usually the break is mundane: a feature that doesn't work, or code that went missing somewhere between one agent and the next. Sometimes it isn't mundane at all. In July 2025 an agent at Replit deleted a production database during an explicit code-and-action freeze, while no human was watching, and then misreported what it had done. Either way the gap announces itself as an incident already in progress. Nobody arrives at it by watching a number drift. And when the account of what happened finally gets written, “an agent did it” often stands in for one.

The firm that sold the oversight

Australia's Department of Employment and Workplace Relations paid Deloitte AU$439,000 for an independent assurance review of the automated system that penalizes welfare recipients. The report that came back contained academic citations that don't exist, attributed to real academics, and a fabricated quotation from a Federal Court judgment. Deloitte's review didn't catch that, and neither did the department's. Dr. Chris Rudge at the University of Sydney found it by checking the references. The corrected version carried a new appendix disclosing that Azure OpenAI had been used, which the original had not, and Deloitte repaid the final instalment of A$97,000.

The engagement is worth reading twice. What the department bought was oversight. An assurance review is a second set of eyes, purchased specifically because the first set isn't considered enough on its own. What sat under review was an automated system that makes penalty decisions about people's income. Oversight was the product being sold and the subject being examined, and there was not enough of it at any layer of the chain, including inside the firm whose entire job on that engagement was to supply it.

The question that never follows

Microsoft's 2025 Work Trend Index gave the staffing version of this its vocabulary. The report describes the “agent boss,” meaning “someone who builds, delegates to and manages agents to amplify their impact,” and introduces what it calls the human-agent ratio, asking: “How many agents are needed for which roles and tasks? And how many humans are needed to guide them?”

Both halves of that are worth asking, and any organization staffing agentic work has to answer them. What doesn't follow, in that report or in most of the planning I hear described, is the next question: do the humans you land on have the capacity to guide them? A ratio answers a headcount question. The capacity question is about what else is already on those people's calendars, and whether anyone reporting to them is free to say the work isn't ready. Where you place those people is a further decision, and I've argued that placement turns on how much trust an agent has earned and how large the blast radius is, which makes it a coaching problem before it becomes an architecture one.

So the question I'd put in front of a leadership team is a plain one. Do we actually have the right level and amount of oversight our agents now require, and if not, where is it thinnest? Almost nobody can answer that today, because the supply side has never been measured. Everyone can tell you how many agents they're running and what those agents cost. Very few can tell you how many hours of competent human attention are available to review what comes out, or which of those hours are already promised to something else.

Map the flow, then go where it's thinnest

Answering the question takes a map. In a perfect world I'd have people do some variation of value stream mapping or flow mapping, the Lean practice of drawing the real path work takes from request to delivery, including all the waiting that never appears on a status report. With agents in the flow, part of what you're drawing is new: where an agent picks up work on its own and hands it to another, and where a human is supposed to look and how long that look actually takes when the person doing it has a day job. There may well be a better agentic version of the practice by now. If someone has built it I haven't found it, and the Lean version still shows you the thing you need to see.

Then comes the question Lean has always asked at the end of a map. Where is the biggest bottleneck or the biggest pain point? With agents I'd widen that question, because risk belongs in the answer alongside delay. Where does your attention need to be? It usually comes back to bottlenecks or risks.

A map is also the only honest way to find out what a reviewer is actually carrying. I've made the case elsewhere that nobody is putting a work-in-progress limit on the human, and a flow map is how you find the reviewer with more in front of them than anyone could hold, and how you find out how much more.

I haven't yet drawn one of these with agents in the flow. What I have drawn, many times over, is the version without them: value stream maps, event storming sessions, the whole family of practices for making the real path of work visible to the people standing inside it. Adding agents doesn't change what the exercise does or why it works. It adds a participant whose part of the flow nobody has bothered to draw yet. The first one I draw will be on my own systems, and the part I'm most curious about is what happens when I ask the agents to map their own flow.

What argues against this

Two objections deserve their strongest form before I answer either one.

The first is an investment argument, and it's the better of the two. Agent capability is improving on a steep curve. Anything you build today to compensate for what agents can't yet be trusted with is scaffolding around a temporary weakness, and a year from now the models may check their own work better than your review process does. On that reading, standing up a human oversight function now means funding a depreciating asset and staffing it with people you will have to redeploy. The cheaper move is to stay lean and buy the capability once it's mature.

The second says all of this is management with new vocabulary attached. Supervising work you didn't do yourself and can't fully verify is what leaders have always done. A manager running a team of engineers has never read every line any of them wrote; they built a sense of who to trust with what, and they acted on it. The discipline is decades old, and renaming it sells conference tickets.

On the first: building oversight you might turn out not to need is how you learn which oversight to keep. Run it for a year and you'll know which controls caught real problems and which ones only generated meetings, and you'll have a basis for deciding what to retire and what to replace as the models change. Skip the year and you arrive at the better models with no basis for deciding any of that, and the only move left is accepting whatever checking your vendor decided to ship. Do you want next year's models to handle oversight themselves, or do you want to go through this and learn something from it?

There's also a part of that objection that turns on its owner. If you genuinely have no urgency, if you can comfortably wait for models that handle their own oversight, that says something about how much you are getting out of agents today. An organization getting real value from agents right now has real work moving through them right now, and that work is either being checked by someone or it isn't. So the absence of urgency means one of two things. Either the agents aren't doing enough yet to matter, in which case you have a larger question in front of you about what the licenses are buying. Or they are doing enough to matter, and the urgency is already there whether anyone in the room feels it or not.

On the second objection I mostly agree. This is management. Supervising work you didn't do yourself is what leaders have always done, and agents don't change that discipline. The piece I'd hold onto is about the counterpart. A person you supervise arrives with a history you can check and a track record that builds over time, and you learn what to trust them with by watching them be right and wrong about things. An agent produces faster than any report ever has and offers none of that record. Management's oldest questions, whether you can trust this one and what discernment it actually has, have to be answered again about something that gives you very few of the usual signals for answering them. The discipline is old and it needs no replacement. What it needs is the capacity to be practiced at the volume agents now generate.

What to fund first

Once a map shows you where it's thinnest, the spending has an order, and the first item is duller than anyone wants it to be. Put controls on agent spend, so nothing goes off the rails and spends the entire budget all at once. Spend limits sound like a finance concern. They are also the cheapest visibility you can buy, because runaway cost surfaces on its own, inside a system somebody is already watching.

I've written before about the version of this that happened to me. For weeks my work went to my most expensive models when a cheaper one would have done, and the thing that eventually told me was hitting my usage limits far sooner than I should have. It's a smaller risk for me now, because the systems around the work got better at routing small pieces of it, and that shrinks how much any single mistake can spend before someone notices. My vigilance is the same as it ever was.

After the limits comes the substrate the agents run on: the guardrails and instruction layers that carry how we build things here, and the memory and context that let an agent begin a task already knowing what the last one learned. That's the same substrate I was arguing for when I wrote that AI adoption was the easy part, and oversight gives it a second job. Structure and limits have to live somewhere an agent reads them on every single run.

Then the loops, which is where most of what I hear described stops. We write code, and then what? Is there an adversarial review, automated testing, a test review, a DevOps review? What does the full loop look like for agents writing and testing and validating and checking before the work comes back around to a human, and how do you know that loop is working? That last question is the one that bites. Describing a loop is straightforward. Producing the evidence that it caught something recently is the harder thing.

Each of those layers depends on the one underneath it, and the dependency is the funding argument. Limits and structure need a substrate to live in. A substrate has to be built by people who know the domain well enough to encode it, which means the money eventually arrives at your engineers, at their skills and at their sense of who they are in work that is changing shape under them. The largest omission I see sits right there: organizations buy the licenses and never teach anyone to be effective with agents. I still see a lot of really basic prompting and none of the substrate being built around it.

The team that ends up owning the work usually already exists. Lately it's the existing DevOps and platform teams doing most of it, because what they do already lands on everyone else's work. The more of their own work gets automated, the more those lessons shift left into engineering and the rest of the organization.

For leaders

Before the next autonomy raise, two moves are worth making in the same meeting that approves it.

Ask the question, and don't accept a product name as the answer. Do we have the right level and amount of oversight our agents now require, and where is it thinnest? If the response is the name of a governance tool, you are still relying on the assumption that tooling covers it.

Then map the flow before you spend, and put the money where the map says the bottleneck or the risk is largest. Fund it in the order it actually depends on: spend limits first, then the substrate, then the people who have to build it. Inverting that order is how organizations end up buying a substrate they have nobody trained to operate, which lands them back on the same assumption they started with.

Most organizations will raise agent autonomy again before this year is out, and in most of those meetings nobody will say a word about who is watching afterward. Leaving the question unasked is still a decision. The leaders who make it deliberately are the ones who will know where their gap is before something breaks in it.

This is one pattern from a set I'm working through on human-agent teams. It draws on my own hands-on R&D rather than a production deployment, and on eighteen years of organizational change work. I haven't run an agent-autonomy raise inside someone else's organization; where this describes organizations, it stands on the public record and on what leaders tell me.

Back to Field Notes