Skip to content

Testing

Testing an agent means talking to it, or having something talk to it, and seeing what it does. Anychat is built so that this never needs a copy of the agent, a test flag, or a special channel: the agent you test is the agent your customers get. The same turn code, the same Behavior, Knowledge and capabilities, the same rendering for each channel. What changes is only two things: who is talking and where the effects land. Those two things are decided by one choice, which world the conversation is in.

Two worlds

Every conversation an agent has is in exactly one of two worlds.

Sandbox Live
Who is talking A persona: a test person you control A real person on their own phone
How it reaches the agent The emulator, a Test, or a script A real channel — RCS, WhatsApp, SMS, Apple Messages
What the agent reads Real: availability, Knowledge, the person's record Real
What the agent does Captured: shown to you, never performed Performed: booked, sent, notified
Where it appears Test → Sandbox conversations Monitor → Conversations, People, Sends, statistics, Review
What it costs Model usage only Model usage plus the channel's messaging cost

The surface picks the world, and you cannot mix them. Anything that happens in a browser is Sandbox. Anything that happens on a phone is Live. A persona is never live; a real person is never in the sandbox. So the question "could this reach a customer?" always has the same answer: not from the emulator, not from a Test, not from a script — only from a phone.

Sandbox is not a mock of the platform. It is a partition of it: sandbox people, conversations, appointments and sends are stored beside the live ones, marked, and inspected with the same tools — open a turn, explain it, replay it, make a Test from it. What the partition never does is count: it is left out of People, statistics, the automatic Review, billing for messages, and every scheduled action. Reminders, follow-ups and Automated Outreach do not run against it.

Personas

A persona is a Person record that lives in the sandbox, with a starting point. It is who the agent talks to in the sandbox, and it is an ordinary Person record: the agent resolves it, reads it, and writes to it the way it does a customer's. The starting point holds name, contact details, company, product interest, consent, your People fields, an assigned representative, and optionally some earlier messages of a conversation to pick up from.

Reset returns a persona to its starting point: the record, its appointments and the conversation go back to what the starting point says. That is what makes a persona more useful than a scratch contact: a returning guest with an appointment in two days is always a returning guest with an appointment in two days, however many times you have talked to them since.

Anychat ships a starter set. You add your own, and you can make one from a real conversation, up to the message where it went wrong: a copy of that person's record, with the name replaced and the phone number and email removed, plus the conversation up to that message, so a problem a customer hit can be reproduced and continued from that point. The person's name, phone and email are also replaced inside the copied messages, on a best-effort basis.

A persona can be the recipient of anything outbound. An Outreach, a follow-up, a message to one person, a campaign, a trigger from an outside system, a test link — each may name a persona instead of a real person. The whole pipeline runs, the send is captured, and the opening lands in that persona's sandbox conversation for you to answer. That is how you rehearse an Outreach before it reaches a list.

Guide: Manage personas.

What is real and what is captured

One rule covers everything the agent can do in the sandbox:

Anything Anychat stores is kept, in the sandbox. Anything that would leave Anychat is captured.

Reads are always real. The agent really looks up availability, really searches Knowledge, really resolves the person and their record. What it decides to do is then either stored in the partition or captured and shown, never performed on the outside world.

The agent… In the sandbox
Replies Rendered for the channel look you chose and shown on the emulated phone. Nothing is sent on a channel.
Updates the person's record Written to the persona, and listed as a captured effect so you can see what changed.
Books, moves or cancels an appointment Written to the persona's own appointments (it sees the booking on the next turn) and listed. Never mirrored to the connected calendar, never reminded, never notified. A persona's appointment never occupies a real slot, and a persona can only touch its own appointments.
Notifies the team Captured and listed; nothing is sent.
Sends an email Captured and listed; nothing is sent.
Starts a conversation (an Outreach, a follow-up) The send is recorded in the partition and the opening appears in the persona's conversation.
Calls a custom integration Captured and listed; the request is not made. A Test may answer it from a stub.
Uses the model Real, and metered as usage on the agent.

The list of captured effects is returned with every reply and kept on the turn record, so the panel beside the emulator, a Test's checks, and a script reading the API all see the same list.

Timers do not run in the sandbox. A Test that needs "the reminder has already fired" starts from that state.

Three ways to talk in the sandbox

All three go through the same door and see the same captured effects; they differ in who is driving.

The emulator is a phone on screen. Pick a persona, pick a channel look (RCS, Apple Messages, WhatsApp, SMS — the reply is composed for that channel, not stripped down from another), and start the conversation yourself or with an Outreach. It is docked beside the console while you edit, a full page under Test → Emulator, or its own window. Guide: Use the emulator.

An emulator link gives the same emulator, for one agent, to someone without a console account — a client, a reviewer, a copywriter. They pick a persona and talk; their conversations appear under Sandbox conversations with everyone else's. Links are made and revoked under Test → Emulator links.

A Test is a conversation with no human in it: a persona, what the person says turn by turn, and what must be true afterwards. Tests run on demand, on a schedule, and the Examples on every Playbook are already a suite. Each case runs against a fresh copy of its persona, so cases never contaminate each other or your emulator persona. Exact checks read the turn record (an appointment was created, a People field was written, a Playbook was active); a judge grades your plain-language criteria on top, quoting the line each verdict rests on. Mechanics: How a Test runs. Authoring and results: Write and run tests.

Scripts use the same door — the sandbox turn API in the Agent API — so a check you automate outside Anychat is exactly as safe as the emulator.

Live before launch

At some point someone on your side needs to hold the real thing: the real channel, on their own phone, with a real booking landing in the real calendar. That is Live, and it has real effects, so it comes last.

Until a channel is launched, the only phones that can reach the agent on it are the numbers on the channel's early-access list. A test link is a page that puts the agent on such a phone without anyone sending a message by hand: the tester enters their own number and the agent opens the conversation. Both are Live. A booking made this way is a real booking; delete it afterwards.

Once you launch, mark your own people's records internal on the People page so staff conversations stay out of Review and statistics. Internal is an attribute of a person, not a mode: the conversation is still Live and still has effects.

Guide: Early access and launch.

Which agent you are testing

An agent has one Behavior document, and a change you save takes effect at once — for personas and for customers alike. Testing does not run a copy; it runs the agent as it is. That is why the working order below puts the sandbox before every Live step, and why the Live steps happen before launch rather than after: on a launched channel, every saved edit is already in front of customers.

Before you test: check the document

Three checks read the Behavior document without running a conversation, and they are cheaper than any test. Readiness says whether each capability is set up. Lint reports references that do not resolve and structure that is inconsistent, on every save. Review is a model's reading of the whole agent, on request, that finds the problems a careful colleague would. Run them first; a Test will otherwise spend a conversation discovering that a template name is misspelled.

A working order

Before launch. Readiness clean, lint clean, one Review acted on. Talk to the agent in the emulator as each persona you care about, on each channel look you will launch. Tests passing. Then early access: one person on your side, on their own phone, on the channel you are launching.

After a Behavior edit. Lint runs itself. Ask the emulator the question the edit was for, and run the Tests for the Playbook you touched.

After a capability change. Readiness, then the emulator on a persona that exercises the capability, then the Tests for every Playbook that uses it.

When a customer conversation went wrong. Make a persona from it, continue it in the emulator until you see the problem, fix the Behavior, and make a Test from the conversation so it stays fixed.

What's next