Before you let an AI agent talk to customers: the four guardrails we install every time

If you're about to let an AI agent answer customer emails or draft quotes, these four guardrails are what keep one bad answer from turning into a refund, a job you lose money on, or a Monday spent apologising.

None of them require code. All four are configuration and policy decisions — you can hand this list to whoever builds the thing, or use it to audit a build that's already running.

An agent is not the same risk as an automation

A normal automation is boring on purpose: if a form comes in, create the record, send the template. Same input, same output, every time. An agent doesn't work that way. n8n's explainer on autonomous AI agents frames agents as systems that choose their own steps and tools toward a goal, rather than following a fixed path you drew in advance.

That flexibility is the whole reason you'd use one. It's also why, in our view, "I tested it and it worked" isn't evidence of much: the same question asked twice can take two different routes.

Notice where the vendor documentation puts the work. n8n has a whole guide on debugging, evaluating and monitoring agents in production — production being the operative word. Our read of that, stated as opinion: the harness around the agent is the job, not the prompt. Here's the smallest harness we're willing to ship.

Guardrail 1: scope limits — the written list of things it may do

Write an allowlist, not a blocklist. Our reasoning: blocklists lose, because you can't enumerate every dumb thing a language model might say.

For a customer-facing agent, that list usually looks like:

May do: look up an order or job status; answer from the FAQ and the published price page; collect address, photos, and preferred times; book into an already-open calendar slot; hand off to a human.

May not do: quote any number that isn't on the published page; offer a discount; approve a refund or cancellation; promise a start date; email more than one recipient; attach files; touch the accounting or payments tool at all.

Then add hard caps: one reply per thread, hand off after three exchanges, and a written refusal script for everything outside the list ("I'll have someone from the team confirm that and follow up today"). Read-only access to your systems by default — the agent gets write access to exactly one thing, and only when it's earned it.

The test we use: if you can't fit the scope on one page, the scope isn't decided yet, and you're not ready to point it at customers.

Guardrail 2: a human approval step on anything that costs money

For the first few weeks, the agent drafts and a person sends. Everything.

After that, we keep approval permanently on anything with money or a commitment in it: quotes, discounts, refunds, cancellations, dates, and any first message to a brand-new contact. Informational replies — "where's my order", "what are your hours", "do you service this postcode" — can graduate to auto-send once you've watched a stack of them go out unedited.

Two practical notes, both opinion rather than benchmark. First, approvals have to be fast and on a phone, or people route around them and the guardrail quietly stops existing. Second, track your edit rate per category: when a category has run for a long stretch with no edits, that's the candidate for auto-send. Quotes above a dollar threshold you pick should never graduate.

Guardrail 3: logs a non-technical person can read

For every run, store: what came in, what the agent decided to do, which tools it called, the exact text that went out, and who approved it. Plain rows in a sheet or a table you own — not only the vendor's console, which you may lose access to when a subscription lapses or a contractor leaves.

This is the guardrail people skip because nothing appears to go wrong without it. Then a customer forwards a reply you don't recognise, and you have no way to find out whether the agent invented a price, read a stale page, or got fed a weird email. It's also the part the tooling vendors themselves treat as an ongoing production concern rather than a pre-launch checkbox — see the monitoring and evaluation guide linked above.

Cheap addition: a keyword alert. If the outgoing text contains "price", "discount", "guarantee", "refund", or a currency symbol, ping a human even if that category is on auto-send. And put fifteen minutes in the calendar each week to read ten random runs. Our experience is that scope holes show up there, not in a dashboard.

Guardrail 4: a kill switch anyone on shift can flip

One switch that stops the agent and routes everything to a human inbox. Requirements:

• It's one action, not a workflow edit — a toggle, a flag in a sheet, a disabled trigger.
• At least two people can flip it, and one of them isn't you.
• It's documented in two sentences, next to the phone list.
• Flipping it turns on a holding auto-reply so nothing sits silent.
• Someone tests it once a month. An untested kill switch is decoration.

We also wire automatic triggers: if volume, error rate, or retries spike past a threshold you set, the agent pauses itself and tells a human. The failure mode we're guarding against is the one that starts overnight on a weekend and runs unnoticed until someone opens the inbox on Monday.

Worked example (hypothetical — invented numbers, not a client)

Every figure below is made up to show the shape of the arithmetic. It is not from a tbdb.ai engagement and shouldn't be read as a benchmark.

Say a home-services business gets 80 email enquiries a week, and the owner spends 5 hours triaging and replying. An agent drafts every reply; the owner approves from their phone. Suppose it takes the 5 hours down to 2.

Value the owner's hour at $60 and that's 3 hours × $60 = $180 a week, roughly $780 a month of owner time back. Worth having.

Now the other side, same made-up business. Un-scoped, the agent quotes a job $1,200 under what it should cost and promises a Tuesday start you can't staff. You'd probably honour it, because arguing with a customer about what your own robot said is worse. In this illustration that single email costs more than six weeks of the savings — and the promised date costs you a crew's morning on top.

That's the argument for the four guardrails: they're not the price of the project, they're what makes the savings keepable. Our estimate, not a quote: this is hours of configuration rather than weeks of engineering, and the slow part is deciding the scope, which is your call, not your developer's.

The 30-minute version

1. Write the one-page allowlist: may do, may not do, refusal script.
2. Set every money-or-commitment action to draft-for-approval.
3. Log input, decision, tools, outgoing text, approver — somewhere you own.
4. Add keyword alerts on price, discount, guarantee, refund.
5. Build the kill switch, give two people access, test it.
6. Book fifteen minutes a week to read ten random runs.

If you can't tick all six, the agent can keep drafting — it just doesn't get to hit send yet.

---

Thinking about putting an agent in front of customers? Book our AI readiness audit and bring this list with you — scope, approvals, logging and the kill switch are the first four things we'd work through with you.