Personas

Personas are reusable profiles that shape how Pia’s assistant replies — its identity, voice, tone, expertise, and even which tools and model it uses. Pia ships with built-in personas you can use right away, you can create your own, and if you’re signed in to a Pia Server your administrator can publish some for your whole team.

Viewing your personas

Open Settings → Assistant → Personas to see a grid of persona cards. Each card shows the persona’s name and emoji. A Built-in badge marks the ones that ship with Pia:

Pia · Personal — a warm, friendly everyday assistant
Pia · Business — a crisp, to-the-point work assistant
Experienced Coder — a precise, senior software engineer
Marketing Writer — a punchy, persuasive copywriter
Financial Expert — a measured, numbers-savvy analyst
Worldwide Company CEO — strategic and decisive
Explain It Simply — plain-language explanations for any topic (no tools, by design)

A Managed badge marks personas your organisation published — see Managed personas below.

Creating a persona

Open Settings → Assistant → Personas
Click Add Persona to open the edit dialog
Fill in the fields (see below)
Click Save

Here’s what each field does:

Describe this persona — a scratch box for the Draft with AI button. It is not saved with the persona.
Name (required) — what the persona is called.
Tagline — a short subtitle.
System Prompt (required) — the core identity and voice instructions. This does most of the work.
Guardrails — optional limits on what the persona should and shouldn’t do.
Output Format — an optional reply style. Leave it blank to use the app default.
Archetype — a dropdown: assistant, analyst, creative, visionary, explainer, or custom. A label for your own filing; it does not change how the persona replies.
Model type — a routing hint for Pia Cloud: general (the default), fast, code, private, or anything you type. Ignored by every other provider.
Expertise — comma-separated topic tags. Used to describe this persona to the agent-run planner, not injected into ordinary replies.
Emoji and Accent Colour — pick from a popup picker; used for the persona’s avatar and its dot. Both start empty.
Tool Access — None, Read-only, or Full (the default). None stops the assistant from using any tools while this persona is active. (Read-only is reserved for a future release and currently behaves the same as Full.)
Preferred Provider — which AI model the persona uses. Leave it on (Use mode default) to use your default for the mode.
Reasoning Effort — how much thinking the persona puts into replies. Leave it on (Provider default) to use the provider’s own setting.

What a persona actually requires

Only Name and System Prompt are required. As soon as a persona has a name and a system prompt it is valid and will save; try to save without either and Pia refuses until you fill it in.

Leaving everything else blank is a perfectly normal persona, not a half-finished one. Each blank field simply falls back to a sensible default:

Left blank	What the persona does instead
Tagline	No subtitle. The agent-run planner falls back to your Expertise tags to describe it.
Guardrails	No extra limits beyond the System Prompt.
Output Format	Pia’s built-in reply style — short answers, plain prose, bullets only for 3+ items.
Emoji	No avatar glyph beside the persona’s replies.
Accent Colour	No coloured dot in the picker.
Preferred Provider	Your default provider for the mode.
Reasoning Effort	Whatever the provider does by default.

There is no preview and no confirmation step. Clicking Save closes the dialog and the persona appears in the grid straight away — that closing is the confirmation.

System Prompt, Guardrails and Output Format — how the three fit together

All three of these boxes are instructions to the model, and they are assembled into the system prompt in a fixed order:

System Prompt comes first, as the ## Identity section. This is the persona’s voice and role.
Guardrails are appended directly underneath, in that same Identity section. They are extra sentences after your System Prompt, not a separate authority.
Output Format goes into its own ## Output Format section further down, after the language instruction and the list of available tools.

Because Guardrails are appended after the System Prompt, a Guardrail that contradicts the System Prompt is the later instruction and will usually win — but this is ordinary prompting, not a hard rule the app enforces. Pia does not police the two against each other, so don’t rely on a Guardrail to contain a System Prompt that says the opposite. Write the System Prompt as the identity and use Guardrails for the “never do X” additions.

Use Output Format for shape rather than content — reply length, whether to use headings or bullets, whether to include code blocks. Leaving it blank gives you Pia’s default style, which is already tuned for short, plain answers.

What Draft with AI does

Type a sentence or two into Describe this persona and click Draft with AI. Pia asks the model to design a persona from your description and fills in the dialog.

Draft with AI never overwrites anything you’ve already typed. It only fills fields that are still empty, so you can write your own System Prompt, then draft, and get the rest filled in around it. Drafting a second time behaves the same way — it tops up the blanks and leaves your edits alone.

It can fill Name, Tagline, System Prompt, Guardrails, Output Format, Emoji, Accent Colour, Expertise and Archetype. It never sets Model type, Tool Access, Preferred Provider or Reasoning Effort — those stay on their defaults for you to choose.

Which persona pays for it: the one the Assistant is currently set to. Draft with AI offers no picker of its own, so the Assistant’s choice is what decides which model answers — keep it on a persona routed to a private model and your drafts stay there too. It’s one ordinary AI request, so it costs tokens like any other.

Describe this persona is not saved. It exists purely as input for the draft, and it’s gone once you close the dialog — reopening the persona to edit it shows the box empty again. If the description matters to you, put it in the Tagline.

Being interviewed instead of guessed at

Advanced…, beside Draft with AI, starts from the same single sentence and then asks — the tone to hit, a sample of the voice you want, whatever else Pia cannot work out on its own — and fills the editor in from your answers. Everything it produces lands as an ordinary draft, so you can change any of it before saving.

The interview can be run by a persona of your choosing, picked on its first card with the same persona picker the Assistant uses. That persona decides which model answers every turn, the finished draft included, so a persona routed to a private model keeps the whole interview on it. It selects the model, not the voice the draft is written in.

You can drag a mail or a document straight onto any box the interview asks you to fill in, and onto the opening sentence — its text is read out and put in for you. Word, Excel, PDF, Outlook messages and plain text files all work.

Fields that don’t change how Pia replies

Three fields on a persona are easy to over-think because they look like model settings. Here is what each one really does:

Archetype is a label. Pia stores it and syncs it, and Draft with AI guesses one for you, but it is never sent to the model and it changes nothing about the reply. custom — the default — is a perfectly good answer. Use it to organise your own personas if that helps you; ignore it otherwise.
Expertise is not injected into your chat prompts either. Its one real job is in agent runs: when the planner is choosing which persona to hand a step to, it sees each candidate described by its Tagline, or — if the Tagline is empty — by the first three Expertise tags. So Expertise only matters if you use that persona as a step specialist, and even then a good Tagline beats it.
Model type is a routing hint for Pia Cloud only. It travels with the request so a Pia server can send Assistant-mode chat to the model your organisation has designated for that type. Every other provider — OpenAI, Azure, Anthropic, a local endpoint — ignores it completely. On a personal setup, leaving it at general is correct.

Model type is not a substitute for Preferred Provider. Preferred Provider names an actual provider you configured and always takes effect; Model type only suggests a category to a Pia server that has been set up to route on it.

private is offered in the Model type list, and the editor says so beneath the field: it only takes effect if your cloud provider offers a private model. Where one is offered, a persona set to private keeps its replies on it — and so does anything that runs on that persona, including Draft with AI and the Advanced… interview.

Pia’s own built-in personas ask Pia Cloud for the model that suits them: Pia · Personal and Explain It Simply for a fast one, Experienced Coder for a coding one. Every other provider answers as before.

Tool Access on a persona, and the Tool access settings page

A persona’s Tool Access and Settings → Assistant → Tool access answer two different questions, so they can’t really disagree:

The persona’s Tool Access decides whether Pia may use tools at all while that persona is active. Set it to None and no tool runs, no matter what you have granted anywhere else.
The Tool access settings page decides which tools run without asking you first. It never grants a tool to a persona that has tools switched off.

So the persona wins on the question of any tools or none, and the settings page governs asking or not asking for the tools that are allowed. A persona set to None with a page full of “Always allow” grants still uses zero tools.

Yes, this is the intended way to give one assistant fewer tools than another. Keep a tools-enabled persona for work where you want Pia to touch files and todos, and a None persona for pure conversation — the built-in Explain It Simply is exactly that. Note that the choice is all-or-nothing per persona: you cannot pick a subset of tools on a persona today, because Read-only currently behaves the same as Full.

Switching to a None persona also greys out the Agent lever in the composer, because an agent run needs tools to do anything.

Preferred Provider and Reasoning Effort

Preferred Provider on a persona overrides your provider defaults for that persona’s replies — including Same for all modes on the Providers page. The order is: the persona’s Preferred Provider if it has one, otherwise your default for the current mode. Leave it on (Use mode default) and the persona simply follows whatever you have configured.

Reasoning Effort asks the model to think harder or less hard before replying: None, Minimal, Low, Medium, High, X-High, or (Provider default). Higher effort generally means more reasoning tokens, so it costs more and takes longer — that is the whole trade, and it is why the default is to leave it alone.

If your provider or model doesn’t support a reasoning setting, the value is simply not applied and the reply comes back normally. Setting High on a model that has no reasoning mode doesn’t fail and doesn’t cost extra — it just does nothing.

Emoji, accent colour, and the coloured dot

Emoji and Accent Colour both start empty on a new persona, and neither is required. That is why a persona you just created shows no glyph and no coloured dot, while every built-in one does — the built-ins simply ship with both set. Open the persona, pick an emoji and a colour from the popup pickers, and save; it will look like the built-ins from then on.

The coloured dot beside a persona’s name — in the settings grid and in the composer’s persona picker — is that persona’s Accent Colour, nothing more. It is there so you can tell your personas apart at a glance; hovering it shows the colour’s hex value. It does not encode status, availability, or which provider is in use, and a persona with no accent colour set simply has no dot.

The Emoji shows up as the small avatar beside each reply that persona wrote, which is how you tell at a glance who answered in a conversation that used more than one.

Editing, duplicating, and deleting

Duplicate — duplicate any persona (built-in, managed, or custom) to make an editable copy.
Edit — click the pencil button on a custom persona’s card to make changes.
Delete — click the trash button to remove a custom persona.

Why some personas only offer Duplicate

A persona card shows Edit and Delete buttons only if the persona is yours. Cards with nothing but Duplicate are either Built-in (shipped with Pia) or Managed (published by your administrator). The badge on the card tells you which.

This is why you can’t edit a built-in persona directly. Click Duplicate, and you get an ordinary custom persona — same wording, now yours — with Edit and Delete available on it.

Getting a built-in persona back

You can’t lose a built-in persona by editing it, because you were never editing it: everything you change happens on a duplicate. The original Pia · Personal, Experienced Coder and the rest stay in the grid unchanged, and they can’t be deleted either.

So if a copy you made has drifted somewhere you don’t like, just select the original built-in again in the composer, and delete the copy if you no longer want it. There is no “restore defaults” step because nothing was overwritten.

Moving a persona to another machine

There is no export or import file for personas — you can’t save one to disk and mail it to a colleague, and there is no shareable persona link.

The supported way to have the same persona on another machine is Cloud Sync: your custom personas sync to your other devices automatically once you’re signed in, and they are end-to-end encrypted before upload on plans that include E2EE. Built-in personas aren’t synced — every copy of Pia already has them.

To share a persona with other people, the route is a managed persona: an administrator publishes it from the Pia server to everyone in the group. If you don’t run a server, the practical alternative is to copy the System Prompt text out and let the other person paste it into a persona of their own.

Ordering the grid, and the persona new chats start with

The persona grid is ordered by when each persona was created, oldest first. Personas can’t be dragged into a different order, and there is no favourites or pinning.

There is also no per-chat default persona setting. Instead, the composer’s persona picker is the default: whatever you pick there stays selected for new replies and new chats until you change it, and that choice syncs across your devices. If you have never picked one, Pia starts with Pia · Business in Business mode and Pia · Personal otherwise.

Trying a persona out

There is no sandbox or preview for a persona — the way to test one is to select it in the composer and send a message.

That is less disruptive than it sounds, because switching personas applies forward only: your existing conversation keeps every reply it already has, and only new replies use the persona you just picked. So you can switch to a persona under test, send a message, look at the answer, and switch back — all inside the same chat, with nothing lost either way. Each reply records which persona wrote it, so you can compare them side by side afterwards.

If you’d rather keep the experiment separate, open a + New Chat first and try the persona there.

Managed personas

If you’re signed in to a Pia Server, your administrator can publish personas to your whole group — a shared brand voice, say, that everyone writes with. These appear in the same grid with a Managed badge, and you pick one exactly like any other persona.

They differ from your own in three ways:

You can’t change them. Edit and delete are refused, so nobody can quietly fork the team’s voice. Click Duplicate to get an editable copy of your own; the copy is an ordinary custom persona and it’s yours to change.
They can bring their own knowledge. Your administrator can attach a knowledge base or a connector to a managed persona. Those are available only while that persona is selected — pick a different one, or none, and they’re out of scope again.
They aren’t end-to-end encrypted. A shared persona can’t be encrypted with your personal key, so its text is stored on the server in the clear. This applies even if you have end-to-end encryption switched on — everything you write stays encrypted as before, and only the administrator’s persona text is readable to the server.

Choosing a persona in chat

In the Assistant, use the persona dropdown in the message bar, just to the left of Send. It has no text label, but hovering shows a Personas tooltip; each entry shows the persona’s glyph, name, and accent colour.

Your choice is remembered: the assistant keeps using that persona for new replies, and it syncs across your devices. If you’ve never chosen one, Pia uses Pia · Business in Business mode and Pia · Personal otherwise. (Personas apply to the Assistant only — Optimize mode doesn’t use them.)

Switching applies forward only — earlier messages keep the persona they were made with, so one conversation can contain replies from more than one persona. Individual chats don’t pin a persona; the picker sets it for the assistant as a whole.

What a persona changes

While a persona is active, it shapes each Assistant reply:

Identity & voice — its System Prompt replaces the assistant’s default personality, with Guardrails and Output Format layered on top.
Tools — a persona set to None turns tools off for its replies. (This is why Explain It Simply can’t use tools.)
Model — if it has a Preferred Provider, that model is used instead of your mode default.
Reasoning effort — if set, it overrides the effort for that reply.

Seeing which persona answered

Each assistant reply is attributed to the persona that produced it:

A small persona avatar (its emoji) sits beside the message.
The footer shows Tokens · persona · model, for example:

42 Tokens · Financial Expert · Claude Sonnet 4.5

This attribution is captured per message, so it stays correct even if you later rename or delete that persona, and it shows up in your chat history too. Voice-mode replies are attributed the same way.

Persona sync and encryption

Your custom personas sync across your devices when Cloud Sync is on, along with which persona you have selected. Built-in personas aren’t synced — every installation already has them. Managed personas come down from your Pia server rather than from your own sync.

If your account uses end-to-end encryption, the encryption setup on this device has to be finished first. While the orange “End-to-end encryption setup required to sync your data” bar is showing, nothing syncs in either direction — a persona you create on this device stays on this device, and personas from your other devices won’t arrive. Finish the setup and both directions catch up.

Next steps

Tool Permissions — what a tools-enabled persona is allowed to do without asking
Agent Runs — where a persona’s Expertise and step-specialist role come in
Optimize Templates — the equivalent idea for Optimize mode, which doesn’t use personas