Making sense of AI agents

Whenever people bring up AI agents, they think about AI that can handle a process by magic, and everyone else goes with it and moves on just as quickly. It’s commonplace now to assume an AI agent just handles the process. It’s less commonplace to understand what “AI agent” actually means.

I think the easiest way to understand one is to imagine bringing in a contractor for a piece of work. You give them a brief, a laptop, access to the building and accounts for the systems they’ll need, then you explain what they can decide for themselves and who they should speak to when the work moves beyond what they were brought in to do.

Different products draw the line around agents in slightly different places, although the part they share is software that uses an AI model to work towards a goal over several steps, choosing an action, seeing what happened and using that new information to decide what to do next until it completes the task, reaches a limit or needs to send the work to a person.

The same contractor also helps explain the difference between an agent and the things around it, because a chatbot’s closer to somebody who waits at a desk for the next question, while a fixed workflow gives them a route where the possible branches have been chosen in advance. The agent receives a brief and has some freedom to work out the next step from what it finds, which helps because plenty of work changes as soon as you look closely at it, although many real systems use all three at different points in the same process.

Chatbot Waits for the next question

Fixed workflow Follows routes chosen in advance

AI agent Chooses from what it finds along the way

What we give the agent

If we brought in a contractor and gave them a laptop with no accounts, there’d be very little they could do. The laptop matters because of what it lets them reach, so access to a document library lets them find information, access to customer records lets them see private details, and permission to edit those records lets their decisions change something for another person.

The tools attached to an agent work in much the same way because a model can suggest that a record should be updated inside a conversation, while an agent with the right tool may be able to make the change itself. Reading and editing can sit beside each other in a list of permissions even though they place very different amounts of trust in the system.

Watching an agent find an answer and update a test record can prove that the connection works, while suitability only becomes clear once we understand the work, the permissions and whether the agent should make that change at all across hundreds of ordinary uses.

Along with the laptop and access, the contractor gets a brief that explains the outcome, some instructions for familiar situations and boundaries around the decisions they can make. The model uses those same kinds of inputs when it reads the goal, chooses a tool and receives the result. A search might return a policy, an account lookup might reveal a restriction and an attempted update might return an error, with each result becoming part of what the model sees before it decides what to do next.

This means the agent also needs some way to recognise when it’s finished, when another attempt makes sense and when the work has moved beyond it. If a contractor couldn’t open a system, we’d expect them to try something sensible and then ask for help, and we’d have a very different reaction if they kept trying other ways into the account or found a second system and decided its information was close enough.

An agent takes its cue from the way the work’s been designed, so instructions can shape how it approaches familiar situations, permissions can restrict the actions available to it, and stopping conditions can return the work to a person. An instruction to complete as many requests as possible will create different behaviour from one that treats uncertainty as a valid reason to hand the work over, even when both agents use the same model and tools.

ContractorBriefThe outcome and boundaries

AI agentGoal + instructionsWhat the agent works towards

ContractorLaptop + accountsThe places they can reach

AI agentTools + permissionsWhat the agent can read or change

ContractorWork, check, adjustEach result changes the next step

AI agentAct, observe, repeatThe next step comes from the result

ContractorSupervisor + handoverWhere judgement or access ends

AI agentApproval + stopping pointWhere the work returns to a person

What happens when the request changes

Imagine the contractor’s been asked to help with customer address changes when a customer sends through a new street and unit number but leaves out the postcode, and the surname on their message differs from the one on the account.

The contractor might ask for the postcode, check whether the customer previously used another surname and compare the answer with information held elsewhere. An agent with the right tools can do something similar, using each result to choose the next action as the request moves beyond a route that could have been written into a fixed workflow beforehand.

Now imagine another system contains a restriction saying that this kind of account needs approval from a second person before the address can be changed. The request began as missing information and has now turned into a question about which rule applies and who’s allowed to continue.

A contractor brings their wider understanding of the workplace into that moment, so they may remember something said during induction, recognise the restriction as unusual or notice that the customer sounds distressed and decide to involve somebody more experienced. They can also understand that their access carries trust and that using it will make them responsible for what happens next.

The comparison starts to run out here, because an AI agent works from the patterns available to its model, the instructions it’s received and the information returned by its tools. It can produce a plausible next step without sharing the contractor’s experience of responsibility, workplace norms or the person who’ll live with the decision.

The design needs to carry some of what the human brought to the work, so narrow permissions could allow the agent to gather the information and prepare the case while reserving the change for somebody else. A stopping condition could recognise the restriction and hand the request over, while a record of the steps already taken could help the next person see how the case reached them.

When those things are missing, the agent may keep going because the goal still appears unfinished, which could lead it to decide that the matching address is enough evidence, update one system while leaving another unchanged, or keep searching until it finds information that supports the action it was already trying to take.

This part’s unlikely to appear in a clean demonstration, because the first successful request proves that the expected path works. The hundredth ordinary use tells us whether the instructions still make sense across varied requests, whether failed tools lead somewhere sensible and whether the same uncertainty keeps reaching people in a form they can actually resolve.

What reaches the person at the end

When a contractor reaches the end of their access or judgement, a useful handover carries the work they’ve already done. The next person needs to know what was requested, which records were checked, what conflict appeared, whether anything changed and why the contractor stopped.

An agent needs the same kind of handover, although a box labelled “human review” can make it look much smaller than it feels to the person inside it. A short summary may leave them reconstructing the case before they can make a decision, and an action that’s already happened may add the work of understanding whether it can be reversed.

The mix of work reaching them changes as well because once the agent completes more of the ordinary requests, the remaining queue contains a greater share of ambiguous and sensitive cases, which creates the kind of work described in The exceptions were the job: fewer straightforward completions, more responsibility in each decision, and less contact with the normal cases that once helped people notice when something had changed.

This belongs inside the explanation of an agent because the goal, access and stopping conditions decide the state of the work when a person receives it, shaping the automated part of the process and the job that forms around its edges at the same time.

What I’d ask in the room

If we were bringing in a contractor, we’d want to know what they’d been asked to achieve, which parts of the business they could enter and who would supervise the decisions that carried more risk. The same thought gives us a more useful way to talk about an agent:

• What’s the agent trying to achieve, and how does it know when it’s finished?
• What information can it read, and which records or systems can it change?
• Which actions need approval before they happen?
• What does it do when two sources disagree or a tool fails?
• How long can it keep trying before it hands the work over?
• What context reaches the person who takes over?
• Who notices when the same mistake starts to feel ordinary?

Those answers tell us much more than whether a product has an agent inside it, because they describe the piece of work being trusted to the system and the responsibility that remains with people. They also bring the conversation back to the contractor whenever the technology starts to feel abstract: what did we ask them to do, where did we let them go, and what did we expect them to understand without asking us?

I’d want someone to leave this explanation feeling able to stay in the room the next time an agent is proposed, especially if they’ll be using it, supervising it or receiving whatever it leaves behind. The engineers can explain how it’ll be built, but everyone affected by it deserves enough understanding to question the brief, the access and the handover before those choices become part of their day.