AI Agent Guardrails: Approvals, Limits and Testing Before You Trust One

An AI agent that talks to customers is, in practice, a new employee who never sleeps, never gets tired of repeating itself and has no instinct for when to stop. That is exactly why people want one. It is also why the first week matters so much. The failure that hurts is rarely dramatic. It is a follow-up sent to someone who said no last month, a price quoted from memory that was true last year, or a cheerful reply to a customer who was furious.

This guide is about keeping any customer-facing agent safe: how much authority to give it, which actions a human should approve, which limits must be enforced by the system rather than requested in a prompt, how to test it before launch and after every change, and what to do on the day something goes wrong anyway. It is deliberately not a setup tutorial. It applies whether the agent sells, supports, books or chases invoices.

Key takeaways

The real risks of a customer-facing agent

It helps to be specific about what can go wrong, because each risk points to a different control. Vague worry produces vague safeguards.

Start with least authority

The oldest idea in security applies cleanly here: give a system only the permissions it needs to do its job. An agent that qualifies inbound enquiries does not need to move deals between stages. An agent that reminds people about unpaid invoices does not need to offer discounts.

In practice this means treating each skill as a decision. Before enabling one, ask three questions.

• Does the job genuinely need it? If you cannot name the situation in which the agent would use it, leave it off.
• What is the worst realistic outcome of one bad use? An unnecessary note is trivial. A discount offered to the wrong contact is not.
• Can it be undone? A task can be deleted. A message cannot be unsent.

Approval levels by risk

Not every action deserves the same scrutiny, and asking a human to approve everything defeats the purpose. A simple three-level model works for most teams.

The levels are about consequences, not about how confident the agent sounds. An agent can be very sure and very wrong, and a confident tone is not evidence.

Hard limits versus soft guidance

This is the distinction that most separates safe setups from hopeful ones. Soft guidance is anything you put in the prompt: “never discuss pricing”, “do not message people more than three times”, “be polite”. It is useful, and it shapes the default behaviour, but it is a request to a system that interprets language. Edge cases, long conversations and unusual phrasing can all lead it astray.

A hard limit is enforced outside the model. The agent is not asked to stay inside it; it simply cannot act outside it. If something genuinely must never happen, it belongs in the second category.

The limits worth setting on day one

• Working hours. Messages that land at 2 a.m. feel automated and sometimes break local rules on contact times.
• Daily caps. A ceiling on actions per day, and on new contacts engaged per day, turns a bug into a small incident rather than a large one.
• Cooldowns. A minimum gap between actions on the same contact stops rapid-fire sequences.
• Maximum follow-ups. Decide how many unanswered attempts is polite, then make the number a rule.
• Exclusion tags. Existing customers, partners, suppliers, staff and anyone in a sensitive situation should carry a tag that removes them from the agent's reach.
• Never-contact lists. Opt-outs and complaints are permanent, and the agent should have no way to override them.
• Topic restrictions. Subjects the agent must not engage with, such as legal terms, pricing exceptions or anything regulated.

Know when to hand over to a human

Good agents are defined as much by what they refuse to handle as by what they handle. Write the escalation triggers down before launch, rather than discovering them during an argument with a customer.

• Anger or distress. A frustrated customer wants acknowledgement from a person, not a polished paragraph.
• Legal language. Threats of action, mentions of a solicitor or regulator, or disputes over contract terms.
• Refund or compensation requests. These involve money and judgement about the relationship.
• Medical, legal or financial advice. The agent should never improvise here, however reasonable the question sounds.
• A direct request for a human. Honour it immediately. Making people argue their way past a bot is a fast route to a complaint.

Logging and audit: be able to see why

When something odd happens, the first question is always the same: what did it do, and why? If the answer is “we cannot tell”, you cannot fix it, cannot explain it to the customer and cannot learn from it.

A usable audit trail records, for every action, what was proposed or done, to whom, when, what the agent saw at that moment and the reasoning it gave. That last part is what turns a log from a list of events into something you can debug. It also lets you spot patterns, such as the agent repeatedly choosing the same follow-up for a particular type of reply.

Memory: what an agent should remember, and how to fix it

An agent that forgets everything between interactions asks the same question twice and contradicts itself. An agent that remembers carelessly is worse, because it acts confidently on things that are wrong or out of date.

For each contact, a sensible memory holds three kinds of thing.

• Facts. Budget, timeline, team size, preferred channel, who the decision maker is.
• Objections and preferences. What they pushed back on, what they asked not to be sent, what they care about.
• History. A short narrative of what has happened and the recent actions, so the next step builds on the last.

Correcting wrong memory

Memory will sometimes be wrong. The agent misreads a sarcastic reply as interest, records a budget from an old quote, or treats a closed deal as open. Plan for this rather than being surprised by it.

• Make stored facts visible to your team so errors can be noticed.
• Have a clear way to edit or remove a fact, and to reset the summary for a contact whose history has become misleading.

Testing with scenarios

Reading a few sample outputs and deciding they look fine is not testing. It tells you the agent can write a good message, not that it will make the right decision in the awkward situations that matter. The better approach is a scenario set: a collection of realistic situations, each with the decision you expect.

Building the set

Aim for fifteen to thirty scenarios. Fewer will miss important cases; many more become hard to maintain. Draw them from real conversations wherever you can, and make sure the set is not all easy wins. Include each of these kinds.

Write the expected decision before you run anything. If you decide after seeing the result, you will rationalise whatever it did.

Running them, and reading the score

Run the whole set before launch, and again after every change to the prompt, the skills, the limits or the underlying model. This is regression testing: the point is to catch the case where fixing one behaviour quietly breaks another.

Treat the pass rate as a trend, not as proof. A score of 27 out of 30 tells you the agent handled the situations you thought of. It does not tell you it will handle the ones you did not. What matters is the direction over time, and above all which scenarios fail. A single failed “stop” or “escalate” scenario matters more than three failed “reply positively” ones.

Pilot on a small segment first

Scenarios test the situations you imagined. A pilot tests reality. Choose a small, low-stakes segment, such as fifty recent enquiries or one region, and run the agent with approvals on for everything that reaches a person.

The weekly review: your best source of improvements

Once the agent is live, the most valuable fifteen minutes of the week is a look at what humans rejected or edited. Each one is a labelled example from a person who knows your business, saying “not like that”. No synthetic test can match it.

Sort the rejected and edited actions into groups: wrong facts, wrong tone, wrong timing, wrong person, and should not have acted at all. Then ask what kind of fix each group needs.

An incident playbook, written before you need it

Something will eventually go wrong. The difference between a forgettable incident and a damaging one is mostly whether anyone knew what to do in the first ten minutes.

• Know where the pause switch is. More than one person should be able to stop the agent immediately, without a meeting.
• Pause first, investigate second. Do not try to diagnose a live problem while it is still sending.
• Decide who is told. Name the person who owns the customer relationship, and who decides whether a wider notice is needed. If personal data was exposed, check what your local rules require and how quickly.
• Find the affected contacts. The audit trail should tell you exactly who received what.
• Fix the cause, then add a scenario. The incident should leave behind a test that would have caught it.

Privacy and compliance

Automation does not change your obligations; it just makes it easier to breach them at scale. This is general guidance, not legal advice, and the rules differ by country, state and channel, so check what applies to you.

• Consent. Know on what basis you are contacting each person, and be stricter with text messages and calls than with ordinary business email.
• Opt-outs. Make leaving easy, honour it promptly and record it somewhere the agent cannot overrule.
• Data minimisation. Collect and remember only what the job needs, and keep it only as long as it is useful.

How Scalry handles this

Scalry agents are built around the idea that you should be able to constrain them before you trust them. A new agent starts paused, so nothing happens until you deliberately switch it on. Each skill can require human approval, and when it does, the proposed action waits in an approval queue rather than going out. Actions move through clear states: pending approval, approved, completed, failed, skipped or rejected, so you can see what is waiting and what happened to the rest.

Guardrails are enforced by the system rather than requested in the prompt. The types available are working hours, cooldown period, max follow-ups, topic restriction, exclude tag, never contact, daily limit, max leads per day and require approval. An agent takes one action at a time per contact, with a cooldown between them. Enrolments can be active, paused, completed or exited, and a contact leaves through a guardrail, such as reaching the maximum follow-ups, carrying an excluded tag or being on a never-contact list, or through escalation to a human. There is an escalate-to-human skill for the situations described above.

For memory, each contact or deal has a persistent thread that holds a rolling window of recent run summaries, extracted facts such as budget and objections, and a compressed narrative summary. For testing, you can create evaluation scenarios, each a simulated contact state with an expected agent decision, and these can be seeded from real past actions. Evaluation runs report the total, how many passed and failed, and a score, so you can rerun them after changing the prompt. Proactive insights, such as deals gone silent, overdue follow-ups, high-intent contacts and deals at risk, help you see where attention is needed.

Questions to ask before you commit

Whichever way you are leaning, these are the questions that change the answer. Work through them against your own numbers rather than anyone's feature matrix — including this one.

• What is the worst thing this agent could do with the skills it has? If you shudder, remove a skill or add an approval.
• Which rules are enforced by limits, and which only by the prompt?
• Who is on the never-contact and exclusion lists, and who keeps them current?
• Can I see why the agent chose each action?
• Do I have a scenario set, with expected decisions, that I rerun after every change?
• Who can pause it, and would they know to?
• What happens to a contact who asks for a human?

If you cannot answer the first three, you are not ready to choose between Scalry and running agents unsupervised yet — you are still deciding what you need, which is a cheaper problem to solve first.

A short plan: from paused to trusted

Before launch, enable only needed skills, set the limits, require approval on messages, write escalation triggers and run your first scenarios. Then pilot on a small segment for two weeks, expand in steps with a weekly review, and rerun the scenarios after every change.

Frequently asked questions

What guardrails should an AI agent have?

At minimum: only the skills it needs, human approval on messages and high-risk actions, working hours, daily caps, cooldowns, a limit on follow-ups, exclusion tags, a never-contact list and clear triggers to hand over to a person. The important point is that limits are enforced by the system, not just written in the prompt.

Should a human approve every AI agent action?

No. Approving everything removes the benefit. Let low-risk actions such as reading and adding notes run freely, require approval for sending messages at first, and keep a person in the loop for anything irreversible, such as moving a deal, booking or discounting. Relax approvals one skill at a time as the record improves.

Why not just put the rules in the prompt?

Because a prompt is a request to a model that interprets language, and it can be ignored or misread in unusual cases. Anything that must never happen, such as contacting an opted-out person or exceeding a daily volume, should be a hard limit that the agent cannot override.

How do I test an AI agent before launch?

Build 15 to 30 realistic scenarios, each with the decision you expect, such as reply, do nothing, escalate or stop. Write the expected result first, run the set, and investigate every failure. Then run a small pilot with approvals on before widening access.

How often should I rerun the tests?

Before launch, and after every change to the prompt, the skills, the limits or the underlying model. Treat the pass rate as a trend rather than proof, and pay most attention to which scenarios fail, especially stop and escalate cases.

When should an AI agent escalate to a human?

When a contact is angry or distressed, mentions legal action, asks for a refund or compensation, asks for medical, legal or financial advice, or asks to speak to a person. It should also escalate whenever it is unsure, rather than guessing.

What should I do if an AI agent sends something wrong?

Pause it immediately, then investigate using the action log. Identify who was affected, contact them personally where it matters, apologise plainly and fix the cause. Finally, turn the incident into a new test scenario so the same mistake is caught next time.