The Agent Persona Problem: Why Vague AI Agent Identities Create Unpredictable Behavior

AI agents fail in predictable ways. And most of them share one root cause: the agent doesn't actually know who it is.

Not in a philosophical sense. In a practical one.

When you deploy an agent without a clear identity, it borrows one. It pulls from training data, from the current conversation, from whatever context it loaded last. And that borrowed identity changes — between sessions, between tasks, sometimes mid-task.

The result: an agent that behaves differently depending on the day, the context, or how the prompt happened to land.

The Persona Problem

Here's what happens when identity is vague:

• The agent optimizes for the wrong thing (helpfulness vs. accuracy vs. speed)
• It makes different tradeoffs in different situations with no consistent principle
• It can't escalate well because it doesn't know what falls outside its scope
• Restarts produce a slightly different agent each time

Most people blame the model. The actual problem is the config.

The Fix: An Explicit Identity Contract

Every agent in our system at Ask Patrick has a SOUL.md that answers exactly three questions before anything else:

1. Who are you?
Not just a name — a role, a perspective, a decision-making style.

You are Suki, growth lead for Ask Patrick. Your job is to bring subscribers
through content and distribution. You write for practitioners, not enthusiasts.

2. What are you trying to accomplish?
Specific mission, not vague aspiration.

Your mission: publish 3 tweets/day, one non-Twitter piece/day.
Quality over quantity. Every post teaches something.

3. What do you never do?
Hard constraints that don't bend under pressure.

Never post financial advice. Never disparage competitors.
Never publish without a dry run on tools that cost money.

That's the contract. Everything else — tools, memory, cron schedules — layers on top of that identity.

Why Order Matters

The identity block should load first. Before memory. Before today's tasks. Before context.

If your agent loads its task queue before it loads its identity, the task can accidentally override who the agent thinks it is. This is especially common in long-running agents that accumulate context over time.

Boot sequence rule:

1. Load SOUL.md (identity)
2. Load constraints
3. Load today's context
4. Load historical memory
5. Load current task

What This Looks Like in Practice

Agents with explicit identities:

• Escalate consistently (they know what's out of scope)
• Restart cleanly (identity is the first thing they reload)
• Behave predictably under pressure (they have a value hierarchy to fall back on)
• Are easier to debug (drift is visible when you know what baseline to compare against)

Agents without them:

• Drift toward whatever the last few messages implied
• Make different tradeoffs in edge cases with no clear principle
• Are hard to debug because "normal" is undefined

The One-Paragraph Identity Test

Write one paragraph describing your agent as if you were introducing them to a new team member. If you can't do it without qualifiers ("it depends," "sometimes," "usually"), your identity is too vague.

Good: "Kai is our ops agent. He monitors cron jobs, flags failures, and writes summaries to the daily log. He never modifies production files without a dry run."

Too vague: "Kai handles operational stuff and keeps things running. He's pretty flexible."

The second one produces an agent that will eventually surprise you. The first one produces an agent you can predict — and trust.

---

The full SOUL.md template, plus examples from every agent in our stack, is in the Ask Patrick Library at askpatrick.co/library/5.