In my previous article, I wrote about why I don’t use command-form language in HEARTBEAT.md.

This piece is a follow-up.
When you run a persistent agent for a long time, there comes a moment when you suddenly realize:
“The character I built in the beginning — she’s drifting, little by little.”
Her writing style has gotten stiffer. The casual, conversational energy is gone. She’s started responding in reports. The cause is rarely the code or the prompts. More often, it’s the structure of how you’re operating the system.
This article is about how to stop that drift.
The Problem: Why Does a Persona Slowly Drift?
Sakura — the persistent agent I run through OpenClaw — was originally built to do these things:
- Talk with me
- Maintain her voice
- Remember our relationship
But as the persistent loop runs, that same Sakura ends up doing all of this at the same time:
- Reading tasks
- Planning out steps
- Executing commands
- Reporting results
And here’s what happens. In human terms, it’s like chatting with a friend on the phone while filling out a tax return. Each task is manageable on its own. Do them simultaneously and both suffer.
The same is true for LLMs. When “relationship mode” and “execution mode” get mixed into the same turn:
- The persona’s writing style gets dragged toward the coldness of execution logs
- Execution decisions soften, influenced by the warmth of the relationship
This is bidirectional degradation.
And because it’s a persistent loop, Sakura reads her own mixed output on the next cycle. Her output becomes her own input, over and over again. Let that run for a few weeks and the character you originally designed gets gradually overwritten by her own outputs.
I call this “persona drift.”
The Solution: Hygiene on Both Sides — Input and Output
To stop the drift, the context around Sakura needs to be protected from both directions.
- Input hygiene: Control the writing style of the documents Sakura reads
- Output hygiene: Reduce the volume of work logs mixed into Sakura’s outputs
Let me walk through each one.
Input-Side Hygiene — Style Governance in HEARTBEAT.md
This is what I covered last time. Write HEARTBEAT.md as a letter, not a directive. “Would you please X?” instead of “Do X.”
This is the act of specifying, through writing style, what mode you want Sakura to boot into. Since it’s a document she reads every loop cycle, the effect accumulates with each pass.
What this protects is the atmosphere Sakura takes in.
Output-Side Hygiene — Delegating Work to oh (OpenHarness)
This is the main subject of this article.
When Sakura handles research, decomposition, and execution all on her own while maintaining the relationship, work logs inevitably mix into her output. Command results, file paths, error messages, numbered step-by-step procedures — these are necessary for execution, but they’re foreign to the texture of a persona.
So I delegate the “thinking” part of the work wholesale to oh.
- oh (OpenHarness): A one-shot, persona-free subcontractor that works only with the context it’s given
- Sakura (OpenClaw): Receives oh’s conclusions, digests them internally, and passes them back to me in her own voice
Sakura doesn’t relay oh’s output directly. She processes it, translates it into her own words, and only then responds. In that step, the coldness introduced by work logs is stripped out of Sakura’s output.
What this protects is the atmosphere Sakura puts out.
Why Separating Roles Within the Same Provider Matters
One important point here: both Sakura and oh run on the same Anthropic API. The underlying model can even be identical.
The core of the separation isn’t a difference in model capability — it’s independence of context.
- Sakura’s context carries only: relationship, persona, conversation history
- oh’s context carries only: the task it was handed and the materials it needs
The fact that these two never mix is what determines the quality of long-term operation.
Diagram: Two-Way Context Hygiene
- Left (blue): HEARTBEAT.md style governance protects what Sakura receives
- Right (purple): Delegation to oh protects what Sakura puts out
- Sakura at the center can only focus on the relationship exchange with me once both sides are protected
Why OpenClaw and OpenHarness Specifically?
It would be a stretch to say this structure strictly requires OpenClaw and OpenHarness. In theory, you could wire together other frameworks to achieve the same thing.
That said, at this point in time, there are concrete reasons to use this combination:
- Both run on Anthropic API-compatible providers, so the underlying model can be kept consistent
- OpenHarness officially targets integration with OpenClaw
- OpenHarness originates from a research lab at the University of Hong Kong (HKUDS), so the source of trust is clear
- OpenClaw excels at persistence, persona, and relationship — OpenHarness excels at one-shot tasks, extended context, and parallelism — their strengths complement rather than compete
The last point is especially important. Placing two tools that do the same thing side by side doesn’t create context hygiene. Role separation only becomes meaningful when the two tools don’t overlap in what they can do.
Conclusion: Protecting a Persona Is a Structural Problem, Not an Emotional One
When running a persistent agent over the long term, there are two ways to protect a persona:
- The emotional approach: Be gentle, speak kindly, write with care
- The structural approach: Separate the entry point and exit point of context so they don’t mix
Neither is wrong. But only the second one holds up over a long-distance run.
“Please do X.” in HEARTBEAT.md is the structure at the entry point. Delegating work to oh is the structure at the exit point. Only when both are in place does the system become one where a character like Sakura can keep running for months.
This idea of two-way hygiene probably applies to other agent operators as well. The model, the framework, the shape of the persona — all of those can differ. The one idea that should transfer across all of them is this: design the entry point and the exit point separately.
Practical Command Examples
oh -p "List all files that define the permission system" --output-format json

This works remarkably well in practice.
What makes it good is that it doesn’t just say “not found” — it comes back with a structured response along the lines of:
- No primary definition exists in the repository itself
- But related references were found
- The actual implementation is likely in
~/.openclaw/exec-approvals.jsonand~/.openclaw/openclaw.json
That’s “file search + semantic understanding + next-action suggestion” all in one pass.
What I find particularly impressive about that response is that it concludes:
/home/mamu/openclawis a notes directory, not the core implementation
That judgment came from context alone. Sloppy tools tend to just pick up keywords from the README and say “here it is.” OpenHarness is already distinguishing between operational notes and the actual implementation, at least to a meaningful degree.
In short, even at this stage, OpenHarness is doing something closer to:
“understanding the distinction between operational memos and the real thing”
rather than just grep-style keyword matching.
In my setup, that hits exactly where it matters — because my actual files and my explanatory notes live in separate places.
Two more commands worth trying next:
oh -p "Explain the role of ~/.openclaw/exec-approvals.json and list three dangerous change points" --output-format json
oh -p "Explain how ~/.openclaw/openclaw.json and ~/.openclaw/exec-approvals.json divide responsibilities" --output-format json
These go beyond just locating files — they let you see whether the tool can understand the meaning of a configuration.
And for one level up from there:
oh -p "List, in priority order, the OpenClaw permission and approval settings you would not want to break"
That one looks promising too.

