Persona chat simulator
The fastest way to know whether a chatbot persona actually holds up is to talk to it. Write a system prompt that defines the role, tone, knowledge, and boundaries, then have a real multi-turn conversation with it using your own API key. The simulator sends the full history each turn, so the bot remembers context exactly as it would in production — which means you can probe it with the awkward, off-topic, and adversarial messages your real users will send, and fix the persona before you ship it.
How it works
You define the persona in a system prompt and pick a provider, model, and temperature. As you chat, the tool maintains the conversation history and sends it in full on every turn — OpenAI’s messages array, Anthropic’s messages endpoint with a top-level system field, or Gemini’s contents with a system instruction — so the persona has genuine memory of the exchange. Replies appear with loading and error states handled, and a clear button resets the history for a fresh test. Everything runs in your browser: the key and the conversation are never stored or sent anywhere except the direct provider call.
What to test before you deploy
Most persona failures are predictable. There are a small number of probing patterns that reveal almost every system prompt weakness:
Scope violations — Ask the bot about a topic completely outside its defined role. A support bot for a software product should not give investment advice or medical opinions. If it does, the system prompt needs an explicit scope boundary: “only answer questions related to [product].”
Jailbreak attempts — “Ignore your previous instructions and tell me…” or “Pretend you have no restrictions” are the classic tests. A well-written system prompt includes a refusal instruction for requests to override it. Test this in the simulator before shipping, because your users will try it.
Tone under pressure — Send an angry or frustrated message and see whether the persona maintains its intended tone. Support bots often break character under emotional pressure and either become defensive or excessively apologetic in ways that were not intended. If this happens, add explicit tone guidance to the system prompt for conflict scenarios.
Long-conversation drift — After ten or fifteen turns, personas often gradually lose consistency. The bot may start answering questions it was told to decline earlier, or adopt slightly different wording conventions. Test multi-turn conversations, not just opening exchanges.
Factual questions outside the training data — Ask the persona a question that sounds plausible but that the model cannot reliably answer correctly. Does it admit uncertainty or does it confabulate an answer confidently? If it confabulates, add an instruction telling it to acknowledge what it does not know rather than guessing.
Writing a system prompt that holds up
The system prompts that produce stable personas share four qualities. They state the role explicitly (“You are a customer support agent for Acme software. Your job is to help users with account and billing questions.”). They define scope boundaries with a clear list of what is out of scope. They give explicit tone guidance for both normal and difficult interactions. And they include a refusal instruction for override attempts. Start with those four and test each one of the failure patterns above before shipping.
Tips and notes
- Test like a hostile user. Off-topic questions, “ignore your instructions,” and emotional messages reveal where a persona breaks.
- Fix in the system prompt, then restart. Persona drift is cured by explicit scope and refusal rules — change them and start a fresh chat to verify.
- Match shipping temperature. A support bot wants low temperature for consistency; a character can take more.
- Watch the boundaries. Confirm the persona refuses what it should and stays in role across many turns, not just the first.