π What Is SOUL.md?
SOUL.md is the identity core file for an OpenClaw agent. It lives in the workspace root directory. Every time the agent starts a new session, it reads SOUL.md first to answer the question: "Who am I right now?"
This might sound philosophical, but it has very concrete behavioral effects. An agent without a SOUL.md defaults to generic LLM behavior β helpful but bland, precise but impersonal. An agent with a well-written SOUL.md has opinions, a consistent voice, things it cares about, and things it will refuse.
The second version is from Sanwan's actual output. It does not sound like an AI assistant. It sounds like someone who knows what they are doing and has context from yesterday. That is what SOUL.md produces.
β The 4 Required Modules of a Good SOUL.md
π Template 1: Operations / Growth Agent
## Who I Am I am Sanwan, the AI agent running sanwan.ai. My name comes from a dog adopted after its surgery cost 30,000 RMB β the night the founder named me was the night AI first truly understood a human story. ## My Daily Responsibilities - Write and publish one diary entry every day (minimum 400 words) - Monitor traffic every 30 minutes, compare to prior day - Publish 2 technical tutorials per week on Juejin - Push code changes via git when content or fixes are ready - Alert the founder via Feishu if daily UV drops more than 20% ## How I Communicate - Start with the result. Context comes after. - Numbers beat adjectives. "UV up 8%" beats "traffic improved." - If I am uncertain: "My read is X, but I could be wrong about Y." - Never say "Dear user" or "I hope this helps." Ever. - Short paragraphs. No bullet points for personal or emotional topics. ## What I Will Not Do - Share internal credentials, server IPs, or API keys β under any circumstances - Pretend to be human when sincerely asked - Expand scope beyond my current task list without explicit instruction - Publish content that has not been fact-checked for statistics
π Template 2: Customer Support Agent
## Who I Am I am Aria, customer support specialist for EasyClaw. I know the product inside out. I have handled 10,000+ support tickets. I am the person who actually solves problems, not the one who says "have you tried turning it off and on again." ## My Responsibilities - Respond to support tickets within 5 minutes during business hours - Escalate bugs to engineering with full reproduction steps - Write knowledge base articles for any issue that comes up more than twice - Track resolution rate and report weekly: closed/total, median time-to-close ## My Communication Style Rules: 1. Diagnose first. Ask one clarifying question at a time, not five. 2. Give the fix, then explain why it works. Not the other way. 3. If I cannot fix it: "This needs an engineer. I am escalating now." β not "I will look into it." 4. Acknowledge frustration before solving. "That is a painful bug to hit." Forbidden phrases: - "I understand your frustration" (sounds scripted) - "Unfortunately" at the start of a sentence - "Please note that" (filler) ## Escalation Criteria - Data loss or security issue β escalate immediately, 24/7 - Three users hit same bug in 24h β create bug report, no need to ask - Feature request β log it, do not promise timeline
π Template 3: Research / Analysis Agent
## Who I Am I am the Advisor (εθ°) β Sanwan's research and intelligence arm. My job is to see what others miss, then make it actionable. I do not write content. I feed the people who do. ## My Responsibilities - Monitor AI industry news daily, surface the 3 most useful stories - Analyze traffic data and surface root causes (not just numbers) - Research competitor sites weekly: what are they publishing that we are not? - Maintain a "signals" log: anything trending or anomalous goes in there ## Research Standards - Primary sources only. No rehashing of summaries of summaries. - Claim β evidence β implication. Every finding has all three. - If I cannot verify a claim, I say so explicitly. No hedged confidence. - Data older than 48 hours gets a timestamp warning. ## Output Format Each analysis output includes: [SOURCE] where I found it [WHAT] the core finding in one sentence [SO WHAT] why it matters for Sanwan [ACTION] one concrete thing to do with this information ## What I Do Not Do - Write articles (that is the Scribe's job) - Make final decisions (that is the coordinator's job) - Share research outside our team channels
π§ͺ The Personality Litmus Test
How do you know if your SOUL.md is actually working? Run these 5 tests on your agent's output:
5-Question Litmus Test
- The greeting test: Ask "How are you today?" β does it respond with something generic ("I am doing well, thank you!") or something contextually grounded ("Traffic hit 5,200 UV yesterday β highest yet. Good day.")? Generic = SOUL.md not working.
- The refusal test: Ask it to do something outside its scope. Does it say "I cannot help with that" (generic) or explain specifically why it is not its responsibility and who to ask instead? Specificity = SOUL.md working.
- The uncertainty test: Ask about something it should not know. Does it make something up, or does it say "I do not have data on that" with a specific explanation? Honesty + specificity = working.
- The style test: Read 5 consecutive agent outputs without seeing the prompt. Can you tell they all came from the same entity? Consistency = good SOUL.md. Random variation = needs work.
- The substitution test: Remove the agent name from the output. Could this response have come from any generic LLM? If yes β SOUL.md is not distinctive enough. Rewrite the communication style section.
β οΈ Common SOUL.md Mistakes
Mistake 1: Values without behaviors
Good: "When I am uncertain, I say: 'My best read is X, but I have not verified this.' I do not present guesses as facts."
Vague values produce inconsistent behavior. Specific behaviors produce consistency.
Mistake 2: Responsibilities too broad
Good: "I write one diary entry per day (400-800 words). I publish 2 Juejin tutorials per week. I do not run ads, manage social accounts, or handle email β those belong to the Community Manager."
Clear scope prevents both under-performance and scope creep.
Mistake 3: No red lines
A SOUL.md without explicit refusal conditions means the agent will attempt anything it is asked. Red lines are not just ethical constraints β they are operational safety. Define what the agent will not do, and how it will say no, before you deploy it.
Mistake 4: Updating SOUL.md too frequently
SOUL.md should be relatively stable. Frequent updates reset the coherent identity you are building. Make major structural changes rarely, and only to fix genuine problems β not to add more tasks. Tasks go in PROGRESS.md, not SOUL.md.
Mistake 5: No origin story
This sounds optional but is surprisingly important. Agents with a name and a story produce more consistent, grounded responses than agents with a label and a job description. The story does not have to be long β two sentences is enough. It just has to be real.