Most things should be deterministic not AI Agents at Dubai Airport

This morning I am at Dubai Airport. I booked a taxi from my hotel at 5:43am. By 6:03, I had checked in and passed passport control, which involved me walking through a tunnel of cameras.

No boarding pass scanning. No passport scanning.

So cool.

After a quick monorail, I was in the café ordering my delicious avocado on toast by 6:14.

Twenty-nine minutes in total. Amazing.

Why is it amazing? I would imagine because of a large number of deterministic tools working together behind the scenes.

Right, let’s get into what I am talking about.

Everyone Wants an Agent

Everyone wants an agent.

An agent for this. An agent for that.

You hear someone mention they have an agent to do X and, do not get me wrong, agents are amazing. But they are also unpredictable. Most of the time, you do not want an agent because you do not want unpredictability.

I do a lot of work building software, and I do so in an agentic way. That means I use agents to understand what I am trying to achieve, plan a list of tasks, and then execute those tasks to create a digital thing.

Over the last year, I have built more than 50 tools or apps to help my work and my life.

When I sit down to build one, I need an AI agent with enough reasoning to understand the outcome I want and plan the work. It might need to ask me questions. It might need to point out something I have missed. It might decide that my first idea is not the most sensible route.

Then the nature of the work changes.

For the actual writing of the code, what I need is an LLM, or large language model. An LLM generates text, including code, based on the instructions and context it is given.

I then use a deterministic compiler, as we did before AI, to see whether the code can run. If it cannot, I use an agent to evaluate the error and fix it. The loop continues.

Agent. Code. Compiler. Error. Agent again.

It is a pretty repeatable process.

The agent does not need to improvise every part of the work. Its value is in understanding the problem, making the decisions and dealing with the moments where the predictable process fails.

Agents Build Predictable Things

All of those tools and apps I have built use deterministic code. That means the same input, under the same conditions, produces the same output each time.

Some of the tools have agent or LLM functionality inside them. But for most of them, I used the agent to build me a tool.

A tool I could run again and again.

A tool that did not need to reconsider its entire purpose every time I pressed a button.

This is what I think we are missing in the current conversation.

There is a belief that AI agents can replace everything. We just need to turn every task into an agent and all will be well.

Well, I have news for you.

Most of the time, the useful outcome of agentic work is a process that is pretty deterministic. The agent understands the problem, makes judgements and creates the thing. The thing it creates can then behave predictably.

I think of this as judgement at the top and certainty underneath.

Judgement goes where the work is unclear, the conditions can change or a choice still needs to be made. Certainty goes where the choice has already been made and the same thing should happen correctly every time.

The difficult part is knowing where one should end and the other should begin.

Judgement Sits at the Top

Agents are like people.

Not literally, obviously. But if you have ever worked, lived or partied with people, you will know that rules and processes are what keep us from becoming The Purge every night.

When you start a new job, or a new project begins, you follow a procedure even if you do so subconsciously. There are predetermined steps that you have agreed or learnt.

Some decisions require judgement.

Others have already been made.

We should map agents and processes in the same way.

At the top, we need AI agents using highly capable models. They can understand a problem, consider possible approaches and decide how to proceed. If something is unclear, they can ask questions. Then they can plan and split the goal into tasks.

Those tasks can be handed to smaller agents.

The smaller agents do not need the same level of general capability. They can be given very specific personalisation, a narrow area of focus and a clearly defined objective. That also means they may not need as complex a model.

The structure can continue until we reach a task where no further judgement is needed.

Converting HTML to Markdown, for example, could be handled by code rather than asking an LLM to interpret the request and carry it out each time.

The distinction matters.

An agent is useful when it needs to understand intent, work with incomplete information or choose between possible routes. Code is useful when the route is known.

If it is a one-off task, writing code might feel heavy-handed. Equally, if trust or cost matters, even a one-off task may deserve a deterministic approach.

There is no rule that says every small action must become software. There is also no rule that says every action involving AI must remain an open-ended conversation with a model.

The point is to decide where reasoning is useful and where repeatability is more valuable.

Once that line is clear, the system becomes easier to understand. The agent is not the whole machine. It is the part of the machine that deals with uncertainty.

The Organisation Chart Already Shows Us How

This is no different from the way humans have built organisations.

A CEO or founder has a mission, a skill set and a high-level strategic view of what the business should and can be.

They hire key people to lead different parts of it. Those people hire others with more specific skills and responsibilities. The work keeps moving down through the organisation until it reaches someone carrying out a defined task.

Then, at some point, a person does something incorrectly.

A process is created.

It might be a checklist. It might be a tool or a system. But something deterministic is introduced so the same mistake is less likely to happen again.

The organisation has taken a decision that once sat inside someone’s head and turned it into a repeatable process.

Perhaps a manager used to explain the task every time. Then somebody wrote down the steps. Later, those steps became a form. Eventually, the form became a piece of software.

The judgement did not vanish. It moved.

Someone still decided what the process should be. Someone still reviews the unusual cases. Someone still changes the process when the world around it changes.

But the ordinary case no longer needs to be reconsidered from scratch.

Over the years, as industries have become commoditised, we have created a world of checklists and processes. Sometimes even when a process is not the best answer.

We did this in search of repeatability and confidence.

There is a cost to that. Processes can become rigid. They can survive long after the reason for creating them has disappeared. Anyone who has worked inside a large organisation has probably found themselves following a process that nobody can quite explain.

Still, the underlying idea is sound.

Use people for judgement. Use processes to preserve decisions that have already been made.

So why are we reluctant to do the same with AI?

The Magic Agent Often Writes a Script

At the moment, people want everything to be an agent because agents appear able to do anything. The marketing buzz pushes more of that idea.

But when an agent needs to perform a task, it will often write code and create a deterministic script to carry it out.

The magical agent turns out to be a creator of predictable processes.

Rather like most humans working inside a classic business hierarchy, unfortunately.

That does not make the agent less useful. It tells us where its usefulness sits.

The agent can inspect the situation. It can decide what needs to happen. It can create a method for doing it. When something breaks, it can return to the problem and revise the method.

Between those moments, the method should be allowed to work.

This is where judgement at the top and certainty underneath becomes useful as a way of designing systems. You do not ask whether a workflow should use an agent or code as if the whole thing must be one or the other.

You look at each part of the work.

Where is the goal unclear?

Where might the conditions change?

Where would two sensible people make different choices?

Those are useful places for an agent.

Then you look for the point where the choices disappear. If a task has a known input, a known transformation and a known output, the agent may have already finished its job.

Use judgement where judgement is required. Once the judgement has produced a reliable process, use the process.

The best agent may be the one that knows when the work no longer needs an agent.

Build Judgement at the Top and Certainty Underneath

I have trained more than 2,500 people in AI, and the pattern I keep seeing is that people place AI at one of two extremes.

It is either rubbish or amazing.

Neither position helps much.

AI is a way to digitally replicate parts of what a human does: think, reason and judge. I am not saying it is always the best at those things, but that is the role we are asking it to perform.

Like a human, it should have checklists. It should have tools and services it can call upon. It should be able to achieve goals through deterministic processes rather than reconsidering every small action from scratch.

For people building systems, this means resisting the urge to put an agent everywhere simply because you can.

Start with the parts of the work that genuinely require interpretation.

Define the goal. Let the agent ask questions, consider the problem and plan the route.

Then look for the point where the choices disappear.

Turn that part into code, a checklist, a tool or a service. If the same input should produce the same output, unpredictability is not a feature.

Test the handover between the two. A deterministic tool is only useful if the agent gives it the right information, and an agent is only useful if it knows what happened when the tool fails.

Keep the agent where conditions change or judgement matters.

Keep the fixed process where the work is known, repeatability matters and there is little value in improvisation.

The old way is still the right answer for a lot of work. If a simple script can do the job, use the script. If a checklist makes the process safer, use the checklist. If existing software already solves the problem, adding an agent may only make the system more expensive and harder to trust.

This does not reduce the role of AI. It gives AI a clearer role.

The agent can spend its effort on the parts we could not easily automate before: understanding what somebody means, planning around constraints, handling an unusual case or repairing a process that has stopped working.

The predictable parts can remain predictable.

The Tunnel Should Not Improvise

Back at Dubai Airport, I did not want an imaginative passport-control experience.

I wanted to walk through the tunnel of cameras and arrive on the other side.

No login. No upload.

No agent deciding that this morning might be a good time to try something different.

The intelligence belongs in designing and managing the system. It belongs in deciding what should happen, recognising when the ordinary process is not enough, and dealing with the exceptions.

The experience itself should feel almost boring in its predictability.

That is the question I keep coming back to when I build with AI: where do I need judgement, and where do I need the same thing to happen correctly every time?

The answer will move. A task that needs judgement today may become a reliable process tomorrow. A fixed process may need an agent again when the conditions around it change.

That is fine. Organisations have always moved decisions up and down their structures. AI gives us another way to do it, and perhaps a faster one.

Perhaps the future is not an agent for everything.

Perhaps it is agents building the right tunnels, then knowing when to get out of the way.