Skip to content

AI agents: when AI takes action

An agent is a model running in a loop: decide what to do, call a tool, read what comes back, decide again, and keep going until the task is done or it stops. Nobody scripts the steps. The model picks each one from the result of the last, working towards a goal without being walked through it.

That is the whole idea, and it changes what a mistake costs. A model that only writes text is cheap to be wrong. A model that sends, books and updates is not.

Ask a model a question and it answers once. That is the whole interaction. An agent instead takes a goal, chooses a first step, reads what that step returns, and chooses the next one from what it now knows.

Watch an agent work · decide · act · read · decide
0 / 8
Task
Pull invoices unpaid > 30 days, draft reminder emails.
    Click Start to watch the agent work the task.

    Bounded automation. Booking a meeting that requires checking 3 calendars. Pulling data from 3 systems and assembling a report. Answering a customer question by querying the database, calling an API and writing the reply. A short path, a small set of choices at each step, and a clear definition of finished.

    Coding agents. Cursor, GitHub Copilot, Claude Code. These read the code, plan changes, edit files, run tests, fix what breaks, repeat. For routine work they beat asking a model for a few lines, because they can read the surrounding code and check their own output by running it.

    Research agents. “Research our top 3 competitors and write me a brief on their pricing.” The agent searches, reads, takes notes, searches again, eventually writes the brief. Quality varies a great deal by topic, and it varies most where the source material is thin, which is exactly where nobody can tell.

    Workflow agents. Sales follow-up, support triage, internal request routing. These usually mix a model with ordinary software: the model makes the judgement calls, hardcoded rules handle the predictable parts.

    Agents that drive a screen. Every major lab now ships a model that operates a browser or a desktop directly, clicking and typing the way a person would. It is the class most people have watched in a video, and the least reliable of the 5. On ordinary web tasks the published pass rates sit somewhere between two thirds and nine tenths depending on the task and who is counting. It fails on the things a person barely notices: a login wall, a redesigned page, a checkbox that moved. It is also the class where a malicious instruction hidden in a web page can end up being read as a command.

    A year ago the honest boundary was a few minutes of work. It is now a few hours, and the measured length keeps roughly doubling on a timescale of months rather than years. Any specific number here dates fast. The mechanism under it does not: more time means more steps, and each step is another place to go wrong on a foundation everything after it is built on.

    There is a second measurement that matters more than the headline. The task length an agent finishes about half the time is 4 to 5 times longer than the length it finishes reliably. A job an agent sometimes completes in an afternoon is not a job it can be left alone with.

    Small failure rates multiply. A step that goes right 95% of the time is a good step. 10 of them in a row go right about 60% of the time. 20 go right about a third of the time. None of that is about model quality, and it is why the answer to a long run is a checkpoint in the middle rather than a better prompt at the start.

    It works when the path is short or the choices at each step are few, when the tools are dependable (the calendar API responds, the database returns clean rows), and when approximately right is useful: a research brief, a first-draft reply, a triage decision a person will glance at.

    It breaks when the path forks in ways nobody anticipated, when a tool returns something odd and every later step is built on a wrong answer, and when the task is stated so widely that there is no way to tell whether it is finished. “Organise the company’s operations” has no last step.

    That is the distinction worth holding. Work that moves between systems, where each step returns something checkable, is the case running in production today. Plans that depend on the real world answering back, where a step can be subtly wrong rather than obviously broken, remain the hard case.

    When a model only writes text, mistakes are cheap. You read, you discard, you try again.

    When a model acts, sends emails, books appointments, updates databases, spends money, mistakes are expensive. A real customer gets a confused email. A real meeting goes on a real calendar. A real query writes real data.

    Systems that survive contact with production put the checks at specific points:

    • Approval before anything irreversible: sending, paying, deleting.
    • A record of every step taken, so a run can be audited and rolled back.
    • A limit on reach: it can email customers, not everyone; it can update these records, not all of them.
    • A route back to a person when the agent is uncertain, and a definition of uncertain that fires before the money moves.

    Scope is 2 separate questions: how much can this agent touch, and how many different things is it allowed to try. An agent with one database query and one draft-email function has a small answer to both. An agent with a shell, a browser and a company inbox has a very large one.

    Scope is settled by what the agent is connected to, not by what it was told. A prompt asking a model to stay away from the production database is a request. A connection it does not have is a limit.

    Building those connections used to be bespoke work per system and per assistant. There is now a common standard for them, the Model Context Protocol, covered in the previous chapter. The part that matters here is that connections have become the unit: an agent is handed a defined set of them, each one carrying its own permissions, and that set is the honest description of what it can do. Which is also the question to ask about any agent, whether bought or built: not how capable is the model, but what is it wired into.

    Multi-step work that checks a few systems, reasons over what comes back and produces an output is running in production at real companies. Coding agents are the most mature version of it. Bounded operations work comes next: booking, triage, internal lookups, customer replies drafted with the account details already pulled in.

    Customer-facing and irreversible action is where the technology is real but the engineering around it has to be careful. Most production deployments here have a human checkpoint at the step that costs money or touches a real person. Removing that checkpoint is what blows up publicly.

    “Let an agent run our operations”, the demo-video framing, is still a demo. The band of what works has widened a lot in a year and will keep widening, unevenly, faster in software than anywhere else. But the distance between a run that works on stage and one that works for 6 months without supervision is much larger than it appears, and almost all of that distance is in the checks, not in the model.