In this guide 6 sections
An AI agent is a language model that can call a fixed list of actions, such as looking up an order, drafting a reply or opening a ticket. Read-only actions can run alone. Anything that commits money, quotes a price or promises a delivery date should wait for a named approver before it leaves the building.
A chatbot talks, an agent acts
A chatbot answers a question and stops. An agent reads the request, picks an action from its list, reads the result that comes back and decides the next step, repeating until the task ends. The model supplies judgement. Your systems supply facts.
Take a customer asking where order 4471 is. The agent calls a lookup against your order table, finds the courier reference, and drafts a reply carrying the tracking link before any human has typed a word. Nothing more is happening.
It can only do what its list allows. If no refund action exists, it cannot refund, which makes the list the main design lever, and your developers can change it with a one-line edit and a retest.
The action list is the real product
An agent is its action list. Each action has a name, the inputs it accepts and the result it returns, like buttons on a control panel that the model may press but never rewire.
A support agent might hold six of them: look up an order, check stock, fetch a warranty record, draft a reply, open a ticket and add a note. The model cannot invent a seventh, because the code behind each button is fixed by your developers and changes only through a reviewed release.
Start short. Every added action widens what can go wrong, so each new button should arrive with a good call, a bad call and a test that proves the difference.
- Action name, such as get_order_status
- Inputs it accepts, such as order number only
- What it returns, such as status and courier reference
- Whether it only reads or also writes
- Who approves it, if it writes
Separate reading from committing
Sort every action into two groups. Read-only actions fetch or draft something and change nothing, while committing actions move money, alter a record that others rely on or make a promise to a customer.
Read-only actions can run unwatched. A wrong lookup costs one retry and nothing else, so nobody needs to sign off before the agent tries again. Committing actions need a gate. A refund, a quoted price, a delivery date promised in writing or a supplier payment should stop and wait for a named approver.
Name the person, not the department, and name a deputy for leave days, so the queue never stalls while the accounts lead is away from the desk. A queue owned by nobody gets ignored. An owned queue gets cleared before lunch.
What an agent should not be allowed to do
Some actions stay off the list on day one: deleting records, editing the price master, messaging your entire customer base and changing bank details on a vendor record. Vendor bank details are a classic fraud route.
Limit what the agent can see as well. If an action only needs order status, withhold the customer table that holds phone numbers, home addresses and payment notes, since the agent has no use for them. A model cannot leak what it never received. Scope each action to the narrowest table, view or API route that still does the job, and test that it fails when asked for anything wider.
Log every call with input, result and timestamp. When a customer disputes a reply, the log shows the exact input, the action called, the result returned and the time, so nobody has to guess.
- Deleting or merging records
- Editing price lists or tax rates
- Bulk sends to the full customer list
- Changing vendor bank details
- Anything outside the logged action list
Start with one narrow task
Pick a boring, frequent, checkable task. Order status replies fit. So does drafting a first response to a warranty claim, or chasing missing fields such as drawing number, quantity and delivery site on a quote request.
Run the agent in draft mode for the first weeks, where it prepares the reply and a person presses send. Count how often the person edits the draft and which edits repeat, because that count tells you when read-only work can go fully automatic. Typical repeats include a wrong courier name.
This week, write down the five actions your best support person uses most, then mark each as read or commit. That page is your agent’s first draft.
Agent action register
A sheet for the agent’s control panel. One row per action. Columns hold the action name, inputs, system touched, read or commit flag, named approver, daily call limit, test date and the person who last reviewed the example calls. A second block lists the actions kept off the list, each with a reason, an owner and the date someone last asked for it to be allowed.
Open a blank worksheet to printQuestions owners ask
Is an AI agent the same as a chatbot?
No. A chatbot replies with text. An agent can also call actions in your systems, such as an order lookup or a ticket creation, and use the result in its next step. The action list is the difference.
Can an agent approve refunds by itself?
It can prepare one, with the order, the reason and the amount filled in, so the approver only reviews a draft instead of building the refund. A named person should press approve. Money leaving needs a human gate.
What if the agent calls the wrong action?
Fixed action code limits the damage. A wrong read-only call returns the wrong data and gets retried, while a wrong committing call stops at the approval step, where a person sees the mistake.
Do we need to train a model on our data?
Usually not. The agent fetches live facts, such as stock levels and warranty dates, through its actions at the moment of the request, so nothing needs to be memorised. Training is a separate and heavier job. Most agent tasks never need it.