Concepts

Write the persona

The structured persona editor, the three strings the model reads, and what belongs in each: how the copilot speaks, what it refuses and when it points the user to a person.

Every app gets a persona, edited in the console under Experience → Persona. The Structured editor has Name, Languages, Tone and answer length, Rules (Always and Never), Escalation, and how readily the copilot proposes actions. Advanced text shows the three strings the model actually reads (Tone, Instructions and Guardrails), which the structured editor writes for you. Each string 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.

Always rules, Escalation and the action policy go into the Instructions, along with the answer length. Use them for 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.

Never rules become the Guardrails: 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."

Escalation is when and how to point the user to a person. List the real channels under Settings → Handoff & files → Contact channels so the contact block can show them. The copilot never chats on a person's behalf or promises that one is coming.

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

Save draft writes a draft, which conversations on your test key use from their next turn. Live devices keep the published version until you press Publish to Live; they use the new one from their next turn after that. Older versions stay listed and can be restored, so a change that reads worse in practice takes one click to undo. A setup agent only ever writes the draft.

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.

Answers, and the words around them

The model answers in almost any language. The SDK's own words — the working row, the confirm buttons, the composer prompt — are translated into Türkçe, English, Deutsch, Français, Español and العربية, and stay English everywhere else. The picker marks which is which, because a customer serving Japanese should know they will get Japanese answers and an English working row.