Write the persona

Every app gets a persona, edited in the console under Experience → Persona. It is four fields, and each one enters the system prompt in a fixed position that the model cannot rearrange.

What belongs where

Tone is voice, not policy. "Friendly but never chatty" belongs here; "never discuss refunds" does not.

Instructions are about your domain: what your app is for, what the words in it mean, which of your actions to prefer for a common request. This is where a copilot stops sounding generic.

Guardrails are refusals and cautions phrased for a reader: "Never quote a delivery date that did not come from get_order_status." "Do not give tax advice." "If someone asks to cancel a shipped order, say it cannot be cancelled and offer a return."

What the persona is not

It is not a security boundary. A guardrail is an instruction to a language model, and a model can be argued with. The things that genuinely cannot happen are enforced outside it:

• The copilot can only call actions you registered, and the console can disable any of them at runtime.
• Write and destructive actions cannot execute without a confirmation card that our servers build from your template and the parameters they validated.
• The model can only emit components from the catalog, and it cannot emit a confirmation card at all.
• Knowledge and app state reach the model inside tags marked as untrusted data, with instructions not to follow directives found there.

Put your refusals in guardrails because they improve the answer. Put anything whose failure would be a real incident behind an action's risk level.

Versions

Saving creates a new version and activates it, and live devices use it on their next turn. Older versions stay listed and can be restored, so a change that reads worse in practice takes one click to undo.

Writing one that works

Be concrete and short. A persona competes for attention with the rendering rules, the action list and the conversation itself; three sharp sentences outperform a page.

Name the actions you want preferred, by name. Name the words your users use. Say what to do when the copilot cannot help, because "escalate to support" is a real answer and the model will otherwise invent one.

Then test it on a test key, where nothing is billed, and read the transcripts on the Conversations page rather than guessing.

Seeing whether an edit helped

Every save writes a new version and the old ones stay, so restoring one is a click. What is easy to miss is that turns now record which version wrote them: the console's Analytics page breaks turns, ungrounded rate and ratings down per version.

That is the honest way to iterate on a persona. A guardrail you tighten can quietly make the copilot refuse things it should do, and the only way that shows up otherwise is a feeling that it got worse. Versions that predate the measurement are absent from the list rather than shown as zeroes, because "we did not measure this" and "this performed badly" are different facts.

The languages it answers in

By default the copilot answers in whatever it is addressed in. That is the right default and the wrong rule for a business: a clinic serving Türkiye and Russia has two languages its staff can read a transcript in, and an answer in a third — because somebody's phone is set to Thai — is a conversation nobody at that company can check, support or correct.

Under Experience → Persona, name the languages you can stand behind. The device still decides which of them is used: an app that has named Turkish, Russian and English answers a Russian phone in Russian with nobody configuring that. The list only says what happens at the edge — a language nobody named falls to the first one you picked, which is why the order is a decision.

Pick none and nothing changes.