Designing a Tag Taxonomy for Agent Memories

Your agent stores memories. Lots of them. But without consistent tagging, recall becomes a lottery — sometimes semantic search nails it, sometimes it returns vaguely related noise. Tags are the fix. They give your agent a structured way to filter recalls and find exactly what it needs.

The problem? Most agents tag memories inconsistently (or not at all). “preference” one day, “user-pref” the next, “prefs” the day after. Three tags that mean the same thing, none of them useful for filtering.

This guide covers how to design a tag taxonomy that actually works — naming conventions, categories, and practical patterns for OpenClaw agents using MemoClaw.

Why Tags Matter

MemoClaw’s recall endpoint accepts a tags parameter that filters results before semantic ranking. This is a precision tool:

# Without tags: searches ALL memories
memoclaw recall "what database does the user prefer"

# With tags: searches only preference memories
memoclaw recall "what database does the user prefer" --tags user-pref

The tagged recall is faster, cheaper (same cost, fewer irrelevant results), and more accurate. But it only works if your tagging is consistent.

Naming Conventions

Pick a convention and stick to it. Here’s what works:

Use kebab-case

✅ user-pref, session-summary, tech-decision
❌ userPref, SessionSummary, TECH_DECISION, user_pref

Kebab-case is readable, CLI-friendly, and won’t cause quoting issues in bash.

Be specific but not verbose

✅ user-pref
❌ preference (too vague — agent pref? user pref? project pref?)
❌ user-preference-from-conversation (too long)

Use singular nouns

✅ correction, decision, summary
❌ corrections, decisions, summaries

Prefix with domain when needed

✅ project-context, project-deadline
✅ user-pref, user-correction
❌ context (context of what?)

The Core Tag Categories

After observing patterns across many agents, these categories cover most use cases:

1. user-pref — What the user likes

Timezone, code style, communication preferences, tool preferences. Things your agent should remember across every session.

memoclaw store "User prefers TypeScript over JavaScript for all new projects" \
  --importance 0.8 --tags user-pref,tech

2. correction — Things the agent got wrong

High-value memories. When a user corrects your agent, that correction should be easy to find and hard to ignore.

memoclaw store "CORRECTION: User's company is 'Acme Corp' not 'Acme Inc'" \
  --importance 0.95 --tags correction

Pro tip: always store corrections with high importance (0.9+). They should surface in recalls even when the query isn’t directly about the correction.

3. decision — Choices that were made

Architecture decisions, tool selections, process choices. Things that explain why something is the way it is.

memoclaw store "Decided to use Postgres instead of MySQL for the analytics service" \
  --importance 0.85 --tags decision,architecture

4. summary — Condensed session or project context

Session summaries, meeting notes, project status snapshots.

memoclaw store "Session 2026-03-10: Worked on auth refactor, decided to drop OAuth1 support, user wants tests before merge" \
  --importance 0.7 --tags summary,session

5. context — Background information

Project descriptions, team structure, business context. Things that don’t change often but inform everything.

memoclaw store "The analytics service processes ~2M events/day and runs on 3 Railway instances" \
  --importance 0.6 --tags context,infrastructure

6. task — Action items and to-dos

Things that need doing. Useful for agents that track work across sessions.

memoclaw store "TODO: Update the deployment script to handle the new env variable" \
  --importance 0.7 --tags task,ops

Secondary Tags (Combine With Core Tags)

These add a second dimension of organization:

  • tech — Technical/engineering. Combine with: decision, context, user-pref
  • architecture — System design. Combine with: decision, context
  • ops — Operations/deployment. Combine with: task, decision, context
  • session — Per-session data. Combine with: summary, task
  • personal — Non-work user info. Combine with: user-pref, context
  • urgent — Time-sensitive. Combine with: task, correction

The pattern: core tag describes what type of memory, secondary tag describes what domain.

# A technical decision
--tags decision,tech

# An urgent operational task
--tags task,ops,urgent

# A personal user preference
--tags user-pref,personal

Enforcing Tags in Your Agent’s Instructions

Tags only work if your agent uses them consistently. Add tagging rules to your AGENTS.md or skill configuration:

## Memory Tagging Rules

When storing memories via MemoClaw, ALWAYS apply tags:

**Required core tag (pick one):**
- `user-pref` — user preferences and settings
- `correction` — something I got wrong (importance ≥ 0.9)
- `decision` — a choice that was made and why
- `summary` — session or project summary
- `context` — background information
- `task` — action items

**Optional secondary tags:**
- `tech`, `architecture`, `ops`, `session`, `personal`, `urgent`

**Rules:**
- Always use at least one core tag
- Use kebab-case only
- Corrections always get importance ≥ 0.9
- Session summaries include the date in content

This turns tagging from “hope the agent remembers” to “enforced by instructions.”

Filtering in Recall

Here’s where the payoff comes. With consistent tags, your agent can make targeted recalls:

# "What does the user prefer for X?"
memoclaw recall "database preference" --tags user-pref

# "What decisions did we make about the API?"
memoclaw recall "API design choices" --tags decision

# "What corrections have been made?"
memoclaw recall "previous corrections" --tags correction

# "What's still on the to-do list?"
memoclaw recall "pending tasks" --tags task

Each of these returns a focused result set instead of fishing through every memory your agent has ever stored.

Tags vs Namespaces vs Relations

Quick mental model:

  • Tags answer: “What kind of memory is this?” → correction, decision, user-pref
  • Namespaces answer: “Which project does this belong to?” → mobile-app, analytics-service
  • Relations answer: “How does this connect to other memories?” → supports, contradicts

Use all three. A well-organized memory might look like:

memoclaw store "Chose SQLite for local caching in the mobile app" \
  --importance 0.85 \
  --tags decision,architecture \
  --namespace mobile-app

Then linked via a relation to its supporting evidence. Tags, namespace, and relations each add a different axis of organization.

Common Mistakes

Too many tags: If you have 30+ unique tags, you’re defeating the purpose. Stick to 6-8 core tags and a handful of secondary ones. The taxonomy should fit in your head.

Inconsistent naming: user-preference, user-pref, preference, prefs — pick one. Document it. Enforce it.

Tagging everything important: That’s what the importance score is for. Don’t waste a tag slot on it.

No tags at all: Relying purely on semantic search works until your agent has thousands of memories and recalls start returning noise. Tags are your precision filter.

Over-engineering: You don’t need a hierarchical taxonomy with 4 levels of nesting. Flat tags with 2-tag combinations cover 95% of use cases.

Start Here

  1. Add the six core tags to your agent’s instructions
  2. Pick 2-3 secondary tags relevant to your projects
  3. Add the tagging rules to your AGENTS.md
  4. Review your agent’s memories after a week — are the tags consistent?

Good tagging is invisible when it works. Your agent just… finds what it needs, faster and more accurately. That’s the whole point.

Resources: