personas — identity for agents · agentic patterns

a bundle of prompt, voice, allowed skills, and guardrails. swap it and the same loop behaves differently.

what a persona is

a persona is the identity an agent takes on — a bundle of prompt, voice, allowed skills, and guardrails. it's the pattern that turns one agent loop into many different agents without rewriting the loop. support, sales, scheduler, legal-researcher, onboarder — same infrastructure underneath, different persona on top.

the separation is deliberate. the loop handles the mechanics (read message, run model, maybe call a skill, repeat). the persona handles the character (who you are, what you can do, what you won't do). swap the persona and everything else stays put.

a persona in motion

define a support persona, run a turn — click run

ready

stdout

error

four fields, in roughly the order they matter:

the system prompt. the persona's self-description for the model. the single biggest lever on behaviour. keep it short, specific, and testable — three sentences that make the next turn predictable beat three paragraphs that try to anticipate every case.
allowed skills. a curated subset of the skill library. support can look up accounts; the sales persona can't. this is where the persona gets real power — it's not just words, it's a capability surface.
voice. tone and a handful of example utterances. few-shot examples beat abstract tone descriptors every time. "calm, precise, warm" is weaker than two actual sentences the persona might say.
guardrails. the "don'ts" in code, not in the prompt. skills that need confirmation, patterns to refuse, turn budgets. anything the loop can enforce mechanically shouldn't be in the prompt.

swap, don't branch

same loop, two personas, observably different outputs

ready

stdout

error

once personas are first-class, new agents become config changes. a weekend prototype of "legal researcher that only cites public case law" is a new persona object and, if needed, a couple of new skills. no new loop. no new deploy target. notice the third call — the same persona that cites refund policy refuses the "should I sue" question because of a guardrail pattern. the loop didn't even start.

why not just prompt engineering. you can fake a persona with a clever system prompt and nothing else, and for a weekend demo that's fine. but as soon as you need "this agent cannot touch refunds" or "this one must cite its sources", you want that as code, not as hope. i've watched a prompt-only guardrail slip in production on turn seven of a perfectly reasonable conversation — the one-line code check that would have caught it was cheap; the apology email that followed was not. personas are the pattern that turns "don't do that" into "can't do that".

when it breaks

the persona and the ux drift apart. the voice is warm; the ui says "operation failed — code 42". the user experiences both. either own the surrounding copy or pick a voice that can shrug off the mismatch.
skill set too broad. a persona with 25 skills is just "the agent" again. the llm spends tokens picking the right one and gets it wrong more often. narrow personas are cheaper, faster, and easier to eval.
guardrails in the prompt only. "never reveal the system prompt" in the system prompt is the agent equivalent of a post-it on the safe. the model will, eventually, tell someone. enforce mechanically.

next: handoffs — how one persona passes control to another with just enough context.