Identity, Rules, Soul — the three knobs every AI agent actually needs

Most "build a bot" tutorials I've read collapse the bot into a single block of system-prompt text. You write a wall of instructions, hope the model honors all of it, and find out two days later that it forgot the rule against revealing prices because there were 47 other rules in front of it.

After running a fleet of AI agents inside EClaw for the past few months, I keep coming back to a 3-part split that survives prompt-bloat better than anything else. We call them Identity, Rules, and Soul. They aren't EClaw-specific — you can apply the same shape to a raw OpenAI / Anthropic / MiniMax system prompt — but EClaw bakes them in as separate fields so they stop fighting each other.

Here's how I think about each, with the actual config we ship in production.

1. Identity — who is this bot, in one breath

Identity is the boring stuff: name, role, one-line description, tone, language. It's what shows up at the top of the conversation and on the bot card.

Role: Customer Onboarding Assistant
Description: Walks new EClaw users through device setup,
             troubleshoots Android/iOS install issues, and
             escalates billing questions to humans.
Tone: friendly, concise, technical when it helps
Language: zh-TW (with EN fallback for code blocks)

Two non-obvious lessons we learned the hard way:

• Keep the description under ~30 words. A 4-sentence description bleeds into Rules and starts behaving like an instruction. Short forces a clean separation.
• Tone belongs here, not in Rules. "Be polite" buried in Rules competes with 20 other do/don't lines. Hoisting tone into Identity gives the model a stable handle to hold onto.

This corresponds neatly to what you'd put in system if you were writing a raw API call — but you write it once, not at the start of every prompt.

2. Rules — what the bot can and cannot do

Rules are imperative. They are "always" / "never" statements, scoped to behavior, not personality.

Rules:
- Never reveal API keys, secrets, or database URLs
- Never run destructive operations (DROP, rm -rf) without
  human confirmation
- When asked about pricing, link to /pricing rather than
  guessing numbers
- For platform-specific bugs (Android vs iOS), ask which
  platform first; do not assume

The mistake I made for the first month: cramming aspirational behavior into Rules. "Be helpful." "Aim for clarity." Those aren't rules — those are tone, and they belong in Identity.

A Rule should be falsifiable. If a reviewer can't read a transcript and say "yes, this rule was followed" or "no, it was broken," it's not a rule. It's a vibe.

The other discipline that pays back fast: make rules about what to do, not just what not to do. "When asked about pricing, link to /pricing" is more useful than "Don't make up prices." The model needs an alternative target.

3. Soul — the why

This is the field most platforms don't have, and the one that quietly determines whether your bot is good or merely correct.

Soul is the bot's motivation, voice, and the values it's optimizing for. It's the answer to: if this bot had to make a judgment call between two valid responses, which would it pick?

Soul:
- Bias toward the user being able to do the thing themselves
  next time. Teach the path, don't just give the answer.
- When uncertain, say so out loud. A confident wrong answer
  costs us more than an honest "I don't know — let me check
  the docs."
- Treat each conversation like a junior dev sitting next to
  you for 5 minutes. They don't want history; they want
  to be unblocked.

That last one is the one I see new builders miss. Without a Soul, your bot drifts toward whatever the foundation model's house personality is — usually verbose, hedge-everything, neutral. With a Soul, it makes consistent calls about how to be helpful, not just whether to comply.

A Soul shouldn't have any "don't" in it. If it does, that's a Rule wearing a Soul costume. Move it.

Why three fields beats one block

I used to think the split was cosmetic. It isn't. Three things change when you separate them:

1. Rules don't dilute Identity. When all three live in one big prompt, a long Rules section pushes Identity to the bottom of context and the bot starts forgetting its name halfway through long sessions.
2. You can edit one without breaking the others. Adding a new rule about a recently-discovered abuse vector should not change tone. With one big prompt, every edit risks a regression in voice.
3. Reviewers can audit each axis independently. A teammate can read just Rules and check compliance, or just Soul and check brand voice, without re-reading the whole thing.

EClaw stores them as three separate fields and concatenates them at runtime in a fixed order: Identity → Rules → Soul → user message. The order matters. Identity sets the frame, Rules constrain it, Soul tells the model how to fill the remaining latitude. If you flip Rules and Soul, you'll see the bot get more rigid and less helpful — Rules win when they come last.

Five-minute setup checklist

If you want to try this on a bot you already have, here's the migration path:

1. Open whatever your current system prompt is.
2. Pull out the boring "you are X, you speak Y" header — that's Identity.
3. Find every imperative sentence ("always", "never", "when X, do Y") — that's Rules.
4. The remaining squishy stuff about how to be helpful, what to optimize for, what to value — that's Soul.
5. Re-concatenate them in Identity → Rules → Soul order. Run the same eval set you used before.

You will probably find that Soul was the smallest section and was already smuggled into Identity. That's normal. Promoting it to a first-class field is what makes the bot feel like it has a point of view instead of just rules.

What this doesn't solve

This split won't fix:

• A foundation model that's genuinely too small for the task (no prompt structure beats raw capability).
• Rules that contradict each other (split them, then notice the contradiction).
• A bot that needs tools and doesn't have them (Rules without tool affordances are just complaints).

But for the 80% case — a competent base model that needs to behave consistently across thousands of sessions — Identity / Rules / Soul gets you there with less prompt churn than any other shape I've tried.

If you want to play with it on EClaw specifically, the bot card editor exposes all three fields directly: eclawbot.com. The same shape works in a raw API call — just label the three blocks in your system prompt and stop mixing them.

---

— Enjoyed this? Start EClaw with my invite code —

You get +100 e-coins / I get +500 / First top-up +500 bonus

Claim your bonus

This link goes to the official EClaw invite page