Ask five vendors what their "AI agent" does and you'll get five different answers, and at least two of them will turn out to be a chatbot with a new name on the box. That's not entirely marketing's fault: the underlying technology genuinely has moved on, and three different things now get sold under one word. Sorting them out is the first useful thing anyone can do before spending money on any of them.
A chatbot answers a question and stops. You ask, it responds, the conversation ends there, useful for a support widget, not much more. A copilot sits inside a piece of work a person is already doing and speeds one step of it up: drafting a reply, summarising a document, suggesting the next line of a spreadsheet formula. It's still the person doing the work; the copilot is just a faster pen. An agent is different in kind, not just degree: given a goal, it works out the steps needed to reach it, carries several of them out using the tools available to it, and only comes back to a person at points someone decided mattered. That's the whole distinction, because most of what gets called an agent today is a copilot with better branding.
What an agent actually does
Strip the word back to its mechanics and an agent is a system built around four things: a goal, a set of tools it's allowed to use, a way of deciding what to do next given what it's already found out, and a defined point, or several, where a person checks the work before it goes further. Remove any one of those and it stops being an agent. No goal and it's just a tool. No tools and it's a chatbot giving advice nobody acts on. No planning and it's a fixed workflow with an AI step bolted in. No checkpoints and it's something nobody sensible would deploy against a real customer.
The planning part is what's new, and what's oversold in roughly equal measure. Given a goal, a current model can break it into a sensible sequence of steps, call a tool for each one (look something up, fill in a form, draft a message) and adjust the plan when a step returns something unexpected. That's a genuine capability, not a demo trick. What it isn't is judgement, and every deployment that's worked has been built around that limitation rather than in spite of it.
A worked example: the enquiry that runs itself
Take an inbound enquiry landing in a commercial insurer's mailbox: a landlord wanting cover for three rental properties, sent as a two-paragraph email with a property list attached as a spreadsheet. Handled well, an agent built around that mailbox does a recognisable sequence of things, none of them exotic on their own.
It reads the email and the attachment together, and works out that this is a quote request rather than a claim or a complaint: the triage step, and the one most demonstrations skip because it's unglamorous. It checks what it already knows: whether this is an existing customer, whether there's a live policy the request might affect, whether the property list needs enriching with a flood or crime-rate lookup before a quote can be sensible. It gathers what's missing, using the tools it's been given (a rating engine, a property database, the CRM) and assembles a draft quote against the underwriting rules it's been configured with, not rules it invented.
Then it stops. It doesn't send the quote. It puts a draft in front of an underwriter with the reasoning attached (the properties considered, the rating factors applied, anything unusual it flagged) and waits. The underwriter can approve it in under a minute, adjust a figure, or reject the whole thing. What changed isn't that a computer now sells insurance. It's that a chunk of an underwriter's morning, spent on data-gathering rather than judgement, has gone away, and the judgement itself is still entirely theirs.
What agents are genuinely good at, and what they aren't
The genuine strengths are narrower than the pitch decks suggest, and more useful for being narrow. An agent is tireless and consistent at exactly the kind of multi-step, multi-system task that wears a competent person down by the tenth repetition of the day: chasing the same three systems for the same three facts, applying the same rules to each case, noticing the same red flags every time rather than the seventh time out of ten. Give it a bounded goal, well-defined tools and rules that don't require reading a room, and it will do that work faithfully, all day, without getting bored into skipping a step.
What it's still bad at is exactly what you'd expect: situations the rules didn't anticipate, judgement calls where the right answer depends on context nobody wrote down, and anything where getting it wrong is expensive or hard to reverse. An agent will follow a flawed plan with the same confidence as a sound one, because it has no independent sense of when it's out of its depth. That has to be built in from outside, by whoever designs the checkpoints. That gap is exactly where the approval step earns its keep.
The guardrails that make it deployable
None of the above is an argument against deploying agents. It's an argument for deploying them inside guardrails specific enough that the gaps above stop mattering. Three do most of the work.
The first is scope: an agent should have a narrow, explicit boundary on what it's allowed to do, not a broad mandate to "handle enquiries". A narrow scope makes every other guardrail easier, because there's a small, known set of things that could go wrong. The second is the approval step itself, not a courtesy checkbox, but a real point at which a person with the authority to say no sees what the agent is proposing, and anything above an agreed threshold of consequence waits for them rather than proceeding on a timer. The third is the audit trail: a record of what the agent looked at, what it decided, and why, kept in a form a person can review without needing to ask the system to explain itself. Together, those three turn "trust the model" into "check the record", a much easier thing to ask a board to sign off.
Is a process agent-ready?
Not every process is a good candidate for this, and the tell usually shows up before any building starts. A short, honest checklist saves more wasted effort than any architecture debate.
- The goal can be stated in one sentence, without a list of exceptions attached
- The tools it would need (the systems, the data) already exist and are reliable
- Each step has a right answer that rules can express, not one that depends on reading the customer's tone
- There's an obvious point to stop and ask a person, and someone senior enough to be that person
- Getting a step wrong is recoverable: a delay or a redo, not a cheque that's already gone out
- Someone can describe, today, exactly how the process is done by a person, because a process nobody can explain isn't ready to be handed to anything
Where to start
Not with a platform, and not by asking which model is best this quarter. That answer changes too often to build a strategy on. Start with one process that already meets the checklist above, one with a clear owner and a known cost when it's done badly by a person on a bad day, and prove the pattern there before it earns a wider mandate.
That's a discovery exercise before it's an engineering one, and it's where every agent build we run begins, because the checklist above is easier to apply to a real process than to a hypothetical one.
