Aaron Williams ยท Merkle & Bloom / Barnabas Coaching

Celebrating 200 days with my Chief of Staff OpenClaw Agent: Dru

What actually made it work, what took months to figure out, and the parts that still don't.

Dru has been running for 200 days, and I want to be precise about what that means, because the precision is the most useful thing in this post.

Those 200 days belong to the agent, not to the session, which I reset constantly. Everything that survives a reset survives because it lives in a file on disk, and that distinction is the whole difference between an assistant you re-explain yourself to every morning and one that already knows.

Most people who tell me their AI forgets everything are describing a conversation, not an agent. It's a fair description of what they've got.

What it actually does

Dru is a Chief of Staff. I talk to one agent; it holds the context and routes work to whichever domain owner it belongs to. Some jobs it delegates, some it hands to a subagent running a local model on my own hardware, and the ones that need real reasoning go out to a frontier model.

The routing is worth explaining because it's where most of the cost savings live. GLM 5.3 Flash answers by default because it's fast and it costs almost nothing. Anything Dru has to run itself goes to a local Q8 model on the M5 Max, which I benchmarked at 90.4 tokens a second; for comparison, cloud-hosted Sonnet 5 and GLM Flash both land around 62 to 63 on published benchmarks. Local isn't the slow option any more, and most tasks need far less context than people assume.

That mix means the expensive models only get pointed at expensive problems, which is the whole trick to running this without a surprise invoice.

What I got wrong at the start

I assumed the model was the important part. It isn't, and I'd guess that's the single most common mistake anyone makes here.

Swap the model and you get a slightly better or slightly worse writer. Change what surrounds it (the memory, the rules it can't argue with, what it's allowed to touch) and you change what it's capable of doing at all. The industry spent two years talking about models getting smarter. Almost everything that changed what's possible in a business happened one layer up.

I also assumed good instructions would be enough. They're advisory. The model weighs them against everything else competing for its attention, and as a session fills up, whatever you buried in paragraph nine quietly stops mattering.

Three things that made the difference

Memory built as tiers, not as a pile

The always-loaded layer stays tiny: an index of about twenty lines, one per topic, with a "Right now" header of a few lines covering active projects and pending decisions. Detail lives in topic files that only load when the index says they're relevant.

Underneath that sit the files that actually make it improve. DECISIONS.md records alternatives considered and trade-offs accepted, so settled questions don't get relitigated. ERRORS.md carries a root cause and a prevention rule for every mistake. instincts.md holds behavioural patterns with a confidence score, and promotion is gated: a pattern needs to show up in two separate sessions with citable evidence before it becomes a rule, and never on the night it's first seen.

Search runs on a small embedding model on my own machine, indexing roughly 120 files. Nothing leaves the building for Dru to remember something about me.

The addition I'd recommend to anyone

When something replaces an existing memory, the old entry gets edited rather than deleted. A line goes on top of it: > superseded 2026-09-08 by: <new fact>

The old fact stays visible with its replacement named. Stale and current never sit side by side looking equally true, which closes the classic failure where an agent recalls something outdated with total confidence and no flag.

Rules the agent can't reason its way around

There's no rules file that works. People go looking for one. Hard constraints don't live in markdown, and understanding why is the difference between an agent you trust and one you hope will behave.

Instruction files set preferences. The harness enforces limits. A gate is a small piece of code that runs before an action does, sees what the agent is about to do, and can cancel it; the model never gets the chance to talk itself into anything. In one published test, the same agent given the same three rules broke two of them when the rules lived in the instruction file, and none when the identical rules ran as gates.

One front door instead of ten agents

Standing domain owners beat helpers conjured on demand, for reasons that took me a while to appreciate. A spawned helper does the job and evaporates, taking everything it worked out with it. A standing agent gets better at its area every week, keeps its own credentials scoped to that area, and lets you debug it by opening its history and reading what it did.

Delegation still earns its place; it just needs a ceiling. Two or three helpers at a time, one level deep, and helpers can't create helpers.

Fern

This isn't a one-household experiment any more. My partner runs her own agent, Fern, on a fully local Qwen model (ollama/quinn-q8:ctx128k), reachable through iMessage and the web UI. Fern is wired into Notion and handles trip planning, interior design and fashion calls, research, financial planning, and budget tracking. Her workspace is hers; she has never seen a line of my context and never will. Same architecture, smaller perimeter, and it took about an afternoon to set up.

The failures are more interesting than the wins

Two of these still aren't solved, and I'd rather say so than pretend otherwise.

Checking memory is a habit rather than a mechanism. There's a written rule saying Dru must search before answering questions about past work, and that rule is enforced by the same agent that might skip it. In one incident it searched, the right answer appeared in the results, and it asked me the question anyway. When the discipline slips it feels exactly like forgetting, because to me it is.

The architectural fix is the one that works: anything living in always-loaded context can't be forgotten, so the answer to a recurring miss is to move that fact up a tier instead of asking the agent to try harder.

The other open problem is conflict. Once you have more than one place an answer could come from, two of them can disagree, and out of the box whichever one the search ranks highest wins. Ranking is about phrasing, so the stalest thing in the pile can win by using your exact words. Scoring sources by trust helps and doesn't settle it.

My favourite design decision came out of a security choice and turned into something better. My main session runs elevated in the web interface; iMessage is a separate channel with reduced permissions, so nobody holding my phone can do damage. The two share nothing except what got written to disk. If I tell Main something and iMessage hasn't heard about it, my memory system has failed in front of me, in a reply that's missing something it should have known. I hit those failures early, often, and loudly, which beats discovering them in three months when a decision has quietly gone missing.

If you're thinking about it

Start with one agent, one channel, and one job you can check on in a week. Something low stakes, and something you'd notice if it went wrong.

The trap at this stage is designing a nine-agent system before running one. Run one badly first; you'll learn more in a week of that than from any amount of reading, including this.

And if you take one thing from 200 days of doing this: the agent isn't the thing you fix. The rules are.