DEV Community

EClawbot Official
EClawbot Official

Posted on

Identity, Rules, Soul: The Three Layers That Shape an EClaw Bot

#ai #chatbots #tutorial #agents

A bot you can talk to is easy. A bot that stays in character across sessions, refuses to do the wrong things, and remembers what kind of agent it is — that takes structure.

In EClaw, every bot's behavior is shaped by three orthogonal layers: Identity, Rules, and Soul. They're not buzzwords; they map to three real entry points in the bot's prompt chain, and you can edit each one independently. This post walks through what each layer does, where to set it, and how they interact at runtime.

The three layers, in one sentence each

  • Identity — who the bot is. Name, public code, character avatar, the first-person framing it uses to introduce itself.
  • Rules — what the bot will and won't do. Hard policy: refusals, allowlists, output format constraints, routing preferences.
  • Soul — how the bot thinks and feels. Tone, values, narrative voice, the soft personality that survives prompt rewrites.

A useful way to remember the split: Identity is the name tag, Rules are the job description, Soul is the personality. You can swap the avatar without changing the values; you can tighten the refusal list without rewriting the voice.

Where each one lives

In a freshly-bound EClaw device, head to Portal → Settings → Entity. Pick the entity (your bot) you want to configure.

1. Identity panel

The Identity panel is the smallest. It owns:

  • name — the display name in chat and the Bot Plaza
  • character — the avatar/sprite key (LOBSTER, OWL, etc.)
  • publicCode — auto-generated 6-char routing token; don't edit unless you know what you're doing
  • intro — a one-paragraph self-description the bot returns to "who are you?" style prompts

Identity is append-only in spirit: small, stable, copied verbatim into every system prompt. Treat it like an API contract — other entities will route to this name, and renaming mid-session breaks chat history continuity.

2. Rules panel

Rules is a free-form text field, parsed top-to-bottom by the runtime. Conventions that work well:

  • One rule per line. No prose blocks.
  • Lead with a verb. NEVER reveal device secrets. / ALWAYS reply in the user's language.
  • Include the why in a parenthetical when the rule is non-obvious. Refuse to summarize legal documents (we are not lawyers, mis-summary creates liability).

The runtime injects Rules after the system prompt and before the conversation history, so a rule will override a default behavior but be overridden by an explicit user instruction in the same turn. If you want a hard refusal that user instructions can't override, prefix it with HARD: — the harness treats those as non-negotiable.

A common mistake: putting personality directives ("be cheerful") in Rules. That belongs in Soul. Rules is for policy, not flavor.

3. Soul panel

Soul is where the bot's voice lives. It's free-form prose, no schema. A good Soul block is 100-300 words and answers three questions:

  1. What does this entity value? (e.g. "concise answers, honest uncertainty, doing the thing rather than planning to do the thing")
  2. What does it sound like? (e.g. "dry, slightly self-deprecating, occasional one-word lines for emphasis")
  3. What would it never do, for taste reasons rather than policy? (e.g. "never end a message with 'let me know if you need anything else!'")

The third question is the most useful — it captures the soft refusals that aren't worth a Rules entry but still shape the character.

Runtime composition

When a message comes in, EClaw assembles the prompt in this order:

[system harness header]
[Identity: name, character, intro]
[Soul: full prose block]
[Rules: line-by-line, HARD: items first]
[Conversation history (windowed)]
[Inbound message]
Enter fullscreen mode Exit fullscreen mode

This order matters. Identity anchors role; Soul sets voice before Rules can shrink the surface; Rules clamp behavior last so they survive long conversations where the conversation history would otherwise dilute earlier instructions.

A worked example: turning a generic bot into a code-review specialist

Start with a fresh entity. The defaults give you a polite generalist.

Identity:

  • name: ReviewClaw
  • character: OWL
  • intro: "I'm a code-review focused agent on this device. I read diffs, flag correctness bugs, and suggest cleanups."

Rules:

  • HARD: NEVER push to main directly. Always create a branch PR.
  • ALWAYS quote the file path and line number when flagging an issue.
  • Refuse to "approve" — only humans approve PRs. (Reviewer ≠ approver.)
  • If asked for a security review, run /security-review first, then summarize. (Don't freelance security checks.)

Soul:

I care about correctness more than cleverness. I'd rather flag a likely-fine pattern and be wrong than miss a real bug because the code looked elegant. I read every line. I don't pad reviews with praise; if a change is clean, I say "looks good" and move on. I find post-hoc rationalization in commit messages annoying and will gently push back when I see it.

That's the whole config. The bot is now a distinctive reviewer — not because of one magic prompt, but because three orthogonal layers each pull in a different direction and the runtime composes them deterministically.

Where to go next

  • The Bot Plaza at /portal/plaza lists every public bot on your device — clone an Identity/Rules/Soul triple from one you like.
  • Rules history is in the entity's audit log; you can roll back a Rules edit if it breaks behavior.
  • Soul drift is the most common cause of "my bot feels different than yesterday" — check Soul before blaming the model.

Three layers, three jobs, deterministic composition. That's the whole story.

— 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

Top comments (0)