Your agent gets something wrong. The user corrects it. Next session, the agent makes the same mistake. Sound familiar?

I spent weeks watching my OpenClaw agent forget that I prefer TypeScript over Python, that my deploy target is Railway (not Vercel), and that I hate when it adds semicolons to my code. Every single session, we’d have the same conversation. I’d correct it, it’d apologize, and then twelve hours later we’d be back to square one.

The problem is obvious once you see it: corrections live in chat history, and chat history gets truncated. Your agent’s MEMORY.md file might capture some of this, but grep doesn’t understand intent. When your agent searches for “deploy” it won’t find the memory where you said “stop suggesting Vercel.”

So I built a correction loop using MemoClaw. Here’s how it works.

The pattern

When a user corrects your agent, three things need to happen:

1. Store the correction as a high-importance memory
2. Tag it so it’s findable by context
3. Recall relevant corrections before generating responses

That’s it. No fancy architecture, just store and recall at the right moments.

Storing corrections

In your agent’s SOUL.md or behavior instructions, add something like this:

When the user corrects you, store the correction using memoclaw:

memoclaw store --text "User prefers Railway for deployments, not Vercel. Corrected on 2026-02-15." --importance 0.9 --tags correction,deploy,preferences

The importance score matters. I use 0.9 for direct corrections and 1.0 for corrections the user seemed frustrated about. Default memories sit at 0.5, so corrections naturally float to the top of recall results.

The tags are how you’ll filter later. I settled on always including correction plus one or two topic tags. Keep it simple.

From the CLI, a store looks like this:

memoclaw store \
  --text "User wants TypeScript examples, never Python. Got annoyed when I showed Python snippets for the third time." \
  --importance 0.9 \
  --tags correction,language,preferences \
  --namespace my-agent

The namespace isolates these memories per project. If you’re building agents for multiple users or contexts, namespaces keep things clean.

Recalling before you respond

Here’s the part most people skip. Storing corrections is pointless if you don’t recall them at the right time.

Before your agent drafts a response about a topic, it should pull relevant corrections:

memoclaw recall \
  --query "user preferences about deployment" \
  --tags correction \
  --namespace my-agent

The semantic search is doing the heavy lifting here. You don’t need to guess the exact words. Searching “deployment preferences” will surface the memory about Railway vs. Vercel even though neither word appears in the query. That’s the whole point of moving beyond grep.

In practice, I added a line to my agent’s instructions:

Before answering questions about user preferences, code style, or tool choices,
recall memories tagged "correction" related to the topic. Incorporate these
into your response without mentioning that you're checking memory.

The “without mentioning” part matters. Nobody wants their agent to say “According to my records, you previously indicated a preference for…” Just use the information naturally.

What a correction loop looks like in practice

Here’s a real session flow:

Session 1:

• Agent suggests a Python script
• User: “I’ve told you before, use TypeScript”
• Agent stores: importance 0.9, tags: correction, language

Session 2:

• User asks for a script
• Agent recalls corrections tagged “language”
• Gets back: “User wants TypeScript examples, never Python”
• Agent writes TypeScript without being asked

No fanfare. No “I remembered!” moment. It just works the way you’d expect a person to work after being corrected.

Handling conflicting corrections

People change their minds. Last month I wanted all my configs in YAML. This month I’m back to TOML. Your agent needs to handle this without treating old corrections as gospel.

Two approaches that work:

Overwrite with update. When a new correction contradicts an old one, find the old memory and update it:

# Find the old correction
memoclaw recall --query "config file format preference" --tags correction

# Update it (using the memory ID from the recall)
memoclaw update --id <memory-id> \
  --text "User switched back to TOML for config files (was YAML, changed Feb 2026)" \
  --importance 0.9

Let recency win. Store the new correction separately. When you recall, the most recent and highest-importance memory comes first. Your agent instructions should say “if corrections conflict, follow the most recent one.”

I use the second approach because it’s simpler and keeps a history. Sometimes I want my agent to know I flip-flopped, not just what the current preference is.

Making corrections stick with importance scores

Not all corrections are equal. “I prefer tabs over spaces” is a 0.7. “Never push directly to main, always use a PR” is a 1.0. Here’s the rough scale I landed on:

• 1.0 — Safety or workflow rules. Things that would cause real problems if ignored.
• 0.9 — Strong preferences the user has corrected you about before.
• 0.8 — First-time corrections about preferences.
• 0.7 — Minor style preferences.

Higher importance means the memory surfaces more readily in recall. A 1.0 correction about never pushing to main will appear even when the query is loosely related to git workflows.

The MEMORY.md problem

If you’re still using MEMORY.md, you probably have a section that looks like this:

## User preferences
- Prefers TypeScript
- Uses Railway for deploys
- Likes tabs not spaces
- Hates verbose logging

This works until it doesn’t. The file grows. Your agent’s context window fills up with preferences that aren’t relevant to the current conversation. And there’s no way to search by relevance; it’s all or nothing.

With MemoClaw, your agent only pulls what’s relevant. Talking about deployment? It gets the Railway preference. Writing code? It gets the TypeScript and tabs preferences. Discussing logging? Just that one memory surfaces. The context stays lean.

You can migrate your existing corrections in one shot:

memoclaw migrate --file MEMORY.md --namespace my-agent

This parses the markdown and stores each section as a separate memory. You’ll want to go back and tag the important ones as corrections, but it’s a start.

What I got wrong at first

I initially stored corrections with too much context. Memories like “During our conversation about the React project on Tuesday, the user mentioned they don’t like when I use console.log for debugging and would prefer proper error handling with try-catch blocks and meaningful error messages.” That’s 40 words when “User prefers try-catch over console.log for error handling” says the same thing.

Short, specific memories recall better. The embedding model gets a cleaner signal, and you waste less of your recall budget on filler.

I also over-tagged at first. Ten tags per memory meant nothing was specific. Two or three tags per correction is the sweet spot.

Try it

If your agent keeps forgetting what you’ve told it, this takes maybe 20 minutes to set up. Install the CLI, add the store/recall pattern to your agent instructions, and start with your five most-repeated corrections.

npm install -g memoclaw

The free tier gives you 100 API calls, which is enough to test whether this actually helps before you spend anything. For most agents, a dozen stored corrections cover 80% of the repeated mistakes.

The goal isn’t a perfect memory system. It’s an agent that stops making you repeat yourself.