More Work. Less Understanding. Who Is Still in Control?

A growing span of responsibility means little if the people accountable can no longer understand, maintain or intervene in the work.

Imagine a manager responsible for a team using several AI agents.

One prepares customer responses. Another reconciles records. A third updates forecasts. Others write code, interpret policies and chase outstanding actions.

More work gets done. The dashboard looks encouraging.

Then a source changes, two records disagree, and an agent completes a task using an outdated assumption. The manager remains accountable.

But can they establish what happened, understand the consequences and intervene before the next action?

We can expand the volume of work under someone’s responsibility faster than we expand their ability to understand and control it. That gap deserves much more attention.

We have a useful parallel in software.

Picture a coding team producing changes with AI assistance. Features arrive faster. Tests pass. Reviews are completed. The system is deployed.

Now ask a different set of questions.

What code is actually running? Does it correspond to the version that was reviewed? Which dependencies and configuration settings affect its behaviour? Who understands why a particular decision was made? Can someone diagnose a failure, safely change the implementation and explain the consequences?

A repository contains source code. A running service also depends on its build, configuration, permissions, data and external services. Understanding one does not establish control over the whole.

The difficult moment comes when the system works, but the people responsible cannot confidently explain why—or predict what will happen when something changes.

AI assistance does not inevitably create this problem. Used well, it can help people inspect unfamiliar code, document decisions and test assumptions. But producing code faster does not, by itself, make that code understandable or maintainable.

We need to measure both.

Otherwise, an organisation can accumulate software faster than it develops the knowledge required to look after it. Each successful release then risks concealing a growing dependency on machinery that fewer people can explain.

The same concern applies to agentic work beyond software.

Responsibility can grow while control shrinks.

A person might once have supervised a handful of colleagues through conversation, observation and shared experience. Now they may be accountable for many automated activities, running concurrently and acting much faster than they can review.

Adding their name to an approval chain does not solve that problem.

They need information they can understand, time to consider it, authority to intervene and a mechanism that actually works.

If hundreds of decisions arrive for approval, the approval process can become a queue to clear. If the explanation is buried in thousands of log entries, the evidence may exist without being usable. If stopping one agent leaves delegated work continuing elsewhere, the stop button has delivered less control than its label suggests.

A cockpit full of instruments is useful only if the pilot can interpret them and the controls still affect the aircraft.

The organisational equivalent is straightforward: can the accountable person recognise a developing problem and change what happens next?

Control also depends on knowing when the world has changed.

An answer produced on Monday may have been reasonable given Monday’s evidence. On Wednesday, a source table changes.

Having access to the latest data is only part of the requirement. Which conclusions depended on the old information? Which completed tasks need reassessment? Who needs to know?

Software presents the same challenge. A component that passed its tests may behave differently after a dependency, configuration or permission changes. The original test result remains a fact about the conditions under which it was obtained. It is not an unlimited guarantee.

“Done” therefore needs a context: the evidence considered, the rules applied, the version examined and the conditions that would require another look.

This makes memory a practical control.

We need to preserve enough of the reasoning and evidence to distinguish “this was justified at the time” from “this still meets the requirement today”.

Without that distinction, organisations can accumulate apparently finished work whose foundations have moved.

We must preserve the ability to challenge the result.

Experienced judgement develops through dealing with incomplete information, making decisions, seeing consequences and receiving correction.

If automation takes over much of that experience, we need to deliberately preserve opportunities to learn. We cannot remove the route through which people develop understanding and then assume a continuing supply of capable reviewers.

For a coding team, that might mean asking a developer to explain a generated change, investigate a deliberately introduced fault or make a modification without relying on the original generating conversation.

For an operational team, it might mean asking a new colleague and an experienced colleague to examine the same case independently, explain their reasoning and identify gaps in the documented process.

Neither exercise makes the participants automatically right. Experienced people carry assumptions. Newcomers misunderstand things. AI can supply a convincing explanation for either.

Disagreement should trigger examination against appropriate evidence. A named owner must resolve the issue and approve any resulting change.

The aim is to develop judgement while testing the process.

Measure the work through to an accepted outcome.

An agent finishing its assigned step is only part of the economic picture.

Someone may still need to check the result, reconcile conflicting records, correct an error or recover from a failed action. In software, someone must maintain the code after the demonstration and deal with the incident after the release.

That effort belongs in the comparison.

If generation becomes faster while checking, repair and maintenance become harder, the claimed saving needs closer examination.

Before work begins, we should be able to explain what an accepted outcome means in language both people and systems can use: the intended result, the evidence required, the tolerances allowed and the conditions requiring escalation.

We should know who can accept it—and what would cause that decision to be reopened.

These are questions shaping my work on Agent Control and digital labour. A useful record should connect the request, authority, budget, evidence, interventions and acceptance decision. Its value lies in helping someone understand and manage the work, including when things go wrong.

Control needs to reach the people closest to the work.

I have long believed in wirearchy: allowing knowledge and coordination to flow through the people best placed to contribute.

A payroll colleague handling an exception may recognise a problem before it appears on a management dashboard. A developer maintaining an awkward component may understand a dependency that the architecture diagram misses.

They need a clear route to challenge an assumption, raise a concern and see whether it was resolved.

Distributed knowledge still needs explicit decision rights. People must know who can change a rule, authorise an exception, stop the work and own the recovery.

There is also a limit to governing by exception. If exceptions arrive faster than people can understand and resolve them, the organisation has exceeded its supervisory capacity. It must reduce the workload, narrow the agents’ authority or increase the capacity to supervise.

My test is simple:

Can the people responsible explain what is running, understand why its results are acceptable, maintain it as circumstances change, and stop or redirect it in time?

If they cannot, increasing output may be increasing exposure as well.

The real achievement is to expand what people can accomplish while preserving their ability to understand, challenge and control it.

That understanding is part of the capability we are building. We should be very careful about spending it to make the next dashboard look better.

Also published on Medium ↗.

This article reflects the evidence and development status at its original publication date.