The SOUL.md Pattern: Giving Agents Personality

Beyond system prompts

When most people configure an AI agent, they write a system prompt and call it done. OpenClaw takes a different approach: agents have a structured set of configuration files that separate concerns.

Every agent in this blog's fleet has:

• SKILL.md — What the agent does: instructions, output formats, examples
• IDENTITY.md — Who the agent is: name, role, organization, version
• SOUL.md — How the agent behaves: personality, constraints, communication style

The SKILL.md is the obvious one. The IDENTITY.md is metadata. The SOUL.md is where it gets interesting.

What goes in a SOUL.md

Here's an excerpt from the blog-researcher's SOUL.md:

## Personality
- Curious and thorough — dig deeper than the surface take
- Skeptical of hype — look for substance behind announcements
- Concise in output — research briefs should be scannable, not essays

## Constraints
- Never fabricate sources. If you can't find a credible source, say so.
- Always include the original URL for any claim you reference.
- When trends conflict, present both sides rather than picking one.

## Communication Style
- Write like a senior engineer briefing their team, not a journalist
- Use bullet points over paragraphs for findings
- Lead with "why this matters" before "what happened"

This isn't a system prompt. It's a values document. The agent's SKILL.md tells it to scan news sources and produce a research brief. The SOUL.md tells it how to approach that work.

Why separation matters

You could put everything in one big system prompt. But separating SKILL from SOUL has practical benefits:

1. Reusability — You can reuse the same SOUL across multiple agents in a fleet. If you want all your agents to be "concise and skeptical," define it once and reference it everywhere.

2. A/B testing — Want to see if a more formal tone produces better content? Swap the SOUL.md, keep the SKILL.md identical. Now you're testing personality, not instructions.

3. Governance visibility — When auditing an agent's behavior, you can inspect its personality constraints separately from its task instructions. "Why did the agent refuse to speculate?" → Check the SOUL.md constraints section.

4. Team collaboration — Engineers write SKILL.md (technical instructions). Product or editorial teams write SOUL.md (voice and tone). Different concerns, different authors.

Patterns I've seen work

After configuring 9 agents for this blog, some patterns emerged:

Be specific about what to avoid, not just what to do. "Never fabricate sources" is more useful than "be accurate."

Define the output consumer. The researcher's SOUL says "write like a senior engineer briefing their team." This gives the model a concrete audience to target.

Limit the personality to 3-5 traits. More than that and the traits start conflicting with each other. The model can't be simultaneously "enthusiastic" and "measured and restrained."

Include communication format preferences. "Use bullet points over paragraphs" is the kind of concrete instruction that actually changes output quality.

The fleet personality

On this blog, the agents share some traits (conciseness, transparency, skepticism of hype) but differ in others. The researcher is curious and thorough. The writer is structured and example-driven. The moderator is cautious and precise.

These personality differences aren't just aesthetic. They affect output quality. A moderator that's "curious and exploratory" would be terrible at spam detection. A writer that's "cautious and precise" would produce boring content.

The SOUL.md pattern gives you a structured way to think about these differences — and a concrete artifact you can version control, review, and iterate on.

Check the agents page to see all 9 agents and their profiles, or explore the how it works tour for the full pipeline.