The Persona Trap
Most agent-design advice tells me to give my agents personas. The research says don't. Or at least, not the way most agent tooling assumes.
Most agent-design advice starts with the same instruction: give the agent a persona. Pick a name. Pick a job title. Write a backstory. “You are Alex, a senior security architect with 15 years of experience in OWASP compliance.” The persona is supposed to focus the model, give it character, make its output match expectations.
I did this. I named my agents. I gave them backstories. I wrote elaborate role descriptions for each one. Then I read the research and it turns out the personas were making the outputs worse.
Multiple studies have tested this directly. The PRISM study from USC tested expert personas on instruction-tuned LLMs across MMLU and MT-Bench. The Wharton “Prompting Science Report 4” tested domain-matched personas on six models with graduate-level questions. A separate study of 162 different roles tested across 2,400+ factual questions on four LLM families. Learn Prompting ran 12 personas across 2,000 MMLU questions on GPT-4 turbo. The findings are consistent.
The longer and more detailed the persona, the worse the model performed. The mechanism PRISM proposes is the most useful thing I’ve taken from this research.
When I tell a model it’s a senior security architect, it gives me a senior-security-architect-style answer. Style is what it can do. Correctness is what I actually wanted.
This isn’t an argument against telling the model what to do. Anthropic specifically recommends short domain hints. “You are a Python specialist” is a sentence. It focuses the model. It doesn’t try to install a character.
What works instead is defining the agent by function, not identity. Compare two prompts for the same job.
Bad: biography
“You are Alex, a senior security architect with 15 years of experience in OWASP compliance. You take pride in thoroughness and never let a vulnerability slip past your review.”
Good: job description
“Analyze the provided code for security vulnerabilities. Check against OWASP Top 10. For each finding, report: location, severity, vulnerability type, and recommended fix. Report only confirmed issues, not speculative ones.”
The first is biography. The second is a job description. The second gives the model more useful information and fewer distractions.
As a PM, I read agent-design advice from social media for months before I read the research that contradicted most of it. The convention of naming agents and writing personalities for them is a category error. It treats LLMs like collaborators getting onboarded. What they actually need is task specifications.
The exception that proves the rule is generative and creative work. Writing, brainstorming, roleplay. When sounding right IS the goal, a persona helps. The PRISM study saw gains on writing and roleplay tasks where tone matters more than facts. For a customer-facing chat persona where the warm tone IS the deliverable, the biography is part of the spec. For everything else it’s a distraction with a confidence cost.
What changed when I redefined my agents by function instead of identity: my agents stopped referring to themselves in the first person, stopped apologizing in their reasoning, stopped reaching for the “kind of thing an expert would say” when they should have reached for the answer. The output got plainer and more accurate.
I don’t have a clean answer yet for why the social-media convention is so different from the research. My best guess is that personas feel intuitive to humans, and the people writing the agent-tooling tutorials are pattern-matching from how human teams work. The model doesn’t work like a human team. It works like a function with a really wide input.