You can run twenty AI agents in parallel. If you have to inspect every decision they make, congratulations: you've invented a very expensive way to become your own bottleneck.
There's a strange thing happening with AI agents.
Everyone is talking about how many tasks they can perform simultaneously.
Five agents.
Ten agents.
Twenty agents, all working in parallel.
One writes code, another tests it, a third updates the documentation, and a fourth presumably creates a presentation explaining how productive the other three have been.
Wonderful.
But I've noticed something in the teams and projects I encounter.
The people getting the most value from agents aren't necessarily those running the largest number of them.
They're the people who have built systems they can actually rely on.
And that changes everything.
Because the real productivity question isn't how quickly an agent can finish a task.
It's how much of its work you're prepared to accept without personally checking every bloody detail.
Congratulations. You've become the bottleneck.
Imagine you have ten agents working for you.
They produce code, reports, analyses, documentation and proposed changes.
Each completes its work in a fraction of the time a person would need.
On paper, this looks magnificent.
Then the results arrive.
You need to read the reports.
Review the code.
Check the calculations.
Verify the conclusions.
Make sure the agent hasn't quietly misunderstood a requirement.
And perhaps explain the entire context again because the next agent has no idea what the previous one was doing.
Suddenly, the agents are waiting for you.
Your attention has become the scarce resource.
The machines can produce work faster than you can safely accept it.
And that's your productivity ceiling.
You can increase the number of agents, improve their models, give them faster GPUs and run them around the clock.
But if every piece of work eventually lands on your desk for a complete manual inspection, your supposedly autonomous system has merely created a much faster queue.
You haven't eliminated the work.
You've moved it.
And in some cases, you've made it worse.
Because reviewing somebody else's complicated work can be more exhausting than doing it yourself.
At least when you do the work yourself, you know what you were thinking.
Where am I still acting as a human proxy?
This has become one of the most useful questions I ask about my own workflows.
Where am I still acting as a human proxy between an agent and the outside world?
Am I copying information from one system into another because the agent can't access it?
Am I manually checking something that a test could verify?
Am I reading logs and explaining an error when the agent could inspect those logs directly?
Am I opening a browser to confirm that a change worked because the agent has no way to observe the result?
Am I repeatedly reminding the system of rules that should already be embedded in its tools?
Every time I find one of these situations, there's a potential opportunity to remove myself from the mechanical part of the process.
But there's a second half to the question.
And it's more important.
How do I remove myself without becoming worried about the result?
Because simply eliminating human intervention isn't the objective.
I can stop checking everything tomorrow.
That would certainly save time.
It might also produce an impressive collection of disasters.
The objective is justified confidence.
Enough evidence that the system behaves appropriately, and enough protection that failures won't become catastrophes.
This is where trust enters the picture.
Trust is slow to build and spectacularly quick to destroy
There's another pattern I've noticed.
A team experiments with agents.
The first results look promising.
Someone becomes enthusiastic.
Permissions are expanded.
More processes become autonomous.
Then something serious goes wrong.
An important file disappears.
A production service breaks.
A customer receives incorrect information.
Or an agent confidently performs an action nobody intended to authorise.
And suddenly the entire team's attitude changes.
Yesterday, AI was the future.
Today, nobody wants it anywhere near production.
All the enthusiasm evaporates.
People return to manual approvals, repeated checks and increasingly elaborate instructions about things the agent must never do.
The problem isn't necessarily that the technology became worse overnight.
The problem is that the organisation granted more autonomy than its verification and recovery mechanisms could support.
Trust was extended faster than evidence justified.
And when it broke, the damage wasn't limited to the immediate incident.
The team lost confidence in the entire system.
That's why I prefer thinking in terms of a trust ladder.
Not a dramatic switch between “ask permission for everything” and “do whatever you like.”
A sequence of increasingly autonomous responsibilities, each earned through reliable performance and effective safeguards.
An agent can first analyse a problem.
Then propose a change.
Then implement a change in an isolated environment.
Then run its own verification.
Then submit a reviewed change.
Eventually, for sufficiently well-understood and reversible operations, it may be allowed to act without individual approval.
Each step requires evidence.
And the ladder should work in both directions.
If the system becomes unreliable, reducing its autonomy isn't an embarrassment.
It's exactly what a well-designed trust model is supposed to do.
You don't really trust the model
This is an important distinction.
When I say I trust an agent, I'm not describing the kind of trust I might place in a colleague or friend.
A model doesn't make a personal commitment to me.
It doesn't accept moral responsibility in the human sense.
And I shouldn't build my operational processes around the belief that it has a particularly nice personality.
I'm relying on a technical system.
Much as I rely on a bridge.
Or an aircraft's autopilot.
I don't need a bridge to have good intentions.
I need it to be properly designed, tested, maintained and operated within its limits.
Similarly, a useful AI system needs predictable behaviour, appropriate constraints and clear accountability.
Philosophers distinguish between trust and reliance, and there's an interesting argument that artificial agents are more accurately understood through reliance, while genuine social trust concerns the people and organisations responsible for their design and operation.
This isn't merely philosophical pedantry.
It changes how you approach engineering.
If I believe reliability is mainly a property of the model, I try to find the model that behaves best.
If I understand reliability as a property of the entire system, I start asking different questions.
What happens when the model makes a mistake?
What does it know?
What can it access?
How will it detect a failure?
What will stop an unsafe action?
Can I see what actually happened?
Can the changes be reversed?
And who's responsible when something goes wrong?
The model is only one component.
And increasingly, it's the most replaceable one.
A new model release may change behaviour.
The assumptions I learned about the previous version may no longer hold.
But good tests, access policies, operational logs, evaluation datasets and recovery procedures can remain.
They provide continuity even as the underlying intelligence changes.
Trust shouldn't have to be rebuilt from zero every time a model gets a new version number.
The system should provide a stable basis for testing and recalibrating it.
Four questions I ask before trusting an agentic system
I've found that most practical confidence problems can be organised around four questions.
They aren't a complete theory of AI safety.
But they're a useful engineering checklist.
1. Does the system guide the agent?
If I repeatedly have to explain the same rules, conventions and context, something is missing from the system.
Perhaps the agent doesn't have access to the relevant tickets.
Perhaps it can't inspect the project's architecture.
Perhaps important constraints exist only in somebody's memory.
Perhaps the tools make it too easy to perform the wrong operation.
The solution isn't necessarily a longer prompt.
The solution may be better context retrieval, clearer interfaces, reusable skills, explicit permissions or tools designed so that unsafe choices are difficult to make.
An agent shouldn't have to rediscover the organisation's operating rules every morning.
The system should make those rules available where they're needed.
And when possible, enforce the critical ones rather than merely describing them.
2. Can it observe what actually happened?
This is where many agentic workflows fail.
The agent writes code.
Then announces that the task is complete.
Lovely.
But does it know whether the application starts?
Whether the new feature actually works?
Whether the API returned the expected result?
Whether the change increased error rates in a downstream service?
Whether the supposedly successful operation failed somewhere else?
If I have to perform all those checks manually, I'm still part of the execution machinery.
The agent needs appropriate sensors.
Logs.
Traces.
Metrics.
Tests.
Browser access where relevant.
Temporary test environments.
And sometimes visibility beyond the immediate project.
A service can pass its own tests while breaking the system that depends on it.
A useful agent needs ways to detect that.
A confident sentence saying “everything works” isn't evidence.
A successful, relevant verification is.
3. Is failure cheap enough?
Suppose I want to leave an agent working overnight.
What's the worst thing it can do?
Not theoretically.
In the actual environment where it will run.
Can it delete important data?
Can it expose credentials?
Can it modify production?
Can it send messages to customers?
Can it change billing or infrastructure?
And if it makes a mistake, how quickly can we recover?
This is where isolation, scoped credentials, feature flags, immutable backups, staged rollouts and rollback mechanisms become important.
The goal isn't to prevent every possible error.
That may be impossible.
It's to prevent ordinary errors from becoming unacceptable losses.
If the consequences of failure are too large, the answer may be to restrict the task until the safeguards are adequate.
That's not a lack of ambition.
It's responsible engineering.
4. Does the system learn from failures?
Suppose an agent makes the same mistake three times.
We can remind it again.
Write another paragraph in the prompt.
Add a warning in capital letters.
Perhaps explain that this is extremely important and we would be terribly disappointed if it happened again.
Or we can ask a better question.
Why is this mistake still possible?
Should there be a test?
A linter rule?
A schema validation?
A permission boundary?
A tool that makes the correct operation easier than the incorrect one?
I like thinking of automated checks as accumulated organisational experience.
In a sense, every good lint rule records a previous reason not to trust an unchecked action.
The system encountered a failure.
Someone understood it.
And they converted that understanding into a reusable constraint.
That is how reliability should improve.
But there's a subtlety here.
Not every failure deserves an immediate one-off rule.
A rushed hotfix can solve the observed problem while introducing a new one.
Sometimes it's better to collect several failure cases, understand the underlying pattern and create a more general safeguard.
The point is to improve the system, not simply grow an impressive collection of warnings.
A small hook made a surprisingly large difference
I remember the early days of using Claude Code with broad permissions.
There was an uncomfortable trade-off.
I could approve every operation manually.
Very safe-looking.
Also rather annoying.
Or I could use --dangerously-skip-permissions and allow the agent to proceed without constantly interrupting me.
The name was not particularly reassuring.
And for good reason.
The more autonomous option could execute destructive commands without asking first.
I wanted the productivity benefit.
I didn't particularly want to discover that the agent had misunderstood something after it deleted the wrong files.
Then I found cc-safety-net.
It's a pre-execution hook that inspects tool calls and blocks certain dangerous operations before they run.
Destructive Git commands.
Dangerous filesystem operations.
Attempts to read sensitive credentials.
This was useful because the protection existed outside the agent's own intentions.
I didn't have to hope the model would remember a warning.
The hook could independently refuse the operation.
That changed the practical trade-off.
I could allow more routine autonomy while retaining a separate barrier against known dangerous actions.
Of course, the hook isn't a complete security sandbox.
It doesn't make every possible command safe.
And it can't protect against every kind of mistake.
But it demonstrates the principle.
A small, deterministic safeguard can create more usable autonomy than another thousand words of instruction.
Claude Code has since introduced an auto permission mode that uses additional checks to decide which actions can proceed.
It's a useful development.
But it doesn't eliminate the need for other controls.
And it's interesting that a separate safety hook can still occasionally catch something worth blocking.
That's defence in depth.
Not because every individual protection is perfect.
But because the system doesn't depend entirely on any single one.
Trust becomes more complicated in a team
For an individual developer, the problem is already interesting.
For a team, it becomes considerably stranger.
Here's a question.
Have you ever been the first person to read a long document supposedly sent to you by a client or manager?
Not the first person in your department.
The first human being to read it carefully.
Perhaps an AI system drafted the document.
Someone forwarded it.
Another agent summarised it.
A third turned it into a ticket.
And eventually you received ten pages of requirements that nobody had really examined.
Now imagine the same process happening across an entire organisation.
Documents generated by agents.
Reviewed by other agents.
Converted into plans by agents.
Implemented by agents.
Reported on by agents.
At some point, a human has to know whether the system is operating correctly.
But that doesn't mean a human must manually repeat every step.
It means the organisation needs shared rules for evidence, review and accountability.
Which decisions can be automated?
What must be independently verified?
Who approves high-risk changes?
How is uncertainty reported?
When must the process stop and ask for help?
And what happens if different agents produce conflicting conclusions?
Without a common answer, every team develops its own informal trust model.
Which usually means that someone approves everything, someone checks nothing, and everyone assumes the other person has handled the dangerous parts.
Not ideal.
Verification is becoming the real productivity infrastructure
This is why I think verification is one of the most important areas in agentic engineering right now.
Not just better models.
Better ways to determine whether their work is correct.
Unit tests, naturally.
But also integration tests.
Architecture tests.
Mutation testing, which checks whether the tests can detect deliberately introduced faults.
Independent agents that try to break an implementation.
Temporary environments where changes can run safely.
Evaluations against known failure cases.
Checks that examine actual behaviour rather than merely comparing source files.
And monitoring that continues after deployment.
The aim isn't to build an elaborate verification system for every trivial operation.
That would simply replace one bottleneck with another.
The aim is to match verification to the risk and make it as automated, cheap and repeatable as practical.
A formatting change doesn't require the same scrutiny as a database migration.
A draft internal report doesn't carry the same consequences as a message sent to thousands of customers.
And an autonomous overnight process should have more robust boundaries than an agent working interactively with someone watching.
Autonomy scales when the work becomes verifiable.
Not necessarily perfectly verifiable.
But verifiable well enough for the consequences involved.
The irony of making automation too reliable
There is another side to this.
And it's considerably less comfortable.
In 1983, Lisanne Bainbridge published a paper called Ironies of Automation.
It was written about industrial automation, long before today's language models.
But one of its central observations has become remarkably relevant again.
As automation takes over routine operations, humans are increasingly left responsible for unusual situations.
The very situations they have the least practice handling.
Think about it.
If an automated system works almost all the time, people stop performing the underlying tasks.
Their familiarity with the process gradually weakens.
Then something exceptional happens.
The automation encounters a condition it cannot handle.
And suddenly the human is expected to intervene.
Quickly.
Correctly.
In a system they no longer operate every day.
That's a serious design problem.
And the more autonomous AI agents become, the more important it may be.
If almost everything is covered by automated checks, failures will often occur in the gaps.
Unanticipated interactions.
Incorrect assumptions.
Dependencies nobody documented.
Cases that don't fit the existing tests.
And when that happens, someone needs to understand the system well enough to investigate.
Not merely read the agent's explanation and hope it sounds convincing.
This is why I don't believe successful automation allows organisations to stop investing in human expertise.
Quite the opposite.
The remaining human interventions may become less frequent but more demanding.
We need people who understand the architecture.
Who can recognise when the evidence is incomplete.
Who know how the system can fail.
And who can challenge the assumptions embedded in the automated checks themselves.
Otherwise, we risk building machines that operate beautifully until the one moment when a knowledgeable human is most urgently needed.
And discovering that we stopped developing knowledgeable humans several years earlier.
The goal isn't maximum trust
There's a temptation to describe the future as a world where we trust AI agents completely.
I don't think that's the objective.
Complete trust would be a strange goal for a system that can make mistakes, misunderstand instructions and encounter unexpected conditions.
The objective should be calibrated trust.
Or, more precisely, justified reliance.
Trust the system where its performance and safeguards justify it.
Restrict it where they don't.
Increase autonomy when evidence supports the change.
Reduce it when new risks appear.
And always preserve a way to understand what happened.
Sometimes the correct response is to let the agent proceed without supervision.
Sometimes it's to require a review.
And sometimes the correct response is not to give the agent the task at all.
A mature system should support all three possibilities.
Because the purpose of trust engineering isn't to make us feel comfortable.
It's to make our confidence correspond to reality.
The model is replaceable. The system is the product.
This is the conclusion I keep returning to.
The most productive people working with AI agents aren't necessarily those who know the cleverest prompts.
Or those who run the largest number of concurrent sessions.
They're the people who gradually build dependable working environments around the models.
Contexts that don't have to be explained repeatedly.
Tools that expose the right information.
Permissions matched to risk.
Verification that runs automatically.
Failures that produce better safeguards.
And a reliable way to recover when things go wrong.
The underlying model will change.
It may become dramatically more capable.
It may also acquire new habits, new failure modes and new limitations.
But the organisational knowledge accumulated around it should survive.
And improve.
The productivity breakthrough isn't simply getting agents to do more work.
It's being able to accept more completed work without personally repeating it.
That's when the human stops acting as a permanent intermediary and starts concentrating on things that genuinely require human judgment.
Not approving every command.
Not rereading every line.
Not manually checking what a script could establish in seconds.
But deciding what matters.
Understanding unusual situations.
Designing better systems.
And taking responsibility for the decisions that deserve it.
The future of agentic productivity isn't about trusting machines more.
It's about building systems that give us fewer reasons to distrust them.
And knowing exactly when we still should.
For the organisational side of this shift, see Congratulations. You're a Manager Now. So Is Everyone Else.. For its implications for developers, see The Software Engineering Premium Was Never a Lifetime Subscription. I describe my own workflow in How I Work With AI Agents in 2026.