Test your agent

Try an agent before it ever calls a real customer - simulate for free, then hear it live.

Never publish an agent you haven’t heard. The good news: you don’t have to launch a campaign and dial a stranger to find out whether your agent actually works. oyehello gives you two ways to test it first - one that’s instant and free, and one that puts a real call on your own phone.

The golden rule is simulate first, call second. A simulation runs in seconds, costs nothing, and catches almost every problem - a fuzzy opening, a wrong turn, a tool that fires at the wrong moment. Only once the logic is right do you spend a minute (and a little wallet balance) hearing it out loud.

Where you’ll find this: the test tools live right inside the agent builder. A prompt-based agent has a “Test with a simulated customer” panel on the last step; a flow agent has a Test drawer with a Simulate tab and a Test call tab. Either way, you can test a draft - nothing has to be published to simulate.


Way 1 - Simulate against an AI customer

A simulation is a full call where the platform plays the customer and your agent plays itself. No phone rings, no one is dialed, and it’s never billed. It’s the fastest way to check that:

  • The greeting and persona sound right.
  • The call takes the branches (or covers the steps) you expect.
  • Tools fire at the right moments - and not the wrong ones.
  • The agent stays in language and handles a “no” gracefully.
  • The right information actually gets captured.

There are two flavours of simulation depending on the kind of agent you built.

Scored simulation (prompt-based agents)

On the final step of the agent builder, hit Run simulation. The platform role-plays a customer, runs a short call end to end, and then hands you a verdict. You’ll see:

  • Goal met / Goal not met - did the call actually reach the outcome you set as the call goal?

  • Compliant / Compliance risk - did the agent stay inside its guardrails and the rules of its compliance pack, or did it stray?

  • A short summary - one line on how the call went.

  • Issues - a bulleted list of concrete things that went wrong, if any.

  • The full transcript - every line, labelled Agent and Customer, so you can read exactly where it drifted.

  • Captured fields - the structured data the agent pulled out (the same “What to capture” fields you set up), shown with their values so you can confirm they filled in correctly.

  • Tip: read the transcript top to bottom before you touch anything. Nine times out of ten the fix is obvious once you see the exact sentence where the call went sideways - a vague purpose, a missing fact, a guardrail that was too loose.

Test-drive a flow (flow agents)

A flow agent has branching logic, so its simulation is interactive. Open the Test drawer, go to the Simulate tab, and hit Start test. Then you type what a caller would say, turn by turn, and watch the agent respond. It runs the real flow engine against your typed replies, so it behaves exactly like a live call would - just in text.

What makes this tab powerful for debugging:

  • “At node” header - a live badge at the top always tells you which node the agent is currently running on. This is how you confirm the call is taking the branch you intended, not sliding into the wrong one.
  • Captured so far - a running panel of every variable the flow is meant to capture, showing its value or “not set” as the conversation fills them in.
  • Start at node - you don’t have to replay the whole call to test one branch. Jump straight to any node (“Objection handling”, “Book meeting”) and exercise just that part.
  • Test variables - a real call fills placeholders like {name} or {amount} from your calling list. Here you type sample values so the agent doesn’t voice a blank {variable} while you’re testing.

If “Start test” is greyed out: your flow has blocking errors. The builder lists exactly what to fix above the canvas - a node with no way out, a dangling transition. Fix those first; you can’t simulate (or publish) a broken flow.

The adversarial stress test (AI-generated flows)

If you built your flow with the Generate flow AI helper, it was already stress-tested for you before you ever saw it. Behind the scenes, the platform role-plays your flow against a whole cast of difficult callers - all at once - and scores the result out of 100, then automatically fixes the weak spots and tries again until it passes.

The personas it throws at your flow:

  • Interested - a normal, terse caller who says “sure”, “go on”, and expects you not to ask the same thing twice.
  • Curious - wants details before committing, and asks questions first.
  • Not interested - politely but firmly declines and won’t be talked round.
  • Bad time - is busy and wants you to not proceed right now.
  • Skeptical - suspects a scam and demands to know who’s calling and how you got their number.
  • Wants a callback - can’t talk now and asks you to call back later.

The reason this matters: it’s easy to build a flow that works beautifully for the one person who says yes to everything, and dead-ends the moment someone declines or asks a question. This test catches exactly that. You can’t run it on demand as a separate button - it’s baked into flow generation - but it’s why an AI-generated flow tends to handle a “no” gracefully out of the box.

  • Do this yourself in the Simulate tab: you don’t need the AI to think like those personas. Run the flow a few times and be each one - a cooperative caller, a confused one, someone in a hurry, someone annoyed, someone who just says “no”. If the agent recovers cleanly every time, you’re in good shape.

What to check while you simulate

Whichever kind of simulation you’re running, look for these:

  • First impression - does the opening make sense in the first five seconds? Who’s calling and why should be clear immediately.
  • The branches - does a “yes” go one way and a “no” go another, cleanly? Nobody should get stuck on one node being re-asked the same question.
  • Objections and questions - if the caller pushes back or asks “what is this about?”, does the agent answer and stay in the conversation, rather than hanging up on an engaged person?
  • Language - if you set a secondary language, reply in it and check the agent switches instead of ploughing on in the first one.
  • The goal - does the call actually reach the outcome you wanted, and capture the fields you need?
  • The ending - does it wrap up with a proper goodbye, and not hang up mid-question (“what time works for - “ click)?

The most common bug we see: a flow that ends while still asking something. Any “ask” - a callback time, a phone number, a qualifier - belongs before the closing line, not on it. If a simulated call ends on a question, move that step earlier.


Way 2 - Place a real test call

Simulation checks the logic. A real test call checks the voice - the actual speaking pace, the pauses, whether the agent talks over you or leaves an awkward silence, and how fast it responds. Some things you can only hear.

To place one, you tell the agent to ring your own phone:

  1. Enter the number to call (your mobile). For a flow agent this is on the Test call tab; for any agent you can also open the Test call action from the agent’s card.
  2. Verify the number. For security, you may be asked to enter a 6-digit code sent by SMS the first time you use a number - this stops anyone dialing a number they don’t own.
  3. Pick a caller ID if you own more than one phone number (the number the call appears to come from).
  4. Fill in the variables - the same placeholders ({name}, {amount}) a real campaign would supply, so the call sounds like the real thing.
  5. Hit Start call. Your phone rings in a few seconds, and you’re talking to the agent live.

This runs the entire pipeline - real voice, real latency, real tools - exactly as a customer would experience it, without launching a campaign against anyone.

A few things to know before you dial:

  • A test call is a real call. It uses your published agent config, needs an active phone number and wallet balance, and is billed per minute just like any other call.
  • It ignores the calling window. You can test at any hour - the calling-time rules only apply to campaigns.
  • A flow agent must be published to place a real call. Only a live agent can be dialed. (Simulation, remember, works on a draft - which is exactly why you simulate first.)
  • A real call always starts at the greeting. The “Start at node” jump is a simulation-only convenience; you can’t begin a live call halfway through a flow.

The latency panel (internal)

If you’re on an oyehello internal account, a test call also shows a latency panel - a live, stage-by-stage breakdown of how long each part of a turn took (hearing the caller, thinking, speaking). It’s a debugging tool for tuning speed, not something the average tenant needs, and it never affects the call itself. You can also load a past call’s timeline by its interaction ID to see where a slow turn came from. If you don’t see it, you don’t need it.


Then iterate, and publish

Editing is cheap - that’s the whole point of testing before you go live. Adjust a prompt, a transition, a guardrail, or a tool, then simulate again. Because a simulation is free and instant, there’s no excuse for publishing a call you haven’t watched succeed against a cooperative caller and a difficult one.

When it behaves the way you want across your test cases, hit Publish. Now your campaigns (outbound) and phone numbers (inbound) can point at it, and it’s live on real calls. Changed something later? Test again, then Republish to push the update.


Next: Campaigns → - point your tested agent at a calling list and start dialing for real.