The word "agent" has been stretched to the point of uselessness. It currently covers everything from a scripted FAQ widget to a system with tool access and its own budget.
For the purposes of a real business deployment, the useful definition is narrow: an agent is a bounded job, performed on your behalf, with defined inputs, defined authority, and a defined point at which it stops and hands over.
Everything that goes wrong with agents in production goes wrong because one of those was never written down. Here are the six things to specify, in the order they matter.
1. The job, stated as one sentence
Not "handle customer enquiries". That is a department, not a job.
"Answer inbound calls after 5pm, identify whether the caller wants a quote, a booking, or support, capture their postcode and job type, and either book from the live diary or take a callback slot."
The test for a good scope sentence is that you can imagine a new employee reading it and knowing when they have finished. If the sentence contains "and anything else that comes up", you have not scoped it.
Narrow scopes outperform broad ones badly enough that this is close to the whole article. An agent doing one thing reliably is worth more than one doing six things at 80%, because 80% means a person has to check all six.
2. What it may say, and what it must never say
Two lists. The second is more important and takes longer to write.
The may list is usually easy: opening hours, service areas, general "roughly how much" ranges if you have them, availability.
The must never list is where the business risk lives. Firm prices for anything non-standard. Timescales it cannot verify. Anything that sounds like advice (legal, financial, medical, regulatory. Commitments about a specific person. Anything about a competitor.
Write this before you look at any platform. It is a commercial decision and it belongs to you, not to whoever configures the thing.
3. What it is allowed to do, which is different from what it can say
An agent with tool access can change the world. That authority needs explicit limits.
Can it book into the live diary? Which slot types, how far ahead, and can it double-book an engineer? Can it reschedule an existing appointment? Can it cancel one? Can it issue a refund, apply a discount, or amend an order?
Our default, and we would defend it in most contexts: it may create, it may not destroy. Booking a new slot is reversible and low-risk. Cancelling somebody's existing appointment because it misheard is a phone call you do not want to make.
4. The escalation conditions
The agent must have a written list of situations where it stops and gets a human. Not "when it is unsure") models are poor judges of their own uncertainty, and "unsure" is not observable.
Use observable triggers instead:
- The caller asks the same thing twice.
- The caller uses words from a defined list (complaint, solicitor, injury, cancel, urgent.
- The request falls outside the may-say list.
- The caller asks for a named person.
- The caller asks to speak to a human. Always, immediately, without a retention attempt.
That last one is not negotiable in our builds. An agent that makes it hard to reach a person costs more goodwill than it saves in labour, and everybody can tell when it is doing it.
5. Where the output goes
Covered elsewhere on this site, but it belongs on this list because it is the most common mechanical failure: an agent that performs beautifully and writes into a transcript that nobody reads.
Specify the destination as a field on a record, not as a system. Not "it feeds the CRM") which field, on which record, triggering which sequence, reviewed by whom, and what happens if the write fails.
The failure case matters. An integration that silently drops one call in fifty is worse than no integration, because you will trust it.
6. How you will know it is going wrong
This is the one everybody skips, and it is the difference between an agent that improves over a year and one that quietly degrades.
You need a review loop. Concretely:
- A sample. Ten conversations a week for the first month, read by the person who owns it. Not skimmed (read.
- A signal. Escalation rate, tracked over time. A sudden rise means something changed. A rate near zero usually means escalation is broken, not that the agent is perfect.
- A complaint route. Somewhere for staff to flag "it said something odd", with a name attached so it actually gets read.
- A kill switch. A way to turn it off in under a minute without a developer. You will probably never use it. Not having it changes how nervous everyone is, which changes how much authority they are willing to give it.
Write these down before launch. Retrofitting a review loop onto a live agent means you have already lost the first month of data, which is the month that tells you the most.
The scoping session, in practice
When we scope one of these, the meeting produces a single document with six headings matching this list. It usually takes half a day, and about two-thirds of that time goes on headings two and four.
The document is the deliverable. It is also what makes the build quotable at a fixed price, because a build against a written scope is an engineering task, whereas a build against "an AI agent for customer service" is an open-ended commitment for both sides.
If the scoping session cannot produce that document, the honest conclusion is that the process is not defined enough to automate yet. That is a useful finding and it is cheaper to reach in a morning than in month three.
The general rule
Scope narrow, escalate early, write to a real destination, and read the transcripts.
An agent built that way is unremarkable in the best sense: it handles the calls nobody was answering, it hands over when it should, and nobody outside the business notices it exists. That is the target. Anything more ambitious than that should wait until the unremarkable version has been running for a quarter.
If you have a job in mind and want it scoped properly before anyone quotes a build, that is what the assessment is for) and the AI agents page covers where this sits in the wider roadmap.