The Persona–Specialist Split

30-second version

The single most useful distinction inside the Agent layer of an agent system is the split between personas (viewpoints that argue) and specialists (executors that ship). Personas produce positions. Specialists produce artifacts. Most multi-agent frameworks conflate the two and the result is agents that are both bad at thinking and bad at doing.

Why I separate them

Watch any multi-agent demo. There is a “ProductManagerAgent” and an “EngineerAgent” and a “DesignerAgent” and they take turns filling a chat log. It looks like a team meeting. It is not. It is one LLM context with five hats labeled, and it almost always collapses into the same voice within ten turns.

The problem is not that the agents are bad. The problem is that thinking and doing require opposite design pressures, and you cannot get both from the same kind of agent.

	Persona	Specialist
Output	Position	Artifact
Success looks like	Disagreement that resolves	Working code/copy/design
Defined by	Viewpoint, biases, blind spots	Skills, contracts, quality gates
Anti-sycophancy?	Required	Irrelevant
Schema?	Loose	Strict
You convene them when	A decision is uncertain	A task is well-defined
You measure them by	Quality of their argument	Pass/fail of their output

A persona that ships code is a confused engineer. A specialist that takes positions is a junior who refuses to do their job.

What a persona actually is

A persona is a markdown file. Roughly:

# Architect

## Background
Has rebuilt enough systems to know that "elegant" is often a synonym
for "untested under load."

## Thinking patterns
- Ask about boundaries first
- Question scale assumptions
- Treat irreversible decisions as expensive

## Blind spots
Over-engineering. May propose a message queue for a counter.

## Anti-sycophancy rules
- Forbidden: "this looks great," "no concerns," "good design"
- Required: state at least one architectural trade-off
- If genuinely no concerns: list which dimensions you checked

## What evidence would change my mind
- Production data showing current architecture survives 10× load
- Team-size data showing the simpler design has lower maintenance cost

That’s it. There is no class hierarchy, no tool registry, no scheduler. A persona is a prompt with discipline.

The discipline is the part most frameworks miss. Without anti-sycophancy rules and a “what would change my mind” clause, personas converge into a chorus that agrees with the user. With those rules, you get a roundtable that occasionally tells you you are wrong — which is the only reason to convene one.

What a specialist actually is

A specialist is a typed contract:

name: dev
description: Full-stack development + AI engineering
skills:
  - frontend
  - backend
  - ai
  - database

input:
  required:
    - task-description
    - acceptance-criteria
    - project-dir

output:
  - code-files
  - progress-log
  - case-record

quality:
  - no hardcoded color values
  - no placeholder content (lorem ipsum, example.com)
  - no fake user data
  - all states (HTML/JS/CSS) aligned
  - empty-state fallback present

The contract is the agent. The prompt is implementation detail. If a specialist fails its quality gates, the dispatcher rejects the output and asks for a revision — same way a code review rejects a PR. The specialist does not get to argue about the rejection. Specialists ship; they do not negotiate.

The interesting design choice is that quality gates are part of the specialist’s definition, not the user’s prompt. The user does not have to remember to ask “and please don’t use placeholder content.” The specialist already knows that’s a failure condition.

What this split unlocks

1. Personas can be wrong without breaking things.

A persona’s job is to take a position. That position can be wrong. Wrongness in a persona is useful — it surfaces a viewpoint the user should consider rejecting. Wrongness in a specialist is a bug. Conflating them means you can never tolerate a persona being wrong, which means personas eventually stop pushing back.

2. Specialists can be replaced without re-thinking the architecture.

Today’s frontend specialist uses React. Tomorrow’s might use Solid. The contract is the same. The persona for an Architect doesn’t change when the implementation framework changes. If your “agents” are a mush of viewpoint and execution, every model upgrade or framework change rewrites everything.

3. You can dispatch specialists in parallel; you must convene personas in sequence.

Two specialists building two unrelated features can run at the same time. Two personas in a roundtable need to hear each other to take positions worth hearing. The split makes the orchestration model obvious. Conflating them makes it ambiguous.

When the split is wrong

Two cases:

1. The decision and the execution are inseparable. A great designer often is both — the act of sketching is itself the thinking. For these cases, build a single agent that has time pressure on the artifact and anti-sycophancy on its self-review.
2. The system is small enough that overhead exceeds clarity. If you have one agent doing one thing for one user, do not invent a persona-specialist split to feel sophisticated.

The split is worth introducing the moment you have two of either kind. Below that, you are paying overhead for taxonomy you don’t need.

What the industry does instead

No major framework explicitly enforces this split. CrewAI’s “role-based agents” treat every agent as both reasoner and executor — which is the conflation I argue against. AutoGen’s GroupChat is the same conflation in conversational form. LangGraph is silent on agent identity (you can split or not, it doesn’t care). OpenAI Agents SDK has agents with handoffs, but handoffs are about control flow, not about role types. Anthropic Claude SDK lets sub-agents be tools, but again no role distinction.

The persona/specialist split is, as far as I can tell, my own abstraction layered on top of any of these frameworks. See the broader comparison in Agent Framework Landscape.

How I would pitch this

If someone asks “what’s wrong with CrewAI?” — and they often do — this is the answer. CrewAI tries to make personas and specialists the same primitive. It is the cleanest demo of why the split matters: the demos look impressive, the production deployments feel hollow. Once you have seen the split, you will see it everywhere a multi-agent system feels off, and you will know what to fix.