AI Agents: What Changes When Software Can Act

An assistant answers. An agent acts.

Ask an assistant to reconcile last month's invoices and it explains how you might do that. Ask an agent and it opens the accounting system, pulls the invoices, matches them against bank transactions, flags the six that don't reconcile, and drafts an email to the supplier about one of them.

That difference — from producing text to taking actions in real systems — is the entire subject. It is also why agents deserve more caution than any other application of AI. A wrong answer is embarrassing. A wrong action has consequences you have to undo.

What an agent actually is#

Strip away the marketing and an agent is a loop:

Goal ──▶ ┌─────────────────────────────────┐
         │  1. Decide what to do next      │
         │  2. Use a tool to do it         │
         │  3. Look at what happened       │
         │  4. Done? ── no ──┐             │
         └───────────────────┼─────────────┘
                    yes      │
                     ▼       └── repeat
                  Result

Four components make it work:

• A goal — what "finished" means. Vague goals produce wandering agents.
• Tools — the actions it can take. Query a database, send an email, call an API, write a file. An agent with no tools is just a chatbot.
• Memory — what it has already tried, so it doesn't loop.
• A stopping condition — how it knows to finish, and what to do when it cannot.

The model supplies the judgement about which tool to use next. Everything else is ordinary software engineering, and that's the part that determines whether the thing works.

Where agents genuinely earn their place#

The pattern that pays is: a task with many steps, clear success criteria, and tolerable cost of a mistake.

• Triage and routing. Read an incoming request, classify it, gather context from three systems, route it with a summary. High volume, clear rules, cheap to correct.
• Research and synthesis. Search many sources, read them, produce a referenced summary. The cost of a mistake is a human noticing a weak citation.
• Reconciliation. Compare two systems that should agree, investigate what doesn't. Enormously tedious for people, well-defined for software.
• First-draft production. Test cases from a requirement, documentation from a codebase, a response from a template plus context. A human still approves.

The common thread is not intelligence. It is that each of these has a verifiable outcome. You can tell whether the agent succeeded.

Where agents go wrong#

Tasks with no clear "done". "Improve our marketing" gives the loop nothing to terminate on. It will keep going, spending money, producing plausible activity.

Irreversible actions. Deleting records, sending external emails, moving money, changing production configuration. It is not that agents are unusually error-prone — it is that a human doing these steps hesitates instinctively, and an agent does not.

Long chains where each step is only mostly right. This is the failure people underestimate most, because the arithmetic is unintuitive. If every step is 95% reliable:

A twenty-step agent built from 95%-reliable steps fails most of the time. This is why "give the agent a big goal and let it work" disappoints, and why the effective pattern is short chains with checkpoints. Either raise per-step reliability or shorten the chain — there is no third option.

Tasks a script would do better. If the steps are always the same, write the script. An agent's value is deciding what to do next when that varies. Paying a model to re-derive a fixed sequence is expensive and less reliable than a for loop.

Keeping an agent under control#

Five controls. The first two are not optional for anything touching production.

1. Give it the narrowest tools that work. Not "database access" — a specific query for a specific purpose. Every tool is a capability you are granting to a system whose behaviour you cannot fully predict. Read-only unless writing is genuinely required.

2. Put a human in front of irreversible actions. The agent prepares; a person approves. This sounds like it removes the benefit — it doesn't. Nearly all the work is in the preparation. Approval is seconds.

3. Cap the loop. Maximum steps, maximum time, maximum spend. Without a cap, a confused agent retries indefinitely and you find out via the bill. Treat these as hard limits, not warnings.

4. Log every decision. What it chose, why, which tool it used, what came back. When an agent does something unexpected — and it will — this log is the only way to understand what happened. It is also what makes the behaviour auditable, which regulated environments will require.

5. Make failure visible. An agent that silently gives up is worse than one that stops loudly. Surface incomplete tasks rather than reporting a partial result as finished.

One agent or several?#

Multi-agent systems get a lot of attention. A useful rule: more agents means more coordination, and coordination is where the failures move.

One agent with several tools is simpler, cheaper and easier to debug than several agents passing messages. It is the right starting point almost always.

Multiple agents earn their complexity when sub-tasks are genuinely independent and can run in parallel, or when they need materially different capabilities — for example a research agent with broad read access and a writing agent with none. If your second agent exists mainly to check the first, consider whether a validation step would do the same job with far less machinery.

Testing something non-deterministic#

The usual contract — same input, same output — does not hold. Two identical runs can take different paths and both be correct. What you can test:

• Did it reach the goal? The outcome is checkable even when the path varies.
• Did it stay within its tools? Attempts to use something it shouldn't are a security signal, not a curiosity.
• How many steps? A task that took four steps last week and twelve today has regressed, even if the answer is right.
• What did it cost? Token spend per completed task is a quality metric. Rising cost at flat accuracy means it is thrashing.
• How does it fail? Give it impossible tasks deliberately. It should stop and say so, not invent a completion.

Run each case multiple times and measure the pass rate, not a single result. An agent that succeeds 7 times in 10 is a different system from one that succeeds 10 in 10, and a single test run cannot tell them apart. Our Agent Testing material goes into this in depth.

A sensible way to start#

Pick one task that is tedious, well-defined, and reversible. Reconciliation, triage and first-draft generation all qualify.

Build it with read-only tools first and have it propose actions rather than take them. You learn how it reasons at zero risk, and the proposal step is where most of the value already is. Add write access one tool at a time, only where a human approval gate exists or the action is trivially reversible.

Measure from day one: completion rate, step count, cost per task, and what happens when it fails. Without these you cannot tell improvement from luck.

Then resist the temptation to widen the goal. The reliability arithmetic above is unforgiving, and most disappointing agent projects are a working narrow agent that someone asked to do too much.

FAQ#

What is the difference between an AI agent and automation?#

Automation follows a fixed sequence you defined. An agent decides the sequence at run time based on what it finds. If the steps never vary, automation is cheaper, faster and more reliable — use it.

Do agents replace employees?#

In practice they change the shape of work more than the headcount: people spend less time gathering and more time deciding. The tasks agents do well are the tedious, high-volume, verifiable ones — which is also the work people are happiest to hand over. Treat any vendor promising headcount reduction as making a claim about your organisation they cannot possibly know.

How much do agents cost to run?#

Far more per task than a single AI question, because an agent makes many model calls in a loop — often ten to fifty for one task. Cost scales with steps, so an agent that wanders is expensive as well as unreliable. Measure cost per completed task, not per call.

Can an agent access our internal systems?#

Yes, through tools you define — and this is the decision that deserves the most scrutiny. Grant the narrowest access that accomplishes the task, prefer read-only, and log every call. The agent should also run with the permissions of the person it acts for, not with an all-powerful service account.

What happens when an agent makes a mistake?#

That depends entirely on what you allowed it to do — which is why tool design matters more than model choice. With read-only tools and human approval, a mistake is a bad suggestion someone declines. With unrestricted write access, it is an incident. Design for the second case even if you expect the first.

Are multi-agent systems better?#

Not by default. They add coordination overhead and new failure modes, and they are harder to debug. Start with one agent and several tools. Add agents when sub-tasks are genuinely independent or need different permissions — not because the architecture diagram looks more impressive.

How do we know it's working?#

Completion rate on real tasks, steps per task, cost per completed task, and behaviour on tasks it should refuse. If you cannot state those four numbers, you do not yet know whether the agent is working — you know that the demo went well.

What else is coming for AI Agents