AI Agents for Business: What They Actually Do

The word agent is doing a lot of work in AI marketing at the moment, and it is worth being precise about what it means, because the distinction determines what controls you need. An assistant reads and writes. An agent reads, writes, decides on a sequence of steps, and then does them, using real systems, with real consequences.

That is a meaningful jump. It is the difference between a tool that gives you a draft email and a tool that sends it.

Assistant, automation, agent

Three categories that get conflated, and the confusion causes bad procurement decisions.

The last row is the one to sit with. Traditional automation fails loudly and stops. An agent that misunderstands its instruction does not stop; it proceeds, plausibly and quickly, and may do the wrong thing forty times before a person looks.

Where agents genuinely fit today

Four properties make a task a good early candidate. Look for all four rather than any one.

• Narrow. A defined job with a clear boundary, not a general mandate to manage something.
• Bounded. A limited set of systems and actions available, ideally read-heavy and write-light.
• Reversible. If it goes wrong, you can undo it in an afternoon without contacting a customer.
• Observable. Every action lands in a log or a record someone can review after the fact.

Tasks that fit this shape in most businesses include triaging and routing incoming requests to the right queue with a suggested category, gathering information from several internal systems into a briefing document before a meeting, monitoring for a condition and preparing a draft response for approval, and reconciling records between two systems and flagging the differences rather than resolving them.

Notice the pattern. In each case the agent does the gathering, the sorting and the preparation, and a person does the committing. That division is where the current technology sits comfortably, and it captures most of the available benefit.

Where to wait

Three categories where the sensible position is a human approving each action, regardless of how good the demonstration looked:

Anything that spends money. Purchasing, refunds, payments, committing to costs. The failure mode is immediate and hard to reverse.

Unsupervised customer contact. An agent corresponding with your customers without review is your brand voice operating without judgement. The upside is modest and the downside is public.

Changes that are hard to restore. Bulk edits to core records, deletions, permission changes. If your recovery plan for a mistake is a restore from backup, do not let software make those changes autonomously.

The four controls agents require

1. Least privilege, on its own identity

An agent should have its own credential, not a borrowed human account. Two reasons: you can see in logs which actions were the agent's, and you can grant exactly the permissions the task needs rather than inheriting everything a person happens to have. An agent running on an administrator's account has administrator powers it will never need and might use.

2. A hard spending limit

Agents work in loops, and a loop that does not terminate as expected is the classic runaway cost scenario in this category. Give each agent its own credential with its own ceiling, so one misbehaving process trips its own limit rather than the organisation's.

3. A complete action log

Not just the outputs but every action taken, in order, with timestamps. When something goes wrong the question is always "what did it actually do", and without a log the answer is reconstruction and guesswork. This is also what makes an agent explainable to an auditor or a client.

4. A stop condition

Define in advance what makes the agent halt and ask rather than proceed: an unfamiliar case, a value outside an expected range, a number of steps exceeded, a confidence threshold not met. An agent with no stop condition will always choose to continue, because continuing is what it is for.

The sequencing question

Agents are the most interesting thing in this category, which makes them attractive as a starting point. That is usually a mistake, for a straightforward reason: an agent operating inside an organisation with no admin controls, no spending ceiling, no logging and no documented permissions model is a larger version of a problem you have not solved at a smaller scale.

The order that works:

1. Configure the assistant properly. Admin console, retention, sharing, SSO, spending cap, model routing, task guidance for staff.
2. Let people use it for a quarter. You learn which tasks are genuinely repetitive and where the volume actually is, which is rarely where you expected.
3. Automate one narrow task, in suggest-only mode, with its own credential, its own limit and full logging.
4. Earn autonomy gradually, one action type at a time, on the evidence of weeks of reviewed suggestions.

Organisations that skip to step three tend to discover that the hard part was never the agent. It was knowing which task was worth automating, and having the governance in place to let something act on your behalf safely.

Questions to ask a vendor selling agents

• What exactly can it do, and what can it not do? Ask for the list of actions, not the list of use cases.
• Does it run under its own identity, and how are its permissions scoped?
• Can I see a complete log of every action, and how long is it kept?
• What makes it stop and ask instead of proceeding?
• Can I run it in suggest-only mode, and for how long?
• What is the spending control, and is it a cap or an alert?
• When it is wrong, how do I find out, and how do I undo it?

A vendor with clear answers to all seven is selling a considered product. A vendor who redirects to capability demonstrations is selling a demonstration.

Frequently asked questions