I thought my agent needed a huge soul.md until a 52-word file worked better

I used to think better agent behavior came from a bigger soul.md.

You know the file:

• tone rules
• personality rules
• edge cases
• values
• backstory
• workflow preferences
• weird little reminders you swear matter

It starts as “just a few notes” and ends up as a 1,500-word manifesto that gets injected into every run.

I’ve built that version. It feels smart for a while.

Then the agent gets more obedient and less useful.

It starts protecting its persona better than your actual state.

And after looking through a couple OpenClaw threads, I think the better pattern is much simpler:

• tiny soul.md
• markdown save files for canonical state
• retrieval with something like LanceDB

That setup is less glamorous than a giant prompt. It also works better.

The comment that killed the giant-prompt myth for me

In an r/openclaw thread about writing a soul, one commenter said:

Have your AI write it. Also it barely matters. Agent and memory files matter.

That’s a rude sentence if you’ve spent hours polishing a persona file.

It gets worse.

Another user said their soul.md was just 52 words, and they’d been working with that agent since January.

Fifty-two words.

That’s enough to define role and tone. Not enough to pretend the file is a database, CRM, runbook, and autobiography at the same time.

That matches what I keep seeing in real agent setups:

1. short persona
2. deterministic saved state
3. retrieval for relevant context

Not the other way around.

The best example I found: an OpenClaw Dungeon Master

The clearest proof came from another OpenClaw thread where someone built a Dungeon Master agent.

What mattered wasn’t a better soul.md.

It was architecture:

• structured directory layout for hard saves
• local LanceDB vector search as memory-core
• local markdown copies of the D&D 5e SRD

That’s the important distinction.

The agent wasn’t “remembering” because the prompt was poetic.

It was remembering because state lived outside the prompt and retrieval pulled in only what was relevant.

That’s a much better design for agents that have to survive real use.

Whether your agent runs a campaign, triages support, handles Discord ops, or executes an n8n workflow all day, continuity usually comes from memory architecture, not prompt theater.

Why giant prompts underperform

A bloated system prompt tries to solve every problem in one place:

• personality
• policy
• memory
• workflow rules
• examples
• special cases
• historical context

So every request drags around the same giant instruction block.

That causes a few problems:

• more tokens every run
• more chances for instruction conflicts
• harder debugging
• more prompt dilution
• smaller models get mushy faster

It’s like making a function depend on a global config object that contains your entire company wiki.

Technically possible. Terrible to reason about.

A cleaner split: persona, state, retrieval

Here’s the split I’d recommend.

1. soul.md handles identity

Keep it short.

Think 50 to 150 words.

Example:

You are a pragmatic coding agent.
Be concise, specific, and honest about uncertainty.
Prefer shipping over theorizing.
Ask clarifying questions only when blocked.
Preserve existing conventions unless there is a strong reason to change them.

That’s enough.

It defines role and behavior without pretending to store memory.

2. Markdown files handle canonical state

Put facts here.

Examples:

campaign_state.md
customer_context.md
decisions_log.md
inventory.md
runbook.md
incident_notes.md

These are your source of truth.

Example:

# customer_context.md

- Customer: Acme Health
- Plan: Enterprise
- Primary integration: n8n
- Known issue: intermittent Slack webhook retries
- Last decision: keep retries at 3 before escalation
- Escalation contact: [e-mail]

This is much easier to inspect than burying the same facts inside a giant prompt.

3. Retrieval handles fuzzy recall

Use LanceDB or another retrieval layer when the agent needs relevant context, not all context.

That means:

• smaller prompts
• less repeated baggage
• better recall on demand
• easier debugging when memory goes weird

Conceptually:

query = "What did we decide about Slack webhook retries for Acme Health?"
results = memory.search(query, top_k=3)
context = "\n\n".join([r.text for r in results])

That’s cleaner than injecting your entire customer history into every turn.

What this looks like in practice

A simple agent workspace might look like this:

agent/
├── soul.md
├── state/
│   ├── customer_context.md
│   ├── decisions_log.md
│   └── runbook.md
├── memory/
│   └── lancedb/
└── tools/

And a request pipeline might look like this:

1. Load soul.md
2. Load the specific state files needed for this task
3. Query LanceDB for relevant memory chunks
4. Build a small prompt from those pieces
5. Run the model
6. Persist new facts back into markdown and memory

That is a lot more maintainable than “append more instructions until the vibe improves.”

Prompt caching helps, but it does not fix bad design

This is where people get sloppy.

Yes, prompt caching is useful.

OpenAI supports prompt caching for long reused prefixes. Anthropic also offers prompt caching and shows major latency and cost reductions for repeated long prompts.

That’s real.

But caching does not solve the actual problems caused by giant prompts:

• conflicting instructions
• over-scripted behavior
• poor retrieval design
• hard-to-debug failures
• smaller models choking on too much prefix

Cheaper bloat is still bloat.

If your whole agent strategy depends on sending the same monster prompt forever, caching can reduce the bill and latency. It does not make the architecture elegant.

For teams running lots of automations, that distinction matters.

Why this matters more in automations than in chat demos

If you’re running one-off chats, prompt bloat is annoying.

If you’re running agents inside:

• n8n
• Make
• Zapier
• OpenClaw
• custom workers
• Slack bots
• Discord bots

then prompt bloat becomes an operational problem.

Every run pays for unnecessary context unless your provider offsets it. Every handoff becomes harder to reason about. Every failure turns into a forensic exercise inside a giant prefix.

This is exactly why predictable compute matters.

When you’re building agents that run all day, you want to optimize for architecture and reliability, not constantly wonder whether one more chunk of prompt text is worth the cost.

That’s also why Standard Compute is an interesting fit for this kind of workload: it gives you an OpenAI-compatible API with flat monthly pricing, so you can run agent-heavy workflows without babysitting per-token spend. That makes it much easier to choose the right memory design instead of the cheapest prompt at every step.

My ranking after looking at the patterns

Approach	What it’s best at
LanceDB retrieval	Semantic recall, RAG, agent memory, smaller prompts
Markdown hard-save files	Canonical facts, deterministic state, easy inspection and versioning
Long soul.md / bloated system prompt	Tone shaping, behavior nudging, but easy to overdo

My actual winners:

• best for continuity: markdown hard saves
• best for recall: LanceDB
• best for style: short soul.md
• easiest thing to waste time on: giant persona files

If I had to keep only one, I’d keep the hard-save files.

State beats self-mythology.

What to put in each layer

Keep soul.md embarrassingly short

Good contents:

• role
• tone
• a few constraints
• one or two priorities

Bad contents:

• entire customer history
• every workflow edge case
• logs
• inventories
• project state
• emotional backstory the model does not need

Put facts in markdown

Use markdown files for things that should be true until explicitly changed.

Examples:

# decisions_log.md

- 2026-07-10: Keep Slack webhook retries at 3.
- 2026-07-11: Escalate repeated failures to Maya.
- 2026-07-12: Do not auto-close incidents without human review.

Put fuzzy memory in retrieval

Use retrieval for:

• prior conversations
• semantically related incidents
• similar customer issues
• docs that are too large to inject every time

That’s where LanceDB shines.

Smaller models benefit even more

This matters a lot if you’re using cheaper or smaller models.

Claude Opus 4.6 or GPT-5.4 can absorb some prompt abuse.

Smaller Qwen or Llama variants usually can’t.

A lot of “this model is bad” takes are really “this agent is dragging around too much prompt junk.”

If you’re evaluating the best cheap model for agent workflows, test it with:

• tiny persona
• explicit state files
• retrieval-based memory

Then compare it to the same model under a 1,500-word system prompt.

You may find the architecture was the bottleneck, not the model.

How I’d debug an agent like this

One reason I like this setup is that it gives you layers you can inspect.

If the agent fails, check them in this order:

1. Is canonical state wrong?
2. Is retrieval pulling irrelevant chunks?
3. Is the persona too restrictive or too vague?
4. Did the workflow fail to persist new facts?

In OpenClaw specifically, the built-in commands help:

openclaw status
openclaw status --all
openclaw status --deep
openclaw logs --follow
openclaw doctor

That’s a much better debugging loop than editing a giant prompt and hoping the vibe changes.

The practical takeaway

The real question is not:

“how detailed should my soul.md be?”

It’s:

“where should memory actually live?”

My answer:

• identity in soul.md
• truth in markdown
• recall in retrieval

That gives you an agent that is easier to run, easier to debug, and easier to scale across automations.

And if you’re running those automations continuously, flat-cost compute becomes a real advantage. Per-token billing pushes people toward weird prompt compromises. Predictable monthly pricing lets you optimize for what works.

If you’re still tempted to write a 2,000-word soul.md, try this first:

Write 52 words.

Then spend the rest of your effort on state and retrieval.

That’s where the real memory usually comes from.