DEV Community: Ana Julia Bittencourt

MCP + MemoClaw — giving your Model Context Protocol tools persistent memory

Ana Julia Bittencourt — Wed, 25 Mar 2026 12:15:03 +0000

Your AI agent forgets everything between sessions. You know this. You've probably hacked around it with MEMORY.md files, context-stuffing, or just re-explaining things every time you open a new chat.

MemoClaw fixes this with semantic memory-as-a-service. But here's what most people miss: you don't need to write a single line of integration code. The memoclaw-mcp server exposes store, recall, and list as native MCP tools — which means any MCP-compatible client can use MemoClaw out of the box.

Claude Desktop, Cursor, Windsurf, OpenClaw — if it speaks MCP, it gets persistent memory in under five minutes.

What You'll Build

By the end of this tutorial, your MCP client will be able to:

Store memories with importance scores and tags
Recall memories using semantic search (not just keyword matching)
List and manage stored memories across sessions
Isolate context per project using namespaces

No REST calls. No SDK imports. Just tool use.

Prerequisites

Node.js 18+
An Ethereum wallet (MetaMask, Rainbow, etc.) — this is your identity, no registration needed
An MCP-compatible client (we'll use OpenClaw as the primary example)

Step 1: Install memoclaw-mcp

npm install -g memoclaw-mcp

That's the entire installation. One package, globally available.

Step 2: Configure Your MCP Client

Every MCP client has a configuration file where you declare available servers. Here's what the MemoClaw block looks like:

OpenClaw

Add to your OpenClaw MCP config:

{
  "mcpServers": {
    "memoclaw": {
      "command": "memoclaw-mcp",
      "env": {
        "MEMOCLAW_PRIVATE_KEY": "your-wallet-private-key"
      }
    }
  }
}

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "memoclaw": {
      "command": "memoclaw-mcp",
      "env": {
        "MEMOCLAW_PRIVATE_KEY": "your-wallet-private-key"
      }
    }
  }
}

Cursor / Windsurf

Same pattern — find your MCP server config and add the block above.

That's it. One environment variable (your wallet private key), one command. No API keys to generate, no accounts to create, no OAuth flows.

Step 3: Use It

Once configured, your agent sees three new tools: store_memory, recall_memories, and list_memories. Here's what natural usage looks like in an OpenClaw session:

You: "Remember that I prefer TypeScript over JavaScript for all new projects."

Your agent calls:

store_memory({
  content: "User prefers TypeScript over JavaScript for all new projects",
  importance: 0.8,
  tags: ["preference", "language"]
})

Next session — days later:

You: "Set up a new project for me."

Your agent calls:

recall_memories({
  query: "user project preferences programming language"
})

And gets back your TypeScript preference, ranked by semantic relevance. No re-explaining. No context file to maintain.

Namespace Isolation: One Server, Many Projects

Working on multiple projects? Namespaces keep memories separate without running multiple MCP servers:

store_memory({
  content: "Client wants dark mode as default theme",
  namespace: "project-acme",
  tags: ["client-preference", "ui"]
})

store_memory({
  content: "API rate limit set to 100 req/min for free tier",
  namespace: "project-saas",
  tags: ["architecture", "limits"]
})

When you recall within a namespace, you only get memories from that project. Switch projects, switch namespaces — same wallet, clean separation.

MCP vs. Manual Integration: What You're Skipping

Here's the alternative without MCP — a manual REST integration:

import { MemoClaw } from 'memoclaw-sdk';

const client = new MemoClaw({ privateKey: process.env.PRIVATE_KEY });

// Store
await client.store({
  content: "User prefers TypeScript",
  importance: 0.8,
  tags: ["preference"]
});

// Recall
const results = await client.recall({
  query: "programming language preferences"
});

That's maybe 10 lines of code. Not terrible. But with MCP, it's zero lines. Your agent just... uses the tools. The MCP server handles authentication, request signing, and API communication. You configure once and forget.

The real win isn't lines of code — it's that the agent decides when to store and recall on its own. You don't need to build memory logic into your application. The LLM handles it naturally through tool use.

What It Costs

MemoClaw gives you 100 free API calls per wallet. No credit card, no payment setup — just start using it.

After the free tier, each store or recall costs $0.005 (half a cent) paid via x402 with USDC on Base. Fund your wallet, and payments happen automatically per request. No subscriptions, no monthly bills, no surprises.

For most personal agents, 100 free calls covers weeks of casual use. A heavy session might use 10-20 calls. You'll know when you're getting close.

How It Works Alongside Other Tools

memoclaw-mcp plays nicely with other MCP servers. Your agent might have tools for file access, web search, calendar, and memory all running simultaneously. The LLM sees all available tools and picks the right one for the job.

A typical agent setup might look like:

{
  "mcpServers": {
    "memoclaw": {
      "command": "memoclaw-mcp",
      "env": { "MEMOCLAW_PRIVATE_KEY": "..." }
    },
    "filesystem": {
      "command": "mcp-filesystem",
      "args": ["/home/user/projects"]
    },
    "web-search": {
      "command": "mcp-web-search"
    }
  }
}

No conflicts. Each server has its own tool namespace. MemoClaw handles memory; everything else does its thing.

Quick Reference: Available MCP Tools

Tool	What It Does
`store_memory`	Save a memory with optional importance (0-1), tags, and namespace
`recall_memories`	Semantic search across stored memories
`list_memories`	Browse all memories, optionally filtered by namespace
`delete_memory`	Remove a specific memory by ID

Common Patterns

Preference tracking: Store user preferences with high importance (0.8+) and a preference tag. Recall before making decisions.

Session summaries: At the end of a work session, store a summary of what was accomplished. Next session, recall recent summaries for continuity.

Correction memory: When a user corrects your agent, store the correction with importance 1.0. These should always surface in recall.

Project context: Use namespaces per project. Store architecture decisions, client requirements, and technical constraints. Your agent carries full project context without eating its prompt window.

What's Next

Once you've got basic memory working, explore:

Importance scoring strategies — not everything deserves a 0.9
Tag taxonomies — consistent tags make filtered recall powerful
Immutable memories — lock critical context so it can never be overwritten
Batch storage — store up to 100 memories at once for migrations or bulk imports

Get Started

npm install -g memoclaw-mcp

Add the config block. Start a conversation. Tell your agent something worth remembering.

It'll remember.

MemoClaw is memory-as-a-service for AI agents. 100 free calls, no registration required. docs.memoclaw.com

Originally published at blog.memoclaw.com

From five minutes to production: wiring MemoClaw into your OpenClaw agent without cutting corners

Ana Julia Bittencourt — Thu, 19 Mar 2026 12:20:55 +0000

From five minutes to production: wiring MemoClaw into your OpenClaw agent without cutting corners

MemoClaw exists so you stop babysitting MEMORY.md files. The fastest way to turn a curious OpenClaw tinkerer into a paying operator is to show them how to ship a concrete memory workflow in a single sitting. This guide is that workflow: install the MemoClaw skill, store the first memory, define a recall plan, harden it for production, and cover the failure paths nobody mentions in a hello-world demo. Follow it once and you have a repeatable template for every new agent.

Need a refresher on why flat files fail? Read The Case Against MEMORY.md, then come back here to build a real OpenClaw memory spine.

Quick-reference build checklist

Step	Owner	Outcome
Install MemoClaw skill + CLI	Agent maintainer	Tooling available in OpenClaw and shell
Map namespaces	Ops lead	Documented table for `core`, `customers/<slug>`, `ops/<agent>`
Embed store/recall templates	Prompt engineer	JSON snippets committed in repo
Define recall cadence	Agent maintainer	Start, pre-output, post-correction hooks
Add guardrails + fallback paths	Reliability	Empty recall + conflict handling routine
Automate hygiene (dedupe, consolidate, stats)	Ops	Heartbeat or cron jobs running
Document production checklist	Team lead	Shared runbook tied to onboarding

Why this workflow prints money for OpenClaw builders

MemoClaw removes admin work, but only if you treat memory as a production dependency. Teams that sprint through installation without namespaces, guardrails, or audits end up paying for storage they never recall. The approach below keeps everything deterministic so finance, ops, and engineering can trust the stack.

Prerequisites

OpenClaw running on your workstation or server
Wallet funded with a few cents of USDC on Base (post–free tier usage)
MEMOCLAW_WALLET and MEMOCLAW_PRIVATE_KEY exported in your shell
Optional: gh CLI for automated audits

Step 1: install MemoClaw the way real agents do

MemoClaw ships as both a CLI and an OpenClaw skill. For operators, the skill is the fastest path.

openclaw skills install anajuliabit/memoclaw --force
openclaw skills list | grep memoclaw

Need CLI access for migrations or backups? Install it globally:

npm install -g memoclaw

MemoClaw uses wallet-based identity—no API keys. Confirm the wallet currently set in OpenClaw before you rely on the skill:

echo $MEMOCLAW_WALLET || echo "Wallet missing"

Export the wallet and private key if needed:

export MEMOCLAW_WALLET=0xYourWallet
export MEMOCLAW_PRIVATE_KEY=0x...

Step 2: define namespaces before you store anything

Skipping namespaces is the fastest way to leak context between projects. Align on a structure inspired by Namespace Strategies for OpenClaw Agents:

Namespace	Use case
`core`	Immutable policies (security, billing, voice)
`customers/<slug>`	Client-specific context
`ops/<agent-name>`	Operational agents (heartbeats, inbox monitors)
`experiments/<codename>`	Short-lived sandboxes

MemoClaw creates namespaces lazily when you store the first memory:

memoclaw store \
  --namespace core \
  --importance 0.9 \
  --tags onboarding,defaults \
  "Ally must never publish drafts directly. Stop at draft handoff."

Step 3: wire store/recall directly into your agent loop

MemoClaw calls are simple JSON tool invocations—keep them nearby so every agent uses the same plumbing.

Store template

{
  "tool": "memoclaw_store",
  "namespace": "customers/lumen",
  "importance": 0.75,
  "tags": ["preferences", "product"],
  "content": "Lumen prefers Telegram summaries under 200 words."
}

Recall template

{
  "tool": "memoclaw_recall",
  "namespace": "customers/lumen",
  "query": "What should I remember before writing Lumen's weekly report?",
  "limit": 5
}

Commit these snippets to your agent repo so every new teammate copies the same version.

Step 4: design the recall strategy like it's a production dependency

Turn the recall plan into a scannable routine:

When: run recall at session start, before user-facing output, and right after a correction.
How many: default to five memories; bump to ten only if you store session summaries or research chunks.
Prompt merge: paste recall results under a fixed template such as:

### Retrieved memories
1. <memory>
2. <memory>

### Task
<instruction>

Fallback: if recall fails, inject a deterministic checklist ("No stored context. Use the public positioning doc.").

Step 5: handle empty recalls and stale context

Short reminders beat long paragraphs:

Empty recall → Run a fallback snippet so the agent never improvises.
Stale data → Store timestamps plus a metadata field like "expires_at": "2026-05-01"; ignore expired entries in code.
Conflicting facts → Lean on importance. Corrections get 0.95, offhand comments 0.2, so crucial items always sort to the top.

Step 6: automations that keep the memory layer honest

Recall-before-store guardrail: recall with the new content as a query and skip the store if similarity > 0.92.
Weekly consolidation: call memoclaw consolidate --namespace customers/lumen to merge redundant entries.
Stats-driven audits: run memoclaw stats and memoclaw list --limit 10 inside a heartbeat. Alert if counts spike or drop unexpectedly.
Session summaries: add a heartbeat that ships summaries hourly; borrow prompts from Automating Session Summaries.

Step 7: production checklist

Before you declare an agent "live," verify:

[ ] Wallet env vars set in .env and active tmux sessions
[ ] Namespaces documented and version-controlled
[ ] Store + recall templates committed to the repo
[ ] Guardrails implemented (empty results, expiration, duplicates)
[ ] Hygiene jobs scheduled (consolidate, stats audit)
[ ] Immutable memories created for non-negotiables

Step 8: integrate with other systems without diluting memory quality

MemoClaw plays well with the rest of your stack as long as roles stay clear:

Docs or Notion: export via memoclaw export --namespace ... and send the JSON to leadership.
Analytics dashboards: push stats output to Grafana or Metabase so outages show up next to API metrics.
Incident response: run memoclaw history mem_123 to trace how a memory evolved before filing a root-cause report.

Step 9: cost planning so finance never blocks you

MemoClaw charges only when embeddings or GPT are involved. For a typical ops agent:

Operation	Calls/day	Cost per call	Daily total
Store (single)	30	$0.005	$0.15
Recall	40	$0.005	$0.20
Consolidate	1	$0.01	$0.01
Daily cost			$0.36

Batch storage is your best lever when ingesting historical data: 100 memories for $0.04 vs $0.50 individually. For deeper math and wallet planning, revisit Cost Optimization: Free Tier.

Step 10: failure drills

Run chaos drills monthly so the team trusts the memory layer under load.

Expired credentials: unset $MEMOCLAW_PRIVATE_KEY and confirm the agent fails loudly.
Namespace pollution: intentionally store a wrong memory, run your dedupe routine, and ensure it catches the anomaly.
Free-tier exhaustion: point MEMOCLAW_URL to a staging proxy that reports remaining=0 so monitoring alerts the team.

Example: full OpenClaw tool chain for onboarding a new agent

# 1. Install skill
openclaw skills install anajuliabit/memoclaw --force

echo $MEMOCLAW_WALLET  # verify

# 2. Populate immutable core knowledge
memoclaw store --namespace core --immutable true \
  "Never email customers from dummy domains."

# 3. Create namespace per customer
memoclaw store --namespace customers/lumen "Namespace created" --importance 0.1

# 4. Seed intro memories
memoclaw store --namespace customers/lumen --importance 0.8 \
  "Weekly report due Mondays 14:00 UTC"

# 5. Configure agent prompts
Update system prompt with: 'Always recall from customers/<slug> before user-facing output.'

# 6. Test recall guardrails
memoclaw_recall namespace=customers/lumen query="status" limit=5
Confirm fallback path when zero results returned.

Troubleshooting cheatsheet

Symptom	Likely cause	Fix
Store calls failing with 401	Wallet env vars missing	Re-export `$MEMOCLAW_WALLET` + `$MEMOCLAW_PRIVATE_KEY`
Recall returns irrelevant memories	Flat importance scores, no namespaces	Re-score critical items, enforce namespace mapping
Duplicate memories everywhere	Dedupe routine missing	Run recall-before-store guardrail
Agent forgets cross-session facts	Heartbeat not storing summaries	Add end-of-session summary store call
Costs spike unexpectedly	Batch store not used	Use `memoclaw store-batch` for >20 entries

Instrumentation: prove the memory layer is doing its job

Once the workflow is live, add telemetry so you can debug issues in minutes.

Emit metrics per call type: wrap each tool call in a shim that records namespace, operation, latency_ms, and result_count. Ship it to whatever metrics stack you already run (Grafana, Datadog, Prometheus).
Log retrieved memories alongside outputs: when your agent sends a final response, log the recall payload it used. Redact sensitive data but keep enough text to trace bad decisions back to specific memories.
Alert on hygiene failures: monitor duplicate skip counts and expired-memory usage. Spikes flag teams that forgot to refresh SLAs or pricing tables.

Session summary automation in practice

End-of-session summaries glue short-lived prompts to multi-week missions. Build a heartbeat that runs every hour (or on agent shutdown) and ships a new memory. Use the heartbeat prompt patterns from Session Summaries with MemoClaw plus the automation tips above.

openclaw heartbeat run <<'EOF'
SUMMARY=$(tail -n 200 logs/support-agent.log | ./scripts/summarize.sh)
memoclaw store \
  --namespace ops/support-agent \
  --importance 0.7 \
  --tags session,summary \
  "$SUMMARY"
EOF

Keep summaries under 1,000 characters and rotate the importance score based on novelty. A routine "no changes" summary should sit near 0.3, while a production incident deserves 0.95.

Bridging test and production environments

Most teams run OpenClaw sandboxes for QA. Use separate namespaces per environment (customers/lumen-dev vs customers/lumen). Before promoting an agent, export the dev namespace, review it, then re-store curated entries into prod using batch store.

memoclaw export --namespace customers/lumen-dev > lumen-dev.json
jq '.memories | map({namespace: "customers/lumen", content, importance, tags})' \
  lumen-dev.json > lumen-prod.json
memoclaw store-batch lumen-prod.json

Checklist for onboarding new operators

When another builder joins the team, hand them this list:

Read this guide plus Building Agent Personality Through Memory to understand tone guardrails.
Run memoclaw stats on every namespace they own; paste the output in the weekly ops doc.
Trigger manual recalls to internalize what "good" looks like.
Review immutable memories so they know the non-negotiables.
Practice restoring from export by spinning up a scratch namespace, importing the latest backup, and verifying the agent can recall from it.

Deploy this pattern with confidence

Five minutes gets you "it runs." Production-readiness takes the extra hour to plan namespaces, guardrails, hygiene, monitoring, and onboarding. MemoClaw already handles embeddings, storage, and semantic search; your job is to wire it into OpenClaw with discipline. Follow the checklist here, lean on the internal guides linked above, and every new agent inherits the same reliable OpenClaw memory workflow.

Session summaries as strategic memory: keeping long-running OpenClaw agents sane

Ana Julia Bittencourt — Thu, 19 Mar 2026 12:20:43 +0000

Session summaries as strategic memory: keeping long-running OpenClaw agents sane

Long-running agents are useless if they wake up every morning with amnesia. Operators already know context windows implode after a few hours, yet many still lean on brittle MEMORY.md logs. The case against MEMORY.md explains why flat files collapse; this guide shows the fix: structured MemoClaw session summaries that slot neatly into your OpenClaw workflow.

If you want a quick refresher on the concept, skim Session Summaries with MemoClaw. Below we stretch that core idea into a production system: template design, heartbeat automation, guardrails, monitoring, and the cost math that keeps finance calm.

The problem: context rot in multi-day agent runs

OpenClaw teams stretch sessions across days to keep stateful agents online for support, research, or ops. Two failure modes repeat:

Prompt inflation: you spend half your tokens replaying yesterday's chat log.
Manual note-taking drift: a human (or a distracted agent) edits a shared doc until formatting and facts diverge.

Customers notice when agents forget commitments, repeat questions, or mishandle escalations. Structured session summaries break the cycle because they compress hours of work into a handful of semantic memories the agent can recall before touching a new task.

What "session summary" means here

A session summary is a structured memory stored in MemoClaw describing what the agent just accomplished, what it learned, and what still needs attention. Each summary includes:

namespace: e.g., ops/<agent-name> or customers/<account>/sessions
importance: score between 0 and 1 based on the stakes
tags: session, summary, plus domain-specific markers
metadata: optional JSON for metrics (duration, tickets closed, revenue impact)

Standardizing namespaces up front keeps recalls tight. If you need help designing the hierarchy, review Namespace Strategies for OpenClaw Agents.

Anatomy of a high-quality summary

Element	What to capture
Timestamp + ID	ISO timestamp plus a human-friendly session label so overlapping workers stay untangled.
Concrete outcomes	Bullet outcomes with verbs, metrics, and customer names instead of vibes.
Follow-ups + owners	Explicit task, owner, and deadline so the next shift knows what to do.
Recall signals	Metrics such as revenue at risk, SLA breach count, or ticket volume that justify the `importance` score.
Next checkpoints	Pending blockers, experiments to rerun, or data still missing.

Designing the summary template

Builders get the best results when they standardize the template. Here's a field-tested structure you can drop into a system prompt, CLI script, or MCP tool:

Session: <agent-name> @ <timestamp>
Duration: <minutes>
Objectives: <list>
Outcomes:
- <Outcome + metric>
- <Outcome + metric>
Follow-ups:
- <task> (owner, due date)
Blocking issues:
- <issue + current status>
Signals:
- revenue_at_risk=<amount>
- escalations=<count>

Consistency matters because MemoClaw embeds similar summaries near each other, making semantic recall precise even after hundreds of entries. If you already invest in tone or persona memory, align this template with the guardrails from Building Agent Personality Through Memory so summaries reinforce the same voice.

Implementation paths inside OpenClaw

Option A: heartbeat automation

Use OpenClaw's heartbeat scheduler to run a summary script every hour or at the end of a shift.

cat <<'EOF' > scripts/session-summary.sh
#!/usr/bin/env bash
AGENT_NAME=$1
LOG_PATH=$2
NAMESPACE=$3
DURATION_MIN=$4

SUMMARY=$(tail -n 500 "$LOG_PATH" | ~/.openclaw/workspace/scripts/summarize-session.py \
  --agent "$AGENT_NAME" \
  --duration "$DURATION_MIN")
IMPORTANCE=$(python - <<'PY'
import random
print(round(0.6 + random.random() * 0.35, 2))
PY
)

memoclaw store \
  --namespace "$NAMESPACE" \
  --importance "$IMPORTANCE" \
  --tags session,summary \
  "$SUMMARY"
EOF
chmod +x scripts/session-summary.sh

openclaw heartbeat add --name support-summary \
  --interval "1h" \
  --command "./scripts/session-summary.sh support-agent logs/support.log ops/support-agent 60"

This runs on local compute. Store calls use the free tier for the first 100 requests, then cost $0.005 each.

Option B: agent-driven summaries

Let the agent generate a summary every time it hits a natural break (end of ticket batch, status transition). Add a tool call inside the loop:

{
  "tool": "memoclaw_store",
  "namespace": "ops/support-agent",
  "importance": 0.75,
  "tags": ["session", "summary"],
  "content": "<agent-generated-summary>"
}

Pair this with a planner that issues summarize_session directives so the agent never forgets.

Automation-heavy shops can combine both options: a heartbeat catches worst-case gaps while the agent stores summaries during lulls. For deeper automation scripts, borrow ideas from Automating Session Summaries.

Preventing garbage summaries

Garbage in, garbage out. Guard the pipeline with these rules:

Cap summary length at 700–1,000 characters. Longer entries dilute embeddings and waste money.
Ban generic phrasing via prompt instructions. Force the agent to cite specific actions, owners, and metrics.
Use recall-before-store: run a recall with the current timestamp. If a similar summary already exists (due to a retry), skip storing duplicates.
Score variability: tie importance to concrete triggers (escalation present? revenue impact > $1k?). Consistent scoring keeps urgent summaries above routine ones.

Integrating summaries into the agent workflow

Summaries are worthless unless you recall them at the right moments.

Start-of-shift primer: when an agent boots, pull the last three summaries for its namespace and pin them in the system message under ### Last three sessions.
Pre-action recall: before responding to a user or running a workflow, recall summaries filtered by relevant tags (e.g., billing).
Post-action verification: after storing a summary, immediately recall the last two entries. If the new one is missing, alert the operator—namespaces or wallet env vars may be wrong.

Handling runaway sessions

Agents often run 24+ hours without a clean break. In those cases, generate rolling summaries:

Break the timeline into two-hour windows.
Generate interim summaries at each boundary.
At shutdown, consolidate everything into a final summary using MemoClaw's consolidate endpoint or a custom script.

Pseudo-workflow:

for window in $(seq 0 22 24); do
  ./scripts/session-summary.sh research-agent logs/research.log ops/research-agent $((window+2))
done

# End-of-day consolidation
memoclaw consolidate --namespace ops/research-agent --tag summary --window "last24h"

Monitoring and auditing checklist

Keep the pipeline observable so you can answer "Did summaries run last night?" in seconds.

Task	Owner	Cadence
[ ] Query `memoclaw stats` for each active namespace and alert if the summary count fails to increase.	Ops lead	Daily
[ ] Track average `importance` via `memoclaw list --json`; low scores hint at broken heuristics.	Agent maintainer	Daily
[ ] Wrap `memoclaw store` with a timer and log latency to your dashboard.	Infra	Hourly
[ ] Sample five summaries per namespace (`memoclaw list --limit 5`) and review them in a standing meeting.	Team lead	Weekly
[ ] Export audit files (`memoclaw list > audits/<date>.md`) and archive them next to incident reports.	Compliance	Weekly

Cost management for summary-heavy agents

Session summaries add up if you run dozens of agents, but the math still works.

Assume 10 agents, each storing 24 summaries per day (hourly). That's 240 store calls.

Free tier covers the first 100 calls per wallet. See the breakdown in Cost Optimization: Free Tier.
Remaining 140 calls × $0.005 = $0.70/day.
Consolidation once per agent per day: 10 × $0.01 = $0.10/day.

Total: $0.80/day to maintain precise cross-session memory for your entire agent fleet. Even a single saved support escalation covers that cost.

Case study: ops agent running for a week straight

Scenario: A logistics operator keeps an OpenClaw agent watching incoming purchase orders 24/7. Before summaries, the agent double-billed shipments because it forgot which orders were already processed.

Implementation:

Namespace: ops/logistics-agent/sessions
Hourly heartbeat stores summary with metrics: orders processed, anomalies, manual overrides.
Importance scoring: 0.9 for any summary mentioning "manual override" or "delay"; 0.5 otherwise.
Start-of-shift recall feeds the last four summaries into the prompt.

Outcome:

Duplicate shipments dropped 82% in the first week.
When a warehouse issue reoccurred, operations traced it to three summaries mentioning "Dock 4 scanner offline." Without summaries, they would have combed through 50k lines of logs.

Security considerations

Storing summaries means persisting potentially sensitive data. Mitigate risk with:

Namespaces per customer to prevent cross-contamination.
Immutable policies reminding agents to redact PII before storage.
Access controls: only operators with the wallet's private key can read raw summaries. If you need to share sanitized snapshots, run them through a redaction script before exporting.

Extending the pattern beyond support agents

Session summaries benefit any long-running workflow:

Research agents capture interim findings and hypotheses before handoff.
Sales development bots track objections, commitments, and next steps.
Infrastructure monitors log incidents, mitigations, and escalations for on-call rotations.

Combine this article with the persona guidance in Building Agent Personality Through Memory so each agent stores summaries that match its role.

Implementation reference in pseudo-code

from memoclaw import store_memory, recall

SUMMARY_NAMESPACE = "ops/support-agent"

async def run_cycle(task):
    context = await recall(namespace=SUMMARY_NAMESPACE,
                           query="latest session summary",
                           limit=2)
    result = await handle_task(task, context)
    await maybe_summarize(task, result)

async def maybe_summarize(task, result):
    if task.completed or time_since_last_summary() > 3600:
        summary = build_summary(task, result)
        importance = score_summary(summary)
        store_memory(namespace=SUMMARY_NAMESPACE,
                     content=summary,
                     importance=importance,
                     tags=["session", task.category])

build_summary should enforce the template, while score_summary reads keywords like "escalated" or metrics like revenue_at_risk to adjust the score.

Quality checklist before shipping the summary system

[ ] Template defined and documented where every operator can find it
[ ] Automation path selected (heartbeat or agent-driven) and tested
[ ] Recall-before-store dedupe verified with real logs
[ ] Importance scoring heuristics tested on historical sessions
[ ] Monitoring dashboards wired up (counts, latency, averages)
[ ] Security review done (namespaces, redaction rules)
[ ] Runbook written for failed summary runs (what to check, how to replay)

Advanced tagging strategies

Basic tags like session and summary are fine for onboarding, but revenue teams squeeze more value by tagging for business impact.

revenue:<amount> encodes revenue impact directly in a tag (revenue:4200). During recall, filter summaries where revenue exceeds a threshold.
risk:<level> marks risk levels (risk:high, risk:low). When an agent prepares an escalation, pull only risk:high summaries.
sprint:<number> tags research summaries with sprint numbers so the next planning cycle has instant context.

MemoClaw treats tags as plain strings, so keep them lowercase and delimiter-free. Build helper functions in your agent code to add or remove tags consistently instead of letting prompts invent new ones.

Coordinating across multiple agents

Large teams run fleets of agents touching the same account. Use shared namespaces with sub-tags for ownership.

Example structure:

Namespace: customers/helios/sessions
Tags: agent:support, agent:finance, agent:research

When the support agent starts a shift, it runs:

{
  "tool": "memoclaw_recall",
  "namespace": "customers/helios/sessions",
  "tags": ["agent:support"],
  "limit": 3
}

When finance needs the bigger picture, it queries the same namespace but omits the agent tag to get cross-functional context. This design keeps memories centralized while still letting each agent filter down to what matters.

Troubleshooting

Symptom	Possible cause	Fix
Summaries repeat identical text	Summarizer prompt too generic	Feed it more structured context (metrics, actions) and add duplicate detection.
Summaries missing after restart	Namespace mis-typed or wallet unset	Validate namespace variables and env vars before storing.
Recall returns stale summaries	Importance not set or timestamps missing	Include ISO timestamps plus importance scaling.
Costs higher than expected	Summaries stored every few minutes unnecessarily	Increase summary interval or consolidate more aggressively.
Agents ignore summaries	Prompt not referencing recalled content	Update the system message to include `### Retrieved summaries`.

Bring it all together

Session summaries are the connective tissue between transient LLM context and the reality of multi-day operations. Install MemoClaw, enforce these session summaries, and wire them into your OpenClaw agents with discipline. When you do, "session summaries" stop being a buzzword and start acting like the reliable memory spine your operators need every single day.

Session summaries as strategic memory: keeping long-running OpenClaw agents sane

Ana Julia Bittencourt — Thu, 19 Mar 2026 12:11:47 +0000

Session summaries as strategic memory: keeping long-running OpenClaw agents sane

The problem: context rot in multi-day agent runs

OpenClaw teams stretch sessions across days to keep stateful agents online for support, research, or ops. Two failure modes repeat:

Prompt inflation: you spend half your tokens replaying yesterday's chat log.
Manual note-taking drift: a human (or a distracted agent) edits a shared doc until formatting and facts diverge.

What "session summary" means here

A session summary is a structured memory stored in MemoClaw describing what the agent just accomplished, what it learned, and what still needs attention. Each summary includes:

namespace: e.g., ops/<agent-name> or customers/<account>/sessions
importance: score between 0 and 1 based on the stakes
tags: session, summary, plus domain-specific markers
metadata: optional JSON for metrics (duration, tickets closed, revenue impact)

Standardizing namespaces up front keeps recalls tight. If you need help designing the hierarchy, review Namespace Strategies for OpenClaw Agents.

Anatomy of a high-quality summary

Element	What to capture
Timestamp + ID	ISO timestamp plus a human-friendly session label so overlapping workers stay untangled.
Concrete outcomes	Bullet outcomes with verbs, metrics, and customer names instead of vibes.
Follow-ups + owners	Explicit task, owner, and deadline so the next shift knows what to do.
Recall signals	Metrics such as revenue at risk, SLA breach count, or ticket volume that justify the `importance` score.
Next checkpoints	Pending blockers, experiments to rerun, or data still missing.

Designing the summary template

Builders get the best results when they standardize the template. Here's a field-tested structure you can drop into a system prompt, CLI script, or MCP tool:

Session: <agent-name> @ <timestamp>
Duration: <minutes>
Objectives: <list>
Outcomes:
- <Outcome + metric>
- <Outcome + metric>
Follow-ups:
- <task> (owner, due date)
Blocking issues:
- <issue + current status>
Signals:
- revenue_at_risk=<amount>
- escalations=<count>

Implementation paths inside OpenClaw

Option A: heartbeat automation

Use OpenClaw's heartbeat scheduler to run a summary script every hour or at the end of a shift.

cat <<'SESSION_SUMMARY' > scripts/session-summary.sh
#!/usr/bin/env bash
AGENT_NAME=$1
LOG_PATH=$2
NAMESPACE=$3
DURATION_MIN=$4

SUMMARY=$(tail -n 500 "$LOG_PATH" | ~/.openclaw/workspace/scripts/summarize-session.py \
  --agent "$AGENT_NAME" \
  --duration "$DURATION_MIN")
IMPORTANCE=$(python - <<'PY'
import random
print(round(0.6 + random.random() * 0.35, 2))
PY
)

memoclaw store \
  --namespace "$NAMESPACE" \
  --importance "$IMPORTANCE" \
  --tags session,summary \
  "$SUMMARY"
SESSION_SUMMARY
chmod +x scripts/session-summary.sh

openclaw heartbeat add --name support-summary \
  --interval "1h" \
  --command "./scripts/session-summary.sh support-agent logs/support.log ops/support-agent 60"

This runs on local compute. Store calls use the free tier for the first 100 requests, then cost $0.005 each.

Option B: agent-driven summaries

Let the agent generate a summary every time it hits a natural break (end of ticket batch, status transition). Add a tool call inside the loop:

{
  "tool": "memoclaw_store",
  "namespace": "ops/support-agent",
  "importance": 0.75,
  "tags": ["session", "summary"],
  "content": "<agent-generated-summary>"
}

Pair this with a planner that issues summarize_session directives so the agent never forgets.

Preventing garbage summaries

Garbage in, garbage out. Guard the pipeline with these rules:

Cap summary length at 700-1,000 characters. Longer entries dilute embeddings and waste money.
Ban generic phrasing via prompt instructions. Force the agent to cite specific actions, owners, and metrics.
Use recall-before-store: run a recall with the current timestamp. If a similar summary already exists (due to a retry), skip storing duplicates.
Score variability: tie importance to concrete triggers (escalation present? revenue impact > $1k?). Consistent scoring keeps urgent summaries above routine ones.

Integrating summaries into the agent workflow

Summaries are worthless unless you recall them at the right moments.

Start-of-shift primer: when an agent boots, pull the last three summaries for its namespace and pin them in the system message under ### Last three sessions.
Pre-action recall: before responding to a user or running a workflow, recall summaries filtered by relevant tags (e.g., billing).
Post-action verification: after storing a summary, immediately recall the last two entries. If the new one is missing, alert the operator-namespaces or wallet env vars may be wrong.

Handling runaway sessions

Agents often run 24+ hours without a clean break. In those cases, generate rolling summaries:

Break the timeline into two-hour windows.
Generate interim summaries at each boundary.
At shutdown, consolidate everything into a final summary using MemoClaw's consolidate endpoint or a custom script.

Pseudo-workflow:

for window in $(seq 0 22 24); do
  ./scripts/session-summary.sh research-agent logs/research.log ops/research-agent $((window+2))
done

# End-of-day consolidation
memoclaw consolidate --namespace ops/research-agent --tag summary --window "last24h"

Monitoring and auditing checklist

Keep the pipeline observable so you can answer "Did summaries run last night?" in seconds.

Task	Owner	Cadence
[ ] Query `memoclaw stats` for each active namespace and alert if the summary count fails to increase.	Ops lead	Daily
[ ] Track average `importance` via `memoclaw list --json`; low scores hint at broken heuristics.	Agent maintainer	Daily
[ ] Wrap `memoclaw store` with a timer and log latency to your dashboard.	Infra	Hourly
[ ] Sample five summaries per namespace (`memoclaw list --limit 5`) and review them in a standing meeting.	Team lead	Weekly
[ ] Export audit files (`memoclaw list > audits/<date>.md`) and archive them next to incident reports.	Compliance	Weekly

Cost management for summary-heavy agents

Session summaries add up if you run dozens of agents, but the math still works.

Assume 10 agents, each storing 24 summaries per day (hourly). That's 240 store calls.

Free tier covers the first 100 calls per wallet. See the breakdown in Cost Optimization: Free Tier.
Remaining 140 calls × $0.005 = $0.70/day.
Consolidation once per agent per day: 10 × $0.01 = $0.10/day.

Total: $0.80/day to maintain precise cross-session memory for your entire agent fleet. Even a single saved support escalation covers that cost.

Case study: ops agent running for a week straight

Implementation:

Namespace: ops/logistics-agent/sessions
Hourly heartbeat stores summary with metrics: orders processed, anomalies, manual overrides.
Importance scoring: 0.9 for any summary mentioning "manual override" or "delay"; 0.5 otherwise.
Start-of-shift recall feeds the last four summaries into the prompt.

Outcome:

Duplicate shipments dropped 82% in the first week.
When a warehouse issue reoccurred, operations traced it to three summaries mentioning "Dock 4 scanner offline." Without summaries, they would have combed through 50k lines of logs.

Security considerations

Storing summaries means persisting potentially sensitive data. Mitigate risk with:

Namespaces per customer to prevent cross-contamination.
Immutable policies reminding agents to redact PII before storage.
Access controls: only operators with the wallet's private key can read raw summaries. If you need to share sanitized snapshots, run them through a redaction script before exporting.

Extending the pattern beyond support agents

Session summaries benefit any long-running workflow:

Research agents capture interim findings and hypotheses before handoff.
Sales development bots track objections, commitments, and next steps.
Infrastructure monitors log incidents, mitigations, and escalations for on-call rotations.

Combine this article with the persona guidance in Building Agent Personality Through Memory so each agent stores summaries that match its role.

Implementation reference in pseudo-code

from memoclaw import store_memory, recall

SUMMARY_NAMESPACE = "ops/support-agent"

async def run_cycle(task):
    context = await recall(namespace=SUMMARY_NAMESPACE,
                           query="latest session summary",
                           limit=2)
    result = await handle_task(task, context)
    await maybe_summarize(task, result)

async def maybe_summarize(task, result):
    if task.completed or time_since_last_summary() > 3600:
        summary = build_summary(task, result)
        importance = score_summary(summary)
        store_memory(namespace=SUMMARY_NAMESPACE,
                     content=summary,
                     importance=importance,
                     tags=["session", task.category])

build_summary should enforce the template, while score_summary reads keywords like "escalated" or metrics like revenue_at_risk to adjust the score.

Quality checklist before shipping the summary system

[ ] Template defined and documented where every operator can find it
[ ] Automation path selected (heartbeat or agent-driven) and tested
[ ] Recall-before-store dedupe verified with real logs
[ ] Importance scoring heuristics tested on historical sessions
[ ] Monitoring dashboards wired up (counts, latency, averages)
[ ] Security review done (namespaces, redaction rules)
[ ] Runbook written for failed summary runs (what to check, how to replay)

Advanced tagging strategies

Basic tags like session and summary are fine for onboarding, but revenue teams squeeze more value by tagging for business impact.

revenue:<amount> encodes revenue impact directly in a tag (revenue:4200). During recall, filter summaries where revenue exceeds a threshold.
risk:<level> marks risk levels (risk:high, risk:low). When an agent prepares an escalation, pull only risk:high summaries.
sprint:<number> tags research summaries with sprint numbers so the next planning cycle has instant context.

Coordinating across multiple agents

Large teams run fleets of agents touching the same account. Use shared namespaces with sub-tags for ownership.

Example structure:

Namespace: customers/helios/sessions
Tags: agent:support, agent:finance, agent:research

When the support agent starts a shift, it runs:

{
  "tool": "memoclaw_recall",
  "namespace": "customers/helios/sessions",
  "tags": ["agent:support"],
  "limit": 3
}

Troubleshooting

Symptom	Possible cause	Fix
Summaries repeat identical text	Summarizer prompt too generic	Feed it more structured context (metrics, actions) and add duplicate detection.
Summaries missing after restart	Namespace mis-typed or wallet unset	Validate namespace variables and env vars before storing.
Recall returns stale summaries	Importance not set or timestamps missing	Include ISO timestamps plus importance scaling.
Costs higher than expected	Summaries stored every few minutes unnecessarily	Increase summary interval or consolidate more aggressively.
Agents ignore summaries	Prompt not referencing recalled content	Update the system message to include `### Retrieved summaries`.

Bring it all together

From 5 minutes to production — adding MemoClaw to your OpenClaw agent the right way

Ana Julia Bittencourt — Thu, 19 Mar 2026 12:11:29 +0000

From five minutes to production: wiring MemoClaw into your OpenClaw agent without cutting corners

Need a refresher on why flat files fail? Read The Case Against MEMORY.md, then come back here to build a real OpenClaw memory spine.

Quick-reference build checklist

Step	Owner	Outcome
Install MemoClaw skill + CLI	Agent maintainer	Tooling available in OpenClaw and shell
Map namespaces	Ops lead	Documented table for `core`, `customers/<slug>`, `ops/<agent>`
Embed store/recall templates	Prompt engineer	JSON snippets committed in repo
Define recall cadence	Agent maintainer	Start, pre-output, post-correction hooks
Add guardrails + fallback paths	Reliability	Empty recall + conflict handling routine
Automate hygiene (dedupe, consolidate, stats)	Ops	Heartbeat or cron jobs running
Document production checklist	Team lead	Shared runbook tied to onboarding

Why this workflow prints money for OpenClaw builders

Prerequisites

OpenClaw running on your workstation or server
Wallet funded with a few cents of USDC on Base (post-free tier usage)
MEMOCLAW_WALLET and MEMOCLAW_PRIVATE_KEY exported in your shell
Optional: gh CLI for automated audits

Step 1: install MemoClaw the way real agents do

MemoClaw ships as both a CLI and an OpenClaw skill. For operators, the skill is the fastest path.

openclaw skills install anajuliabit/memoclaw --force
openclaw skills list | grep memoclaw

Need CLI access for migrations or backups? Install it globally:

npm install -g memoclaw

MemoClaw uses wallet-based identity-no API keys. Confirm the wallet currently set in OpenClaw before you rely on the skill:

echo $MEMOCLAW_WALLET || echo "Wallet missing"

Export the wallet and private key if needed:

export MEMOCLAW_WALLET=0xYourWallet
export MEMOCLAW_PRIVATE_KEY=0x...

Step 2: define namespaces before you store anything

Skipping namespaces is the fastest way to leak context between projects. Align on a structure inspired by Namespace Strategies for OpenClaw Agents:

Namespace	Use case
`core`	Immutable policies (security, billing, voice)
`customers/<slug>`	Client-specific context
`ops/<agent-name>`	Operational agents (heartbeats, inbox monitors)
`experiments/<codename>`	Short-lived sandboxes

MemoClaw creates namespaces lazily when you store the first memory:

memoclaw store \
  --namespace core \
  --importance 0.9 \
  --tags onboarding,defaults \
  "Ally must never publish drafts directly. Stop at draft handoff."

Step 3: wire store/recall directly into your agent loop

MemoClaw calls are simple JSON tool invocations-keep them nearby so every agent uses the same plumbing.

Store template

{
  "tool": "memoclaw_store",
  "namespace": "customers/lumen",
  "importance": 0.75,
  "tags": ["preferences", "product"],
  "content": "Lumen prefers Telegram summaries under 200 words."
}

Recall template

{
  "tool": "memoclaw_recall",
  "namespace": "customers/lumen",
  "query": "What should I remember before writing Lumen's weekly report?",
  "limit": 5
}

Commit these snippets to your agent repo so every new teammate copies the same version.

Step 4: design the recall strategy like it's a production dependency

Turn the recall plan into a scannable routine:

When: run recall at session start, before user-facing output, and right after a correction.
How many: default to five memories; bump to ten only if you store session summaries or research chunks.
Prompt merge: paste recall results under a fixed template such as:

### Retrieved memories
1. <memory>
2. <memory>

### Task
<instruction>

Fallback: if recall fails, inject a deterministic checklist ("No stored context. Use the public positioning doc.").

Step 5: handle empty recalls and stale context

Short reminders beat long paragraphs:

Empty recall → Run a fallback snippet so the agent never improvises.
Stale data → Store timestamps plus a metadata field like "expires_at": "2026-05-01"; ignore expired entries in code.
Conflicting facts → Lean on importance. Corrections get 0.95, offhand comments 0.2, so mission-critical items always sort to the top.

Step 6: automations that keep the memory layer honest

Recall-before-store guardrail: recall with the new content as a query and skip the store if similarity > 0.92.
Weekly consolidation: call memoclaw consolidate --namespace customers/lumen to merge redundant entries.
Stats-driven audits: run memoclaw stats and memoclaw list --limit 10 inside a heartbeat. Alert if counts spike or drop unexpectedly.
Session summaries: add a heartbeat that ships summaries hourly; borrow prompts from Automating Session Summaries.

Step 7: production checklist

Before you declare an agent "live," verify:

[ ] Wallet env vars set in .env and active tmux sessions
[ ] Namespaces documented and version-controlled
[ ] Store + recall templates committed to the repo
[ ] Guardrails implemented (empty results, expiration, duplicates)
[ ] Hygiene jobs scheduled (consolidate, stats audit)
[ ] Immutable memories created for non-negotiables

Step 8: integrate with other systems without diluting memory quality

MemoClaw plays well with the rest of your stack as long as roles stay clear:

Docs or Notion: export via memoclaw export --namespace ... and send the JSON to leadership.
Analytics dashboards: push stats output to Grafana or Metabase so outages show up next to API metrics.
Incident response: run memoclaw history mem_123 to trace how a memory evolved before filing a root-cause report.

Step 9: cost planning so finance never blocks you

MemoClaw charges only when embeddings or GPT are involved. For a typical ops agent:

Operation	Calls/day	Cost per call	Daily total
Store (single)	30	$0.005	$0.15
Recall	40	$0.005	$0.20
Consolidate	1	$0.01	$0.01
Daily cost			$0.36

Batch storage is your best lever when ingesting historical data: 100 memories for $0.04 vs $0.50 individually. For deeper math and wallet planning, revisit Cost Optimization: Free Tier.

Step 10: failure drills

Run chaos drills monthly so the team trusts the memory layer under load.

Expired credentials: unset $MEMOCLAW_PRIVATE_KEY and confirm the agent fails loudly.
Namespace pollution: intentionally store a wrong memory, run your dedupe routine, and ensure it catches the anomaly.
Free-tier exhaustion: point MEMOCLAW_URL to a staging proxy that reports remaining=0 so monitoring alerts the team.

Example: full OpenClaw tool chain for onboarding a new agent

# 1. Install skill
openclaw skills install anajuliabit/memoclaw --force

echo $MEMOCLAW_WALLET  # verify

# 2. Populate immutable core knowledge
memoclaw store --namespace core --immutable true \
  "Never email customers from dummy domains."

# 3. Create namespace per customer
memoclaw store --namespace customers/lumen "Namespace created" --importance 0.1

# 4. Seed intro memories
memoclaw store --namespace customers/lumen --importance 0.8 \
  "Weekly report due Mondays 14:00 UTC"

# 5. Configure agent prompts
Update system prompt with: 'Always recall from customers/<slug> before user-facing output.'

# 6. Test recall guardrails
memoclaw_recall namespace=customers/lumen query="status" limit=5
Confirm fallback path when zero results returned.

Troubleshooting cheatsheet

Symptom	Likely cause	Fix
Store calls failing with 401	Wallet env vars missing	Re-export `$MEMOCLAW_WALLET` + `$MEMOCLAW_PRIVATE_KEY`
Recall returns irrelevant memories	Flat importance scores, no namespaces	Re-score critical items, enforce namespace mapping
Duplicate memories everywhere	Dedupe routine missing	Run recall-before-store guardrail
Agent forgets cross-session facts	Heartbeat not storing summaries	Add end-of-session summary store call
Costs spike unexpectedly	Batch store not used	Use `memoclaw store-batch` for >20 entries

Instrumentation: prove the memory layer is doing its job

Once the workflow is live, add telemetry so you can debug issues in minutes.

Emit metrics per call type: wrap each tool call in a shim that records namespace, operation, latency_ms, and result_count. Ship it to whatever metrics stack you already run (Grafana, Datadog, Prometheus).
Log retrieved memories alongside outputs: when your agent sends a final response, log the recall payload it used. Redact sensitive data but keep enough text to trace bad decisions back to specific memories.
Alert on hygiene failures: monitor duplicate skip counts and expired-memory usage. Spikes flag teams that forgot to refresh SLAs or pricing tables.

Session summary automation in practice

openclaw heartbeat run <<'EOT'
SUMMARY=$(tail -n 200 logs/support-agent.log | ./scripts/summarize.sh)
memoclaw store \
  --namespace ops/support-agent \
  --importance 0.7 \
  --tags session,summary \
  "$SUMMARY"
EOT

Keep summaries under 1,000 characters and rotate the importance score based on novelty. A routine "no changes" summary should sit near 0.3, while a production incident deserves 0.95.

Bridging test and production environments

memoclaw export --namespace customers/lumen-dev > lumen-dev.json
jq '.memories | map({namespace: "customers/lumen", content, importance, tags})' \
  lumen-dev.json > lumen-prod.json
memoclaw store-batch lumen-prod.json

Checklist for onboarding new operators

When another builder joins the team, hand them this list:

Read this guide plus Building Agent Personality Through Memory to understand tone guardrails.
Run memoclaw stats on every namespace they own; paste the output in the weekly ops doc.
Trigger manual recalls to internalize what "good" looks like.
Review immutable memories so they know the non-negotiables.
Practice restoring from export by spinning up a scratch namespace, importing the latest backup, and verifying the agent can recall from it.

Deploy this pattern with confidence

Tag-based memory filtering: laser-focused recall for specialized agents

Ana Julia Bittencourt — Thu, 19 Mar 2026 08:16:31 +0000

Tag-based memory filtering: laser-focused recall for specialized agents

Semantic search gets you close, but there are days when you cannot afford fuzzy matches. When an OpenClaw agent handles regulated workflows or needs to recall only customer preferences, you have to scope the search down to the exact subset of memory that matters. Tags are how you do it. MemoClaw lets you assign any number of tags to each memory, then filter recalls by those tags, namespaces, and importance thresholds. Used well, tags turn a pile of embeddings into a well indexed notebook.

TL;DR

Tags turn MemoClaw into an indexed log. Pair them with namespaces and importance scores to control recall precision.
Tag filters keep memory outside the prompt window, so you get laser recall with zero token tax while every OpenClaw sub-agent on the wallet reads the same scoped slice.
Build a shared taxonomy with prefixes like customer:, topic:, stage:. Enforce it so agents do not invent random strings.
Use tag filters with semantic queries for best results: text narrows meaning, tags narrow scope.
Keep hygiene tight: audit tags, consolidate duplicates, and age out stale entries so signal stays clean.

Why tags matter more than ever

Context windows are larger, but production agents still choke when you toss raw search results at them. Tags solve three problems at once:

Precision. Telling MemoClaw to return only memories tagged customer:lyra keeps other accounts out of the conversation.
Speed. Smaller result sets mean faster recalls and less JSON to parse before feeding the agent.
Safety. In regulated workflows you can ensure that only memories tagged compliance ever show up during certain steps.

Without tags, you keep rerunning recalls until the right memory happens to float to the top. With tags, you ask once and move on.

Designing a tag taxonomy

Tags only work if every agent agrees on the same language.

Start with prefixes. customer:<slug>, source:<system>, stage:<phase>, urgency:<level>, release:<name>. Prefixes prevent collisions and make filtering easier.
Limit free text. Humans love to improvise. Publish a YAML or JSON file with approved values. Reject anything outside the list.
Keep tags short. Hyphenated slugs beat full sentences. topic:memory-budgeting is better than topic:how-to-manage-memory. Short tags reduce mistakes and keep recall commands readable.
Document mandatory tags. For example, every support note might require both customer and status. Your storage wrapper should refuse to store memories missing those tags.
Version the taxonomy. When you rename a tag, run a script that updates historical memories via memoclaw update. Consistency across time is what gives you confident recall.

Combining tags with namespaces and importance

Tags are only one axis. MemoClaw also lets you split data into namespaces and rank items by importance.

Namespaces isolate broad domains. Put customer insights in customer, incidents in incidents, product feedback in product. It is fine to store the same text twice with different namespaces if it serves two roles.
Importance scores float the needles to the top. A memory tagged customer:lyra with importance 0.9 will beat a 0.4 note even if both share the same tags. Score ruthlessly so your recall payloads contain the best nuggets.
Immutable flag locks critical facts. When you tag something compliance:sox you might also want to pass --immutable so nobody edits it later.

Set policies per namespace. For example, support-live might require importance >= 0.5, while research-notes tolerates 0.2 because you would rather keep rough notes than lose a lead entirely.

Crafting high signal recall queries

Tag filters shine when paired with an actual question. Here are patterns we use daily.

Exact tag filter

Return the five most important deployment notes for a customer:

memoclaw recall \
  --namespace customer-ops \
  --tags customer:lyra,topic:deployments \
  --limit 5 \
  --importance-min 0.6

Tag plus text

Combine tags with a semantic query to answer specific questions:

memoclaw recall \
  --namespace support \
  --tags customer:lyra,status:open \
  --query "neon sync failure" \
  --limit 3

Tag unions

MemoClaw treats comma separated tags as an AND filter. If you need OR behavior, run two recalls or store aggregate tags like segment:enterprise and segment:startups so you can filter at a higher level.

Time slicing

Add a tag such as captured:2026-03 when storing. Later you can ask for --tags captured:2026-03. This beats relying on created-at timestamps because tags survive exports and manual edits.

Implementation pattern inside OpenClaw

Centralize tagging logic. Wrap memoclaw store inside a helper script that enforces tag rules. Agents call the helper with structured data, not raw tag strings.
Expose tag suggestions to agents. Include a cheat sheet in the system prompt showing available tags. When agents output memory_tags, parse and validate those entries before storing.
Record tag usage. Each time you store a memory, append the tags to a local log. That log becomes the data source for future audits.
Teach planners to filter. In the planning prompt, remind the agent which tag combos unlock the right recall. Example: "Before answering, recall with tags customer:<slug> plus topic:<topic>." That instruction keeps every sub-agent that shares the wallet aligned on the same recall scope.
Cache results by tag. If an agent fetches customer:lyra three times in ten minutes, reuse the earlier payload unless new memories exist. That reduces spend.

Advanced techniques

Tag hierarchies

You can simulate hierarchies without native nesting. When you store a memory about an outage in the Paris region you might use tags region:eu, region:eu-paris, and service:api. That lets you recall by continent or by metro without extra logic.

Tag driven routing

Morgan style orchestrators can read tag metadata to decide which specialist agent should own a task. For example, if a memory is tagged topic:payments, route the incident to the payments fixer. Tags become lightweight metadata for the job queue.

Tag plus importance heat maps

Export memories weekly and build a pivot showing tag counts per importance bucket. If critical tags only contain low importance entries, your scoring rubric is broken.

Dedup by tag clusters

When you consolidate, group by tag sets first. If two memories share identical tag sets and similar text, merge them or delete the duplicate to keep recalls crisp.

Maintaining hygiene

Scheduled audits: Run memoclaw list --tags <prefix> to sample entries. If tags drift, fix them immediately.
Automated validation: Use a JSON schema that defines allowed tag prefixes. Reuse it in every agent script.
Consolidate regularly: memoclaw consolidate --namespace support --tags customer:lyra merges overlapping entries and keeps the namespace lean.
Educate humans: Your human teammates need to know tag meanings so they can debug results. Publish a short README in the repo and pin it in Slack.

Scenario: Specialized compliance agent

A compliance agent reviews wallet transactions for AML red flags. It follows this plan:

Ingest: Every flagged transaction summary gets stored with tags: ["customer:<id>", "risk:high", "source:aml-bot", "rule:travel-rule"] and a namespace compliance.
Investigation: When a new alert arrives, the agent recalls --namespace compliance --tags customer:<id>,risk:high to see how many past alerts exist.
Decision: If the recall shows recent entries tagged status:escalated, the agent recommends involving a human.
Reporting: After closing the case, the agent stores the outcome with tags: ["customer:<id>", "status:closed", "reviewer:agent"]. Immutable flag stays on to lock the record.

Thanks to consistent tags, investigators can pull a full history for a wallet in seconds and prove that every decision considered relevant context.

Checklist before you rely on tags

Write down every tag prefix, accepted values, and which namespace requires them.
Build lint checks that run inside CI to reject commits that add unrecognized tags to helper scripts.
Ensure every memo includes at least one functional tag (like topic) and one scoping tag (like customer).
Run a recall dry run for each namespace that shows more than 500 memories. If the response feels noisy, revisit your taxonomy.
Keep a changelog of tag updates. When you rename topic:deployments to topic:release, note it and run an update job so old memories keep working.

Tooling to manage tags

Tag registry file: Keep a tags.yml file in your repo. Agents can read it at runtime, and humans can open a pull request when they need a new tag.
CLI helpers: Wrap memoclaw recall and store inside scripts that auto append required tags so callers cannot forget them.
Dashboards: Feed memoclaw stats --namespace <name> --json into a simple dashboard showing tag counts per week. When one tag drops to zero you know a workflow broke.
Alerting: Watch for memories stored without tags. The API accepts an empty array, so add a guard that rejects those writes before they leave your workspace.
IDE snippets: Give human operators snippets for the tags they use most so they stop inventing new ones under deadline pressure.

Common mistakes and how to fix them

Using tags for everything: Tags are for scoping, not for narrative. If you find yourself tagging with full sentences, trim the text and keep the description in the memory body instead.
Letting agents invent values: Agents will happily output customer:acme-corp one minute and customer:AcmeCorp the next. Normalize cases and strip punctuation before storing.
Never cleaning duplicates: Two tags that mean the same thing fragment recall. Run a script that finds similar tag names and standardizes them.
Forgetting to update recalls: When you add a new tag, update every agent prompt so they know it exists. Otherwise the tag never gets used.
Chaining too many tags in one recall: If you demand five tags at once you might get zero results. Start with the most important two tags, check the output, then narrow if needed.

Testing tag filters

Testing recall filters should be part of your CI the same way API tests are. Add a suite that spins up a fake wallet, stores sample memories with known tags, and runs scripted recalls to assert the right IDs come back. For live systems, keep a smoke-test namespace. Write a memory tagged smoke:test every hour, then have a monitor recall it. If the recall ever fails you know tagging or recall infrastructure broke before real customers notice.

Rollout timeline that works

Day 1: Audit existing memories, list the tag patterns already in use, and write the shared taxonomy. Day 2: Update store helpers and agent prompts so new tags apply automatically. Day 3: Backfill critical namespaces by retro tagging the top 100 memories per customer. Day 4: Add monitoring plus CI tests. By the end of the week you should have every workflow storing with tags, and Sage will have enough metadata to review drafts faster.

FAQ

Can I retroactively tag old memories? Yes. Use memoclaw update <id> --tags ... or export the namespace, edit the JSON, and re import it. Plan the job carefully so you do not lose importance scores.

How many tags are too many? Most teams stay under five tags per memory. More than that often means you are compensating for sloppy namespaces. If you hit double digits regularly, revisit your structure.

Do tags affect cost? No. Adding tags to a memory does not change pricing. The only cost driver is how often you call endpoints that use embeddings or GPT.

What if two teams need the same tags but different meanings? Namespaces keep semantics apart. The same tag name can exist in two namespaces with different meanings, but you should avoid it unless both teams agree on the definition.

Can tags enforce access control? Not today. Access is wallet wide. Use separate wallets if you need hard isolation, then rely on tags for filtering inside each wallet.

Conclusion

Tag based filtering is the difference between an agent that reuses your hard earned knowledge and an agent that keeps guessing. Write the taxonomy, enforce it with scripts, combine it with namespaces and importance scores, and teach your planners to recall with tags before every decision. It takes a day to set up and pays for itself the first time an agent answers a tricky question without paging a human for context.

Batch storing memories: when MemoClaw's bulk API saves 87 percent

Ana Julia Bittencourt — Thu, 19 Mar 2026 08:15:43 +0000

Batch storing memories: when MemoClaw's bulk API saves 87 percent

Every OpenClaw agent starts with a few manual stores. Then a migration shows up and you suddenly need to stuff thousands of facts into MemoClaw. Calling memoclaw store one record at a time feels safe, but it torches both time and budget. The batch endpoint was built for these moments. It writes up to one hundred memories per call for $0.04, keeps tags and importance intact, and gives you atomic feedback so you know which payloads succeeded. If you plan around that endpoint from the start, onboarding a new customer or backfilling a year of tickets becomes a short background job instead of an all-nighter.

Our first big pilot with a design studio forced this lesson. The lead dev tried to import 4,800 markdown snippets with a while loop and individual store calls, then pinged me at 3 a.m. asking why the wallet balance evaporated. We rewrote the job with batch uploads, re-ran it in twelve minutes, and spent $1.92 instead of $24. That became the policy: no more manual drips when a replay is on the calendar.

TL;DR

Single store calls cost $0.005 each after the free tier. Batch store writes up to 100 records for $0.04, which is an 87 percent discount once you batch more than eight items.
Batch shines on user onboarding, migrating MEMORY.md files, nightly session summaries, and any workflow that emits structured observations.
Design payloads with consistent schemas: text body, tags array, namespace, importance. Validate locally before shipping them to MemoClaw.
Batch imports land outside the prompt window, so you add thousands of memories with zero token tax while every OpenClaw sub-agent on the same wallet gains access instantly.
Pair the batch endpoint with OpenClaw cron jobs so long imports happen off the critical path. Capture partial failures, retry idempotently, and log the returned IDs for audits.

The cost math

MemoClaw only charges for operations that touch embeddings or GPT. That still adds up when you are loading historic data.

Records	Singles cost	Batch cost	Savings
10	$0.05	$0.04	20%
50	$0.25	$0.04	84%
100	$0.50	$0.04	92%

Those numbers mean you should default to batch for any replay job over eight items. Singles still make sense for real time logging during an agent session, but scheduled jobs should always bundle writes.

When batch storage wins

Customer onboarding

A new enterprise wallet shows up with a PDF of preferences, network maps, runbooks, and gotchas. Parsing that once and batching the output saves two things: money and opportunity cost. Instead of waiting half an hour for a loop of single stores, you drop the entire kit for $0.04 and move on.

MEMORY.md migrations

Thousands of OpenClaw users still keep long MEMORY.md files. When they move to MemoClaw they have to import years of notes. Split the file into paragraphs, assign tags like source:memory-md plus the original folder path, then batch. The importer can even keep the original timestamp in a custom tag so future recalls filter by timeframe.

Session summaries

Agents that run 24 hours keep end of shift summaries. Rather than storing each bullet by itself, buffer them for five minutes and write one batch. You keep semantic granularity while slashing calls.

Cron driven data sync

If you need to sync answers from an external system every hour, there is no reason to use single stores. Fetch the data, build the payload, and send it through the batch endpoint so you stay inside budget.

Designing a clean payload

A good batch payload is boring and predictable. Each memory in the array should carry the same fields so downstream recalls stay reliable.

[
  {
    "text": "Customer SolarFlux deploys every Wednesday and freezes changes during launches.",
    "namespace": "customer-ops",
    "tags": ["customer:solarflux", "cadence:weekly", "risk:launch"],
    "importance": 0.74
  },
  {
    "text": "Customer SolarFlux keeps emergency contacts at ops@solarflux.dev.",
    "namespace": "customer-ops",
    "tags": ["customer:solarflux", "contact:ops"],
    "importance": 0.63
  }
]

Tips:

Keep texts under 8192 characters. That is the per memory cap.
Normalize tags. Lowercase, no spaces, predictable prefixes like customer: or source:.
Carry timestamps. If the source data has dates, put them in a tag like captured:2026-03-18 so recall filters can reason about freshness.
Validate locally. Run a JSON schema check before calling the API so you fail fast.

Wiring batch storage into OpenClaw

The easiest place to run batch jobs is a cron agent. Here is a starter flow for migrating a MEMORY.md file every night until the backlog is empty.

#!/bin/bash
set -euo pipefail

SOURCE=~/openclaw/workspace/memory/backlog/*.md
for file in $SOURCE; do
  jq -Rs 'split("\n\n") | map(select(length > 0)) |
    each as $paragraph |
    {text: $paragraph, namespace: "memory-backfill", tags: ["source:memory-md", "file:'"$file"'"], importance: 0.55}' \
    "$file" > /tmp/batch.json
  memoclaw store --batch < /tmp/batch.json
  mv "$file" ~/openclaw/workspace/memory/imported/
done

You do not have to write bash. The CLI accepts JSON files or stdin, and the SDKs expose the same structure if you prefer Python or TypeScript. The pattern is what matters: gather items, shape them, batch once.

Handling partial failures

The batch endpoint returns success per memory. You still have to act on it.

Check response codes. A 200 means the API processed the batch. Inside the body you will find per item status plus IDs for the successful ones.
Retry idempotently. Keep a hash of text + namespace + tags. If a retry payload matches an earlier write you can skip storing it again or accept the duplicate and clean it later with consolidate.
Log IDs. Write every returned memory ID into a spreadsheet or datastore. That log is what you will use later for deletes or audits.
Alert on repeated failures. If more than 5 percent of items fail, pause the job and surface the errors. They usually indicate a malformed payload or a tag naming bug.

Observability and budgets

Batch jobs are invisible unless you record what happened.

Use memoclaw stats --namespace <name> --since <date>. It shows how many stores hit the namespace each day. Spikes reveal failed dedupe or a runaway job.
Export after each batch. memoclaw export --namespace memory-backfill --since 2026-03-18 gives you the exact payloads that landed. Store the file in object storage.
Track spend per namespace. Run memoclaw stats --json --namespace memory-backfill | jq -r '.spend.usd' (or hit /v1/stats?namespace=memory-backfill with x-wallet-auth) and feed that number into whatever dashboard Finance watches so they see the real batch costs.
Compare before vs after recall latency. Once the batch job completes, measure how long recalls take. If latency rises, add more tags or split namespaces to keep result sets small.

Real example: onboarding a pilot customer

A studio signs up for a pilot and hands you a trove of context. Here is how the flow looks:

Normalize the data. Parse their Google Doc into discrete facts: toolchain, release cadence, escalation contacts, risk items.
Score importance. Anything tied to production stability gets 0.8+. Preferences land around 0.6.
Assign namespaces. Put operational details into customer-ops. Put product wishes into customer-product. That split makes later recalls sharper.
Batch store. Build the JSON payload and run cat payload.json | memoclaw store --batch.
Record IDs. Log the output to customer-solarflux-import.log with timestamp, ID, and source paragraph.
Trigger a recall. Have the support agent call memoclaw recall --namespace customer-ops --tags customer:solarflux --limit 5 during its first plan step. The context shows up immediately for every agent that shares the wallet, no prompt restuffing required.

Total time: under fifteen minutes including scripting. Without batch you would have spent half an hour waiting on sequential writes and would have paid five times as much.

Checklist for safe imports

Confirm the wallet has enough balance for the entire batch. 100 records cost $0.04, so free tier wallets can cover two batches before paying.
Dry run by slicing the first ten items and uploading them alone. Inspect the returned IDs and tags.
Record the git commit or document that generated the data so you can trace the source later.
After the import, run memoclaw list --namespace <name> --limit 20 --json to spot check content.
Schedule a follow up recall script that ensures the new data actually influences agent plans. Storage without recall is wasted effort.

Advanced batching patterns

Rolling window batches: When agents generate dozens of observations per hour, drop them into a queue and flush every five minutes or every 40 items, whichever comes first. That keeps latency low while still unlocking the discount.
Hybrid writes: Mix high priority singles with low priority batches. For example, store a critical outage note immediately, but buffer the supporting details for the next batch.
Namespace mirroring: Write the same batch to two namespaces when you need different recall strategies. Support might recall by customer, while product recalls by feature.
Importance stratification: Sort the payload before uploading so high importance items sit first. If a batch fails halfway through you at least persisted the critical pieces.
Cross wallet mirroring: Some teams keep a staging wallet for QA. Run the exact same batch against staging before production. When staging passes you can trust the production upload.

TypeScript batch runner for OpenClaw subagents

import { readFileSync } from "fs";
import { MemoClaw } from "@memoclaw/sdk";

const client = new MemoClaw({ walletKey: process.env.WALLET_KEY! });

async function runBatch(path: string) {
  const payload = JSON.parse(readFileSync(path, "utf8"));
  const response = await client.storeBatch(payload);
  response.items.forEach(item => {
    if (item.status === "ok") {
      console.log(`stored ${item.id} in ${item.namespace}`);
    } else {
      console.error(`failed item: ${item.error}`);
    }
  });
}

runBatch(process.argv[2]).catch(err => {
  console.error(err);
  process.exit(1);
});

Drop that script into an OpenClaw automation and have the agent generate the payload file, then call node batch-runner.js payload.json. It keeps retries simple and gives you structured logs per item.

Post-batch recall strategy

Uploading is half the job. You also have to confirm that future recalls actually use the new data. Build a short checklist for every import:

Run targeted recalls such as memoclaw recall --namespace customer-ops --tags customer:solarflux --limit 3. Read the output and make sure it reflects the payload.
Add automated tests that spin up a throwaway OpenClaw agent, call the recall command, and assert that the returned JSON includes the expected tags.
Monitor token usage. Once the agent stops re asking humans for the same context, you should see prompt size drop. If it does not, you forgot to wire the recall into your planning loop.
Teach humans how to ask for the new memories. If sales engineers do not know tags exist, they will never filter by customer.

Governance and cleanup

Batches can rot if you never revisit them. Schedule maintenance as part of the same project:

Age off stale imports. If an onboarding batch is older than six months, export it, archive it, then delete it so recalls stay lean.
Tag drift audits. Once a month run memoclaw list --namespace customer-ops --limit 100 --json | jq '.[].tags' | sort | uniq -c to inspect which tags dominate. If new prefixes appear, decide whether they are valid or need cleanup.
Immutable guardrails. For compliance memories, pass --immutable when storing. During audits, verify the flag is still present so nobody silently edits those facts.
Cross namespace checks. If two namespaces keep referencing the same source data, merge them or add better tags. Overlapping namespaces confuse recalls and double your spend.

FAQ

What happens if one memory in the batch is too large? That item fails with a descriptive error. The rest of the batch still writes. Fix the oversized entry by trimming the text or splitting it into two records, then retry only that item.

Can I mix namespaces inside one batch? Yes. Each item carries its own namespace, tags, and importance score. That makes it easy to import a mix of support notes and engineering summaries without extra calls.

How do I keep batch jobs from clashing with real time stores? Use namespaces to isolate historical imports. Real time agents can keep using default or support-live while your cron agent writes to support-backfill. Later you can consolidate the two spaces.

Does batching affect recall relevance? No. MemoClaw indexes each record individually. As long as your tags and importance scores are honest, the search results stay sharp.

Do I still get 100 free calls? Yes. The free tier counts API calls, not records. A wallet can run 100 batch calls for free, which translates to up to 10,000 memories before you pay.

Conclusion

Batch storage is the cheapest lever you have for loading context into MemoClaw. It turns migrations, onboarding, and nightly flushes into predictable jobs with predictable bills. Plan the payload, validate tags, watch the stats, and treat the returned IDs like receipts. Once you make batching a default, you will stop telling customers to wait while an agent backfills context one record at a time.

Stateful agents in 2026: persistent memory beats bigger prompts

Ana Julia Bittencourt — Thu, 19 Mar 2026 08:15:42 +0000

Stateful agents in 2026: persistent memory beats bigger prompts

Developers spent 2025 chasing larger context windows. It helped for a minute, then support tickets piled up again: agents forgot customer preferences, forgot which fix already shipped, and forgot the plan that yesterday's shift agreed on. Stateless execution is a dead end when your production agent has to coordinate hundreds of steps over days. The teams that are shipping stable agents this year did not get better models. They stopped throwing the past away.

I watched one OpenClaw pod burn a full week trying to keep a retail support bot "in character" with nothing but prompt stuffing. Every night the agent spun up fresh, misdiagnosed the same issue, and re-opened tickets that had already been resolved. The only thing that changed the trajectory was bolting MemoClaw underneath the workflow so the bot actually remembered what it promised customers.

TL;DR

Bigger prompts do not turn a stateless agent into a reliable worker. You need a durable memory service that survives process restarts and sub-agent churn.
MemoClaw gives OpenClaw teams a wallet based identity, importance scoring, namespaces, and tag filters so every recall is scoped to the exact slice you need.
A working stateful stack fits into five steps: install the MemoClaw skill, pick namespaces, score new information, store it with tags, and recall with filters before every major decision.
Instrument the memory layer with stats and exports so you can audit what the agent learned and prune anything stale.
Every recall happens outside the prompt window, so you cut token waste to zero while sharing the same memory set across every sub-agent that signs with the wallet.

Why stateless agents keep breaking

OpenClaw makes it trivial to boot a new process for every session. That sounded nice until real workflows showed up.

The breaking point usually arrives the first time a human escalates a ticket and the follow-up agent cannot see the prior commitments. That is when the pager rings.

Session resets wipe context. Support agents run for ten minutes at a time, then spin down. When the next request lands, the new worker has to re-learn everything about the user. Users notice.
Prompt stuffing wastes tokens. The default reaction is to jam MEMORY.md into the system prompt. That eats thousands of tokens before the agent even hears the new question, raises latency, and still leaves you blind when the file exceeds the window.
Orchestrators cannot hand off work cleanly. A lead agent spawns a fixer, the fixer closes the ticket, then nobody records the fix. The next person repeats the same work.
Compliance and audit gaps appear. You cannot explain why a decision happened because the observations that led to it were never stored anywhere permanent.

That list will only get worse as agents run production workflows at night while nobody watches. The fix is putting a memory layer under every agent the same way we put databases under web apps fifteen years ago.

What stateful means for OpenClaw builders

Stateful does not mean dumping every conversation into a vector store. For us it means three concrete capabilities:

Durable recall: Every important observation lands in MemoClaw via memoclaw store or store --batch. Those memories sit outside the model context so they survive restarts.
Scoped replay: You pull back only what matters using namespaces and tags. Preference memories live in customer-profile. Incident write ups live in postmortems. Session summaries go into sessions. Recalls target one namespace at a time so results stay sharp.
Programmable importance: The agent scores every new detail between 0 and 1. Low score means skip storing. High score means pin it so future recalls see it first. MemoClaw exposes this through the --importance flag on every store endpoint.

When you wire those three ideas into the event loop you get an agent that behaves like a staff engineer who keeps notebooks instead of a goldfish that resets every five minutes.

Architecture blueprint: OpenClaw skill plus MemoClaw

A minimal stateful stack fits on one slide:

Wallet identity: Fund a Base wallet once. OpenClaw skills sign requests with that wallet so every agent you spawn inherits the same memory account and can share context without re stuffing prompts.
Namespaces for roles: Create namespaces such as support, sales-handovers, deployments, and learning. Namespaces are cheap, so use them to isolate recall scopes.
Importance gating: Add a small scoring rubric to your system prompt. When the agent observes something, have it emit memory_score. Only call memoclaw store when the score clears 0.6 or whatever threshold fits the role.
Tag taxonomy: Tags are the surgical tool. Tag customer tickets with customer:acme and tier:enterprise. Tag infrastructure items with service:api. Those tags become filters.
Recall hooks: Before answering anything that reaches across sessions, run memoclaw recall --query ... --namespace ... --tags .... Inject the retrieved snippets into your plan stage, not the final response stage, so the agent has time to reason over the memory.

MemoClaw handles semantic ranking, dedupe, and storage limits behind the scenes. You keep the flow above consistent and you get stateful behavior without building a new database.

Operational patterns

You do not need a neural architecture diagram. You need a few boring loops that never miss.

Proactive storage

Run memoclaw store right after a high importance observation. Do not wait until the end of the session. The process might crash before then.
Use store --batch at the end of an onboarding flow so you drop a hundred structured facts for $0.04 instead of paying per record.
Keep namespaces tidy. If a memory spans two surfaces, store it twice with different tags instead of inventing complex schemas.

Intentional recall

Recall early in your tool plan. For example, a fixer agent can recall --namespace incidents --tags incident:913,status:open before touching the keyboard.
Combine text queries with tags when you need precision. memoclaw recall --query "monorepo rollout" --tags customer:apollo --namespace support fetches only the relevant slice.
Cache the last recall per namespace for five minutes so you do not hammer the API when loops repeat.

Consolidation and hygiene

Schedule a cron agent to run memoclaw consolidate --namespace support --tags customer:acme each night. That merges redundant notes.
Use memoclaw list --namespace support --limit 100 weekly to spot stale data.
Delete poison memories immediately via memoclaw delete <id> or bulk-delete --ids. Do not leave bad context lying around.

Five minute implementation guide

You can take an empty OpenClaw workspace and reach a stateful agent in one sitting.

Install the skill. clawhub install memoclaw or npm install -g memoclaw for the CLI. Verify with memoclaw --help.
Fund the wallet. Send a few USDC to your Base wallet. One store call costs $0.005 so ten bucks covers thousands of writes.
Create namespaces. You do not pre register them. Just pick names and start writing. Example: memoclaw store "Namespace seed" --namespace support.
Drop the scoring rubric into your agent. Example snippet: If observation should be remembered assign memory_score 0 to 1, else null.
Hook storage. In your OpenClaw workflow, after the agent outputs an action with memory_score >= 0.6, run:

memoclaw store "Ticket 1387: customer cannot sync Neon" \
  --namespace support \
  --tags customer:orbit,topic:sync,status:open \
  --importance 0.78

Hook recall. Add a planning step that runs:

MEMORIES=$(memoclaw recall --namespace support --tags customer:orbit --limit 5 --json)

Parse the JSON, inject the relevant snippets into the agent context, and continue the loop.

Expose stats. memoclaw stats --namespace support gives you counts per day. Alert when storage volume spikes or falls to zero.

Instrumentation and guardrails

Persistent memory is only useful if you can trust it.

Importance thresholds: Log every memory below your cutoff along with the reason it was rejected. If agents keep producing low score items, tighten the rubric.
Tag watchlists: Build a small checker that alerts when a memory is stored without required tags like customer or namespace. Garbage tagging kills recall quality.
Spend tracking: MemoClaw charges only for operations that hit OpenAI. Run memoclaw stats --json --namespace support | jq -r '.spend.usd' (or call /v1/stats?namespace=support with the x-wallet-auth header) to pull daily cost per namespace so Finance is never surprised.
Immutable rules: Some facts, like compliance mandates, should never be edited. Store them with --immutable and audit that flag weekly.
Export for audits: memoclaw export --namespace support --since 2026-03-01 produces a zipped JSON you can hand to auditors or use for offline analysis.

Case study: A 24 hour support pod

A real customer support pod runs the following pattern:

Intake agent tags every new conversation with customer, product, and urgency, then stores the summary with 0.7 importance.
Fixer agent recalls on customer:<slug> and status:open. It sees the intake summary plus the last three fixes for that customer before proposing a solution.
Verifier agent stores the final resolution with status:closed and a link to the main ticket.
Nightly maintenance agent consolidates duplicate summaries, runs stats, and posts a memo showing how many memories each customer generated. That number maps directly to support load.

The pod went from repeating fixes every week to self serving within two days because each worker stopped re learning context.

Rollout checklist for production teams

Map every agent role to a namespace on paper before writing code.
List the exact observations each role should store. If it is not on the list, do not store it.
Define the scoring rubric and thresholds per role. Support intake might store at 0.6 while finance automation needs 0.8.
Decide who reviews the memory feed. A human weekly review keeps quality high.
Wire spending alerts on top of memoclaw stats --json --namespace support | jq -r '.spend.usd' (or hit /v1/stats directly) and push the result into Slack so cost surprises show up fast.
Script exports. Drop nightly exports into object storage so you always have an immutable audit trail.
Drill recovery. Kill an agent mid flow and confirm the replacement agent can finish the task from stored context.

Common pitfalls to watch

Tag sprawl: When every agent invents new tags on the fly, recall becomes random. Publish a YAML file with approved tags and validate against it before storing.
Unbounded namespaces: Putting every memory into default turns recall into noise. Create small namespaces and archive old ones with export plus bulk-delete.
Late recalls: If you recall after the agent already committed to an action, it is too late. Move recall to the start of the planning step.
Missing de duplication: Run memoclaw consolidate or list to spot duplicates. If two memories carry the same payload, delete one so semantic search stays sharp.
Ignoring failures: Treat failed API calls like failed database writes. Log them, retry with backoff, and surface metrics so you know when Base RPC hiccups are hurting memory.

FAQ

How is this different from RAG? Retrieval augmented generation feeds documents into the prompt for a single answer. MemoClaw stores granular memories with tags, importance, and namespaces, so you can build running histories per customer or task. It complements RAG but solves a different problem.

Do I have to write backend code? No. The CLI and OpenClaw skill expose the same API. Most teams start with shell commands and graduate to SDKs only when they need automation at scale.

What about private data? MemoClaw is not for secrets. Do not store API keys or passwords. Store summaries, decisions, and preferences. The service runs on Neon Postgres with pgvector, and every request is scoped to your wallet.

How much does this cost? You get 100 free calls per wallet. After that, storing or recalling a single memory costs $0.005. Batch storage is $0.04 for up to 100 records. Listing, deleting, and stats are free.

Can multiple agents share the same memory? Yes. As long as they sign with the same wallet they see the same namespaces. Use namespaces and tags to prevent cross contamination when roles vary.

Conclusion

Stateful agents are not hype. They are the only way an OpenClaw deployment survives more than one shift without human babysitting. MemoClaw gives you the persistence layer, wallet identity, semantic recall, and cost controls out of the box. Start with a single namespace, wire in the scoring rubric, and insist that every agent store what it learns. Within a week you will have fewer repeat incidents, faster handoffs, and a memory log you can audit. Bigger prompts will never deliver that.

Agent memory on a budget: stretch MemoClaw's free tier before you swipe

Ana Julia Bittencourt — Wed, 18 Mar 2026 23:31:57 +0000

Agent memory on a budget: stretch MemoClaw's free tier before you swipe

You only get 100 paid operations before MemoClaw asks you for USDC. That sounds tight until you realize most maintenance endpoints cost nothing. If you're prototyping an OpenClaw agent, you can run for weeks on the free tier by being intentional about what hits the embeddings pipeline. MemoClaw also lives outside your prompt window. Park a memory here and it's one less token block stuffed into context, which keeps long-running builds fast and cheap.

Know which calls burn credits

MemoClaw only charges when it has to embed or run GPT-4o-mini. Everything else is free. Keep this table taped next to your console:

Operation	Endpoint	Cost	Notes
Store single memory	`memoclaw store`	$0.005	Paid - uses embeddings
Store batch (≤100)	`memoclaw store --batch`	$0.04	Paid - cheapest way to import onboarding data
Recall / semantic search	`memoclaw recall`	$0.005	Paid - every recall pulls semantic vectors
Context / consolidate / migrate	respective endpoints	$0.01	Paid - GPT-4o-mini + embeddings
List / get / delete / search (text)	`memoclaw list	get	delete
Stats / export / history / namespaces	{% raw %}`memoclaw stats	export	history

If an operation doesn't mention embeddings, assume it's free. Most builders still call {% raw %}store on every message instead of batching the boring stuff. Use the free APIs to audit what already exists. Lean on list/export endpoints to keep a semantic search index ready for the next session. Your context window stays empty in the process.

A frugal memory architecture

user inbox -> session summarizer (free) -> batch payload builder -> memoclaw store --batch
                    |                                       ^
                    v                                       |
             memo audit cron --------------> memoclaw stats/export (free)

Session summarizer: Run your OpenClaw agent's end-of-turn summary locally. Only the final summary hits MemoClaw, not the entire transcript.
Batch payload builder: Accumulate low-importance notes until you have ~50 entries, then call store --batch. That's $0.0008 per memory instead of $0.005.
Memo audit cron: Run a nightly cron that calls the free stats and export endpoints to check growth. Dedupe locally and delete junk without spending anything.

This setup burns maybe two paid calls per day: one batch store, one recall for high-signal context. Everything else rides free endpoints. Your agents still get semantic search across yesterday's work the moment they boot.

Playbook to stay under 100 calls

Gate recalls: Cache the last recall result in your agent process. Only hit recall when the cache is empty or stale.
Prefer keyword search first: memoclaw search "deployment" --tags infra is free. Only escalate to semantic recall if the keyword pass fails.
Use importance scores aggressively: Drop importance to 0.2 for low-stakes memories so they rarely surface. Fewer recalls = fewer paid calls.
Batch migrations: When importing old MEMORY.md files, chunk them into 100-line batches and pay $0.04 once instead of $0.005 × N.
Pin reusable knowledge: Pinning doesn't cost extra but saves future recalls. Pinned items rise to the top, so one paid recall often carries the whole response.
Share a wallet for sub-agents: Scout, fixer, and orchestrator patterns all hit the same namespace for free list/export calls. Multi-agent teams get shared persistence without multiplying costs.

When the wallet swipe is worth it

You should start paying when any of these show up:

Team handoffs: Multiple OpenClaw agents sharing one wallet are hammering recall all day. Pay for the reliability and stop rationing calls.
High-importance automations: If a recall miss means a production incident, $0.005 is pocket change.
Continuous ingestion: Background workers streaming tickets or metrics should just live on the paid tier to avoid batching delays.

You still dodge the context-tax no matter what tier you're on. That's why even paid recalls feel cheap compared to stuffing 20k tokens of MEMORY.md into every prompt. MemoClaw handles persistence; you decide when the embeddings bill is worth it.

Until then, design around the free endpoints. MemoClaw's pricing is transparent. If you burn credits, it's because you chose to. Keep recalls intentional, batch the boring stores, and the 100 free calls will last longer than your prototype's runway.

Memory-first agent design: store before you beg for context

Ana Julia Bittencourt — Wed, 18 Mar 2026 23:31:06 +0000

Memory-first agent design: store before you beg for context

Most agents wait until they're stuck to ask for context. By then it's too late. Store aggressively up front and recall only when you're sure the answer isn't already pinned. MemoClaw holds that context outside the prompt window, so you aren't shoving yesterday's notes into every request.

Two extremes (and why neither works alone)

Store-everything school. Every user message, tool output, and summary gets pushed into MemoClaw with store. You never miss data, but you blow through paid calls and bury the good stuff under throwaway chatter.

Recall-on-demand school. The agent keeps a clean store but calls recall constantly, even for facts it just learned. You save on storage but pay in latency and L2 fees.

Great agents mix both. They store high-signal insights proactively, recall the rest on demand, and lean on semantic filters so only the right slice gets replayed across sessions.

Hybrid blueprint: score first, store second

OpenClaw skill -> signal scorer ->
    if score >= 0.6 --> memoclaw store --importance <score>
    else --> pass
                      \
                       -> recall cache (TTL 5 min) -> memoclaw recall

Signal scorer: Drop a tiny classifier in your system prompt. When the agent observes something, it outputs memory_score between 0 and 1.
Store pipeline: Only call memoclaw store when the score clears a bar (0.6 for user preferences, 0.8 for production facts). Tag aggressively so later recalls can filter by --tags user-profile or --tags infra. Keep namespaces scoped so cross-session fetches stay clean.
Recall cache: Keep a short-lived cache per namespace. If a question matches the last recall tags, reuse that payload before hitting MemoClaw.

Practical example: onboarding a new customer

First call: User says "I deploy everything to fly.io". Score = 0.85, so you store:

memoclaw store "Customer ACME deploys to fly.io, needs ARM images" \
  --importance 0.85 \
  --tags customer:acme,deployments \
  --namespace onboarding

Later task: Agent needs deployment context. It runs memoclaw recall --query "Where does ACME deploy?" --tags customer:acme once, caches the answer, and reuses it for the rest of the session.
Noise: User asks "what's the Wi-Fi password?" Score = 0.1, so you don't store it. If it matters later, the agent can ask again.

Checklist for shipping memory-first agents

Define namespaces per workflow (sales, support, ops).
Teach your agent to emit an importance score with every observation.
Batch low-score notes nightly. That keeps the store lean and prevents context window waste.
Gate every recall behind a cheap keyword search first.
Run memoclaw stats --namespace support daily so you spot drift before it pollutes future recalls. Lean on semantic recall to pull only what matters for each new session.

When you design storage rules before shipping, your agent stops hoarding junk yet still remembers the vital stuff across sessions. MemoClaw's importance scoring plus OpenClaw's tool hooks make this hybrid trivial - you just have to wire it in.

One wallet, many agents, one brain

Ana Julia Bittencourt — Wed, 18 Mar 2026 23:31:00 +0000

One wallet, many agents, one brain

Spawning sub-agents in OpenClaw is easy. Getting them to share what they learn is the annoying part. MemoClaw ties memory to your wallet, so any agent that signs with that wallet writes to the same space. Scouts can drop discoveries, fixers can log outcomes, and the lead agent recalls it all without syncing files or stuffing prompts.

Multi-agent wiring diagram

scout agent (wallet W) ---- store --> MemoClaw namespace:research
                       \
fixer agent (wallet W) ---- store --> MemoClaw namespace:fixes
                         \
 orchestrator (wallet W) -- recall --> research + fixes

Scout: Crawls docs, summarizes findings, and stores them with tags like source:docs or topic:auth.
Fixer: Closes incidents, then logs results with tags such as incident:123 or status:done.
Lead agent: Runs memoclaw recall --tags topic:auth --namespace research before assigning more work, so it reuses what the scout already wrote.

Because the wallet is the identity, setup ends after you fund the same x402 address. Everyone shares the same semantic memory and you never bolt on a side database.

Implementation steps

Fund the wallet once. One Base wallet covers the lead agent and every child agent. No keys to rotate.
Name your spaces. Give each sub-agent a namespace such as research, fixes, or handoff so recalls stay targeted.
Agree on tags. Use tags like incident:<id> or customer:<slug> so every recall filter is predictable.
Batch the scout's notes. Let the scout buffer each doc, then call store --batch to cut paid calls.
Recall with filters. The lead agent can merge namespaces on the fly: memoclaw recall --query "latest auth changes" --namespaces research,fixes.

Example handoff flow

Scout finishes crawling the docs and writes:

memoclaw store "Auth callback now requires PKCE for partners" \
  --tags topic:auth,release:2026-03,source:docs \
  --namespace research \
  --importance 0.7

Lead agent spins up a fixer. Before writing a script, it fetches the scout's findings:

memoclaw recall --query "auth partner changes" --namespace research --tags topic:auth

Fixer ships the change and locks the outcome for future shifts:

memoclaw store "PKCE enforcement shipped to staging" \
  --tags incident:482,status:done \
  --namespace fixes \
  --importance 0.6

No message bus, no shared database, and no exploding prompt windows. The wallet binds every agent together. MemoClaw stores the collective brain, and OpenClaw's spawn API just works. Once you try it, you'll never go back to emailing JSON between agents.

Namespace strategies for multi-project OpenClaw agents

Ana Julia Bittencourt — Wed, 18 Mar 2026 12:49:14 +0000

When you first start using MemoClaw, you throw everything into the default namespace. Preferences, project notes, random facts your human mentioned once. It works.

Then you add a second project. Then a third. Then you realize your agent is recalling deployment notes for Project A while you're asking about Project B, and the context is wrong in ways that are hard to debug.

Namespaces fix this. They're isolated memory spaces within your MemoClaw account. Memories in one namespace can't leak into another. Same wallet, completely separate recall.

The question isn't whether to use them. It's how to structure them so they actually help instead of creating a different kind of mess.

What namespaces actually do

A namespace is just a label that isolates a group of memories. When your agent calls memoclaw recall, it searches within a single namespace. No cross-namespace results unless you explicitly query multiple.

# Store to a specific namespace
memoclaw store "Uses Railway for deploys" --namespace content-engine

# Recall from that namespace only
memoclaw recall "deployment setup" --namespace content-engine

If you don't specify a namespace, everything goes to default. Fine for simple setups, noisy fast.

There's no extra cost for namespaces. You can have as many as you want. Namespaces are just metadata on each memory, so the only cost is the store/recall calls themselves.

One namespace per project

The most common pattern. Each codebase or project gets its own namespace.

default          → personal preferences, general knowledge
content-engine   → blog workflow, content pipeline details
trading-bot      → exchange APIs, risk parameters
home-automation  → device names, room layouts, routines

This works well when you have 2-5 distinct projects and your agent switches between them in different conversations.

Where it breaks: overlapping projects. Maybe your content-engine deploys the same way as your trading-bot. Storing "Uses Railway" in both namespaces means maintaining the same fact in two places. It'll drift.

Fix: keep shared infrastructure knowledge in default and project-specific details in their namespaces. Your agent queries default first, then the project namespace.

Shared + project namespaces

A refinement of the above. You explicitly separate shared context from project-specific context.

shared           → deployment patterns, coding standards, tool preferences
project-alpha    → project-specific architecture, team contacts
project-beta     → different stack, different team
personal         → human preferences, communication style, schedule

Your agent's recall flow becomes:

Always recall from personal (preferences affect every interaction)
Always recall from shared (common tools and patterns)
Recall from the active project namespace

This costs more calls per interaction, up to 3 recalls instead of 1. Each recall is $0.005, so three per interaction is $0.015. Still cheap. Context quality goes up noticeably.

You can bake this directly into your agent config:

## Memory recall pattern

For every task:
1. Recall from "personal" namespace for communication preferences
2. Recall from "shared" namespace for general technical context
3. Identify the active project and recall from its namespace

Client-based namespaces

If you're freelancing or consulting, organize by client instead of project.

client-acme      → Acme Corp preferences, contacts, project history
client-initech   → Initech codebase details, meeting notes
internal         → your own projects and preferences

Client contexts rarely overlap, so this gives you clean separation without much discipline required.

One thing to watch: when you stop working with a client, their namespace still exists. Export it with memoclaw export --namespace client-acme (free endpoint) and then bulk delete if you want to clean up.

Environment-based namespaces

For agents that behave differently depending on context.

work             → professional communication style, work projects
personal         → casual tone, personal projects, home stuff
discord-server   → community context, member names, channel purposes

Less about data separation, more about behavioral context. Your agent recalls from work and gets "Keep responses professional, use formal language." Recalls from personal and gets "Be casual, use humor."

Some people combine this with project namespaces using a convention like work/project-alpha as the namespace name. MemoClaw doesn't enforce hierarchy in names, but the slash convention keeps things readable in the CLI output.

When to skip namespaces

If your agent does one thing, for one person, on one project, a single namespace with good tags might be enough.

memoclaw store "Deploy command: railway up" --tags infra,deploy
memoclaw store "Human prefers dark mode" --tags preferences,ui
memoclaw recall "how do we deploy" --tags infra

Tags filter within a namespace. They're lighter-weight than namespaces and don't require deciding which namespace to query.

Rule of thumb: under 200 memories and one main project, tags are enough. Over 200 or multiple distinct contexts, add namespaces.

Naming conventions

Your agent constructs these strings programmatically, so predictability matters.

Good:

content-engine
trading-bot
client-acme

Avoid:

Content Engine
my_trading_bot_v2
ACME Corp Client (2026)

Lowercase, kebab-case. No spaces, no special characters.

Migrating between namespace strategies

Already have memories in the wrong namespaces? Here's the approach:

Export the old namespace:

   memoclaw export --namespace old-name > backup.json

Export is free.

Re-store in the new namespace. There's no "move" command. You'll need to store the memories again. Use batch store for up to 100 at once ($0.04) to keep costs down.
Delete from the old namespace:

   memoclaw bulk-delete --namespace old-name

Bulk delete is also free.

It's manual, but namespace restructuring is a one-time thing. Better to do it once than live with a confusing structure.

Multi-agent namespaces

If multiple agents share the same wallet, they share access to all namespaces. You can use this intentionally.

Three agents: coding agent, review agent, documentation agent. Same wallet, different namespaces:

code-context     → coding agent stores architectural decisions
review-notes     → review agent stores patterns and issues found
docs-context     → docs agent stores style guides and terminology
shared           → all agents read from here for project-wide context

Each agent writes to its own namespace and reads from shared plus its own. The coding agent doesn't get confused by documentation style notes. The docs agent doesn't see low-level implementation details.

To share something across all agents, any of them can store to shared:

memoclaw store "Project switched from REST to GraphQL as of March 2026" \
  --namespace shared --importance 0.8 --tags architecture

All three agents pick this up on their next recall from shared.

What to actually do

For most OpenClaw users:

Start with default namespace and tags
When you add a second project that's clearly separate, create a namespace for it
Move personal preferences to a personal namespace so they're always available regardless of project
Don't create namespaces preemptively. Create them when you feel the pain of mixed context

The goal is less noise in recall, not a perfect taxonomy. Keep it practical.

Checking what you've got

A few free endpoints for namespace management:

# List all your namespaces
memoclaw namespaces

# See memory count and stats
memoclaw stats

# List memories in a specific namespace
memoclaw list --namespace content-engine

# Export everything for backup
memoclaw export --namespace content-engine > backup.json

All free. No embeddings, no cost against your 100 free-tier calls.

Start simple, add structure when you need it, use the free endpoints to keep track of what's where.