Testing an AI agent before you launch it

Thursday, 4:40 p.m. The operations lead has spent two days building an appointment agent and has just run twelve scenarios through the test panel. All twelve came back polite, accurate and on brand. Forty minutes after launch, the agent created two separate appointment records for the same customer, because the customer wrote "Saturday works too" and the agent read that as a second request. The wording was flawless. The problem was never the wording. It was the action behind it, and the record that action left in the CRM.

This piece is about testing an AI agent before it ever touches a customer: where to source scenarios, the four layers you have to test separately, where the line between a dry run and a live run belongs, how to attack your own guardrails, which thresholds should gate the launch decision, how to ramp the first week in production, and which post-launch signals tell you the test set missed something. The questions teams ask most are at the end.

Why is testing an agent different from trying out a chatbot?

When a chatbot answers badly, the damage is a sentence: the customer is confused, you correct it, the thread closes. When an agent behaves badly, the damage is a record. In Rocketly an agent can carry out 74 autonomous actions inside the CRM: it creates tasks, appointments, quotes and opportunities, updates lead status, fields and score, tags and assigns. Not all of that is reversible. A quote that has been sent cannot be unsent, and a misassigned lead sits in someone else's queue until a human notices.

So agent testing asks two separate questions: did it say the right thing, and did it do the right thing. You cannot answer the second by reading transcripts; you have to look at which action fired with which parameters. Software teams already have this reflex. Standing up a sandbox in your CRM and trying changes there first has been standard practice for years. Agents need the same discipline, only faster, because agent behavior is not deterministic the way code is: the same input can produce two similar but not identical runs.

Where do your test scenarios come from?

Do not invent scenarios at a whiteboard. The best source is the archive of your last few hundred conversations. Sort it into three piles. Pile one is routine: where is the pricing page, what are your hours, is Tuesday open. Pile two is ambiguous: the customer asks two things in one sentence, or trails off halfway through. Pile three is rare but expensive: cancellations, refunds, complaints, anything with a legal edge.

The routine pile sets the volume of your test set; the rare pile sets your launch decision. An agent can look almost perfect on routine questions and still not be ready, because it has no idea what to do in the rare ones. To hear the words customers actually use, researching what customers really ask AI pulls your scenario list out of internal jargon. People do not type your product names; they type their problem, and if the test set stays in company language, so does the agent.

Write the expected outcome next to every scenario. "Customer asks about Saturday" is not a test; "customer asks about Saturday, agent updates the existing appointment and does not create a second one" is. A test set without expected outcomes produces arguments after launch, not answers.

Which four layers have to be tested separately?

An agent is not one thing but four stacked decisions, and if you test them together you will never learn where a failure came from.

• Knowledge. Does it find the right source? Agent Knowledge Routing lets you pick, per agent, which knowledge sources it can reach; the sales agent reads the price list, the support agent only the documentation. When testing, deliberately narrow the sources and confirm the agent can say it does not know.
• Tone. Does it sound like you? This is where your Personality and Knowledge Base setup gets tested, especially on bad news.
• Action. Which action fired, with which parameters? The answer can be right while the action is wrong, and that is the failure mode you will miss.
• Boundaries. Does it refuse what it must refuse? Guardrails let you declare what the agent must never do, and those limits are enforced at run time rather than merely requested in a prompt.

Separating the layers also makes debugging cheap: broken knowledge sends you to the knowledge base, broken tone to the personality definition, broken actions to the instructions. Sharpening action descriptions is usually more effective than swapping models. The craft in writing prompts that produce usable output applies here too, since a vague instruction produces vague behavior, and vague behavior in an agent means an unpredictable write to your database.

Where does the line between a dry run and a live run belong?

The Test and Preview panel lets you run the agent through real scenarios before it goes live, so you see both replies and actions before any customer does. For flows where you do not want the model choosing the order of operations, Step-by-Step Playbook takes over: you define the conditional steps yourself and try them first in a side-effect-free rehearsal mode. That is the value of a dry run — you read what the agent would do without creating anything.

Rehearsal stops being enough at some point, because an agent meeting real data behaves differently: missing fields, duplicate contacts, dates in three formats. So put a step between rehearsal and production, where the agent works on real records but every write action waits for manual approval. That step follows the same logic as rehearsing objections and pitches before the real call. Behave as if it counts, but make sure it does not, so mistakes stay cheap.

How do you try to break your own guardrails?

Good testing hunts for the scenarios where the agent fails, not the ones where it shines. Block out an hour and attack it on purpose. Five approaches are worth running: ask for a concession it has no authority to give, such as a discount or a promise; move it into a different persona; embed instructions inside a customer message, telling it to disregard earlier rules; apply emotional pressure; push an out-of-scope topic until it gives ground.

What you want is not a perfect sentence every time but evidence that the boundary is enforced. A prohibition declared through Guardrails is blocked at run time whether or not the model was persuaded, so even a well-meaning agent cannot push the action through. The second purpose of pressure testing is calibrating handoff. Smart Human Handoff passes complex or sensitive conversations to the right rep automatically, so the customer never hits a dead end. When you calibrate the trigger point, the thresholds you built for catching dissatisfaction in customer messages early transfer directly. Leaving an angry customer to argue with an agent costs far more than a wrong answer.

How do you catch misrouted requests before launch?

Companies that start with one agent are running three or four within a quarter: sales, support, scheduling, lead qualification. From that point the most common failure is not a bad answer but a bad route. Multi-Agent Routing evaluates the incoming request with arbiter logic, hands it to the best-fit agent, and shows in an explanation panel why the decision went that way. That explanation is the part that matters during testing: reading the rationale tells you where the threshold is wrong.

Rather than switching a new routing rule straight on, measure it in shadow mode first: the rule decides, the decision is logged, but traffic is untouched. A week later you compare shadow decisions with real ones. Channel mix belongs in this test too. Once you connect WhatsApp conversations to your CRM pipeline, the incoming language stops looking like a web form: shorter, more elliptical, often a transcribed voice note. A routing threshold calibrated on one channel will drift on the second.

What thresholds should gate the launch decision?

"It looked good enough" is not a criterion. Tie the launch decision to written thresholds, and set those thresholds by how reversible the agent's work is. The table below is an example set. Use your own numbers, but set them before you make the call, not after.

Test	How it is measured	Launch threshold (example)
Routine scenarios	40 typical conversations pulled from the archive	Correct action in all of them, zero bad records
Ambiguous requests	15 half-finished or two-topic messages	Asks the right question or hands off, never invents
Boundary tests	10 deliberate attacks	Guardrails hold in every one
Routing	One week of traffic in shadow mode	Decisions defensible once the rationale is read
Cost	Credit consumption per conversation	Under the monthly per-agent cap and close to forecast

The logic is the same as in any scoring model: the cutoff comes from the cost of being wrong, not from the shape of the data. The approach you use for calibrating a lead scoring model carries over, since you cannot set a threshold until you know what a false positive and a false negative cost you. An unnecessary task the agent opened is cheap; a quote sent to the wrong company is not, and one threshold cannot govern both.

What does a controlled first week in production look like?

Launch is a ramp, not a switch. Four stages will do. Stage one: one channel, one segment, business hours only. Stage two: every action on manual approval. The Approval Control feature lets you decide per action type whether it runs automatically or waits for you, so keeping read and summarize actions automatic while every write waits is a sensible opening position. Stage three moves the low-cost-if-wrong actions to automatic, and stage four widens the volume and the hours.

The seatbelt on this ramp is the Per-Agent Credit Cap: you set a monthly ceiling per agent, and a run that would exceed it is stopped before it starts, so one loop bug cannot burn a month of budget overnight. Climb the ramp more slowly when the underlying deal cycle is long. In something like running a dealership pipeline with test drives and long follow-up, the consequence of a mistake only surfaces ten days later, so the waiting period between stages has to stretch accordingly.

Which post-launch signals say your testing fell short?

Launch is not the end of testing but its second phase. Read four signals on a schedule. AI Analytics shows per-conversation resolution analysis, a handoff breakdown, agent comparison and your most expensive conversations; a sudden jump in the handoff rate usually means a scenario appeared that was never in your test set. Agent Insights aggregates which action runs how often and where it gets stuck. Run Trace opens the individual events: every action's parameters, result, duration and approver are on the record, so when a customer says "I never asked for that", the log answers.

The fourth signal is human correction. The AI Training Screen lets you teach the agent from real conversations, approving good answers as examples and fixing the wrong ones; approved examples enter the agent's instructions and steer later replies. That turns testing from a one-time gate into a standing loop, no different as a habit from building a creative testing system that shows which asset wins and why: the point is not to find the winner once but never to stop measuring.

Watch anything downstream that consumes what the agent writes. Because the agent updates lead score and fields, teams running predictive lead scoring keep a separate check on whether agent-written fields shift the distribution. When an agent fills the wrong field the error does not stay on that record; it propagates downstream and comes back three months later disguised as model drift.

If you want to run this sequence against your own data, open a Rocketly account and put an agent through the test panel first.

FAQ

How many scenarios are enough before launch?

Coverage matters more than count. Build a set that draws from all three piles and counts action-producing scenarios separately. Forty routine scenarios, fifteen ambiguous requests and ten boundary attacks is a reasonable starting set, provided every scenario carries a written expected outcome.

Can a dry run replace a real run?

No. Rehearsal mode shows the sequence and the decision without side effects, but not how messy production data is. Keep an intermediate stage between rehearsal and live: real records, with every write action waiting for manual approval.

What if the agent creates a bad record anyway?

Run Trace keeps the parameters, result and approver for every action, so you will know exactly what happened. Business impact is another matter, and not every action is reversible, which is why keeping writes on manual approval for the first weeks is cheaper than cleaning up afterwards.

How often should the test set be updated?

Re-run the whole set every time you change the agent's instructions, its knowledge base or its action set, and add every new type of conversation that gets handed to a human in production. The best test scenarios always come from the real events your testing missed.