Update default prompts to suggest rich metadata (model, agent, task, topic, etc.)

[jack-arturo]

Problem

The current default prompts suggest tagging memories with project name and date, but don't mention metadata at all. This means agents store memories with almost no provenance — you can't tell which agent created a memory, what model was used, what task it was part of, or what the conversation was about.

In single-agent setups this is fine. In multi-agent setups (multiple agents writing to the same memory graph), this becomes a real problem for auditing, debugging, and trust.

Proposed Change

Update any default prompts, system prompt snippets, or documentation that describes memory structure to also recommend a standard metadata block on store_memory calls.

Suggested metadata fields (cheap to store, high value):

Field	Example	Notes
created_by	"hub-developer"	Agent name/ID that stored the memory
model	"claude-sonnet-4.6"	Model used at time of storage
task	"PR review automation"	Task or job the agent was performing
topic	"AutoHub architecture"	Conversation or research topic
session_id	"agent-abc123"	Task/session ID for traceability
source	"slack" / "whatsapp" / "code"	Where the memory originated
confidence	0.85	Already supported — make sure it's in the prompt

Metadata is cheap. The cost of over-storing provenance is negligible vs. the value of being able to audit memory origins later.

Why metadata over tags?

Tags are hard filters — adding hub-developer as a tag means queries filtering on other tags will miss those memories. Metadata is additive and doesn't affect semantic search or tag-based filtering. Provenance belongs in metadata, not tags.

Acceptance Criteria

• Default store_memory prompt examples include a metadata block
• Documentation / README updated with recommended metadata fields
• Consolidation note: when memories merge, source_agents should be a union array (not overwritten) — flag this as a known limitation until automem consolidation supports it
• Any example snippets or starter configs updated

Related

• verygoodplugins/automem: Return metadata fields in recall responses by default
• verygoodplugins/automem: End-to-end metadata audit

[coderabbitai]

🔗 Related PRs

#6 - feat: v0.8.0 - Advanced recall capabilities and MCP best practices [merged]
#23 - feat: Memory content size guidelines and warnings [merged]
#31 - Improve agent templates: avoid MCP tool prefix mismatches [merged]
#42 - chore(templates): standardize version markers and add personal namespace [merged]
#62 - feat(openclaw): add CLI installer and behavioral memory template [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[jack-arturo]

Some adjacent movement, but the core ask here isn't done yet — flagging that honestly for the 0.16.0 sweep.

What's there now: the recall/store policy tells agents to put structured details in metadata rather than cramming them into content (src/memory-policy/shared.ts), and metadata is a first-class store_memory field (including batch mode). So the general "use metadata for structured data" guidance exists.

What's still missing is exactly what this issue is about — the provenance recommendation. The default prompts don't suggest created_by, model, task, topic, session_id, or source, and there's no README table of recommended provenance fields. The consolidation source_agents-as-union-array note is also still an open limitation (today a merge would overwrite, not union).

Keeping this open. Concretely, the remaining work is:

• a small provenance metadata block in the default store_memory examples (the fields above)
• a README section documenting them
• flag the consolidation union-array behavior as a known limitation until the server supports it

Low effort, real payoff for multi-agent setups where you actually need to audit which agent/model wrote what.