AgentPrizm Memory

You have persistent memory. AgentPrizm is the memory of record for AI agents — a
semantic, long-term store that survives across sessions, projects, and machines. It is
wired in as the agentprizm-memory MCP server. Use it so you stop relearning what you
already know.

These are the tools you have (all via the agentprizm-memory server):

Least privilege by default. The recommended install scopes this server to the 8
memory_* tools only (--include "memory_*"), which is all a memory skill needs. The
AgentPrizm server can also serve 14 skill_* AgentSkills-marketplace tools (search,
install, fork, publish, …), but those are an explicit opt-in — wire the server
without the --include filter only when you actually want the full AgentPrizm surface,
not just memory. Keep the default unless you specifically need marketplace access.

When to RECALL (read before you act)

Before you start real work, check memory first. Recall is fast and the cost of
missing prior context is high (you repeat mistakes, contradict past decisions, re-ask
the user). Recall when:

• Starting a task or a new session → call memory_bootstrap once to load standing
  context, or memory_recall scoped to the task.
• Before answering a question that depends on the user, their stack, their
  customers, or past decisions → memory_recall with the question as the query.
• Before writing or changing code → recall conventions, prior architecture
  decisions, gotchas, and lessons for this container.
• Before contacting or referencing a person → recall their contact memory.

Every recall returns a receipt — treat it as your evidence. Each memory carries a
confidence (0–1) and a why block (including validityState) showing how strongly
and why it matched; lean harder on high-confidence, active memories and verify the
rest. When you act on a recalled memory, ground your reasoning in it rather than
guessing. If recall returns nothing relevant, say so and proceed; don't fabricate prior
context.

When to STORE (write what's durable)

After you learn something that will still be true and useful in a future session,
store it with memory_create. Store the why and the gotcha, not the obvious. Good
triggers:

• A durable fact about the user, system, or domain is established.
• The user states a preference or corrects your approach.
• You hit a lesson — a non-obvious bug, root cause, or "do it this way" insight.
• A decision / rule is made that should constrain future work (a directive).
• You meet a contact worth remembering (name + role + why they matter).
• A useful bookmark (URL + what it's for) comes up.

Do not store: things re-derivable in seconds from the code or git log,
session-only scratch context, exact line numbers / code snippets that churn, or anything
in the project's own docs.

Choosing the memory type

Scoping with containers

Containers keep memory from bleeding between unrelated work. Scope every write and
read to the right container:

• Use AGENTPRIZM_CONTAINER (if set) as the default scope.
• Otherwise pick a stable slug for the user / team / customer / environment / agent
  you're working on behalf of (e.g. acme-corp, client-x/staging).
• Put cross-cutting, stack-independent knowledge (general user preferences, universal
  lessons) in a shared global container, but bias toward project-scoped — global is
  for things a different project would genuinely benefit from.
• On recall, search the current container and global together when you want
  standing preferences plus task context.

Validity windows for time-sensitive facts

For anything that's only true for a while, set a validity window when you create it
(validFrom / validUntil) instead of storing it as a permanent fact. Examples:
"on-call rotation X until end of quarter", "feature flag Y enabled during the
migration". This lets the fact expire instead of misleading a future session. Add a
confidence when you're unsure. When something is flat-out wrong or superseded, prefer
memory_forget over leaving stale data.

Expired facts are excluded from recall by default, so a stale window won't leak into a
future session. If your job is specifically to review or refresh stale facts, recall
with includeExpired: true and check each result's why.validityState.

Never store secrets

Do not write API keys, tokens, passwords, private keys, or other credentials into
memory. Store the fact that a secret exists and where it lives, never the value.

Worked example

> User: "Set up the deploy script for the billing service."

1. Recall first. memory_recall (container: acme-billing, query: "deploy
   script conventions billing") → returns a receipt: directive "Deploys go through
   webhook-deploy.sh; never git push to prod directly" and a lesson "typecheck
   must run before deploy or you ship a 1-deploy-lag bug."
2. Act on it. Write the script to call webhook-deploy.sh and gate on typecheck —
   grounded in the recalled memories, not guesswork.
3. Store what's new. The user mentions deploys must run only after 6pm UTC.
   memory_create → type directive, container acme-billing, content "Billing
   deploys only after 18:00 UTC (low-traffic window)." If it's only for this migration,
   add validUntil.

That's the loop: recall before you act, store what's durable, scope it, let
time-bound facts expire.