Agent Memory

Persistent semantic memory for agents, with project, team, and repo scopes when the memory should outlive one session, one user, or one model. Store facts, decisions, and preferences with evidence links, lifecycle controls, and automatic relevance-based recall.

Overview

Agent Memory enables your AI agents to persist information across sessions. Unlike conversation history (which is ephemeral), memories are stored server-side and can be recalled semantically based on relevance to the current context. Unlike personal-memory tools alone, Snipara can keep the same reviewed memory at project, team, and repo scope so future agents inherit approved engineering context instead of rediscovering it.

The strongest coding-agent setups use both layers together: execution memory keeps the agent aligned with its workflow state and recent runtime trace, while reviewed memory prevents it from reopening settled engineering decisions.

When an agent needs that operational layer in one hosted fetch, use snipara_resume_context. It packages execution-memory with latest handoff, What Changed, active decisions, and an optional task-scoped work brief instead of exposing execution-memory alone.

Mem0 vs Snipara

If you only need personal or per-agent memory, Mem0 is the closer comparison. Snipara can also store agent and user-scoped memory, but its differentiator for coding teams is governed project, team, and repo memory with evidence, review, invalidation, and lifecycle control.

In short: Mem0 is usually where you keep what one agent or one user should remember. Snipara is where you keep what the project should keep teaching every future agent.

GitHub to Durable Recall

Coding-agent memory should not jump straight from a pull request to a permanent recall. Snipara treats GitHub as evidence first, then promotes selected repo truth into durable memory only after governance and lifecycle checks.

Memory Scope Policy

Choose the narrowest durable owner before writing memory. Raw specs, RFPs, diagrams, and client files stay in context; memory stores compact decisions, preferences, learnings, and reusable state.

Snipara stores agent memory on the reviewed memory model by default. Agent, project, team, and user scopes are owner boundaries, not labels: agent memories require an agent identifier, user memories stay personal to one authenticated or integrator-mapped user, team memories stay with the team, and project memories stay with the active project.

Key Features

• Semantic Storage — Memories are embedded for similarity search
• Source-Linked Evidence — Attach docs, chunks, PRs, issues, and URLs to critical memories
• Lifecycle Controls — Invalidate or supersede stale memories through hosted MCP or companion without losing history
• Verification — Re-check whether a memory is still backed by valid evidence
• Review Queue — Route automated memory writes to an inbox before recall
• Transcript Import — Bootstrap durable memory from transcripts or notes
• Automation-Safe Capture — Use novelty checks and task commits instead of raw note dumping
• Confidence Decay — Memories lose relevance over time unless reinforced
• Type Classification — Categorize as facts, preferences, decisions, etc.
• TTL Support — Set expiration times for temporary memories
• Metadata Filtering — Filter recalls by type, category, or custom tags

Capture & Review Flow

Not every memory should become durable immediately. Snipara supports a reviewable workflow so teams can automate capture without polluting future recalls.

The dashboard memory page also supports Import Transcript, which previews durable candidates from a session transcript or retrospective and imports them into the review inbox.

For local human resolution, use snipara-companion Decision Requests: workflow decisions lists pending questions, workflow decide records the reviewer receipt, and memory reviews --emit-decisions turns hosted memory review candidates into the same review channel.

GitHub Evidence Memory

GitHub can become memory only through a governed path. Snipara first treats repository artifacts as evidence: issues, pull requests, review comments, commits, Actions summaries, and linked files keep their GitHub URLs, SHAs, paths, and line numbers where available.

The next layer proposes selected evidence as memory candidates. Those candidates keep source links, risk flags, confidence, and suggested TTLs. They are not durable recall material until policy or a reviewer approves them.

Before and After: one sourced memory prevents the wrong edit

The value is not abstract. A reviewed memory can stop an agent from repeating a stale repo assumption before it edits the wrong file or reopens a closed decision.

MCP Tools

snipara_remember

Store a new memory with optional metadata.

snipara_remember({

  text: "User prefers dark mode in all applications",

  type: "preference",

  category: "ui",

  scope: "project",

  ttl_days: null  // null = permanent

})

Parameters

snipara_remember_if_novel

Store a memory only if it is sufficiently different from existing memories. This is the safest write path for automation and commit hooks.

snipara_remember_if_novel({

  text: "Use Vaultbrix SSH before rolling out Prisma-backed backend releases",

  type: "decision",

  category: "deploy",

  novelty_threshold: 0.92

})

Typical use: commit hooks, session summaries, and workflow automations that should skip near-duplicate memories.

snipara_remember_bulk

Store multiple memories in a single call for efficient batch operations.

snipara_remember_bulk({

  memories: [

    { text: "User prefers TypeScript", type: "preference" },

    { text: "API uses JWT auth", type: "fact", category: "auth" },

    { text: "Deploy to staging first", type: "decision", ttl_days: 30 }

  ]

})

Parameters

Response

{

  "stored": 3,

  "memory_ids": ["mem_abc", "mem_def", "mem_ghi"],

  "message": "Stored 3 memories"

}

snipara_end_of_task_commit

Persist durable outcomes from a task summary. This is the workflow-oriented memory entry point for automation and handoff flows.

snipara_end_of_task_commit({

  summary: "Completed the memory inbox UI and left deployment validation as the next step.",

  outcome: "partial",

  persist_types: ["decision", "learning", "workflow"],

  files_touched: ["apps/web/src/app/(dashboard)/dashboard/agents/memory/page.tsx"]

})

Use this when you want Snipara to extract only durable outcomes from a task summary instead of storing the raw narrative as-is.

snipara_recall

Retrieve memories relevant to a query using semantic search.

Use snipara_recall for durable decisions, learnings, preferences, and carryover. Do not use it as a substitute for source documents. For specs, PDFs, client files, and shared playbooks, start with Project Intelligence Inputs and use snipara_context_query or snipara_shared_context.

On projects where Outcome Loop recall reranking is enabled, recall may include an outcome_loop_rerank block and per-memory outcome_evidence. That ranking signal is based on sample-aware OutcomeStats posterior evidence, not raw Memory.evidenceScore. It is a gated memory recall treatment. Context/chunk retrieval uses a separate opt-in outcome rerank path backed by persisted OutcomeEvidenceStats for chunk targets, live fallback for missing stats, bounded boost-only movement, and a top-relevance exploration floor.

snipara_recall({

  query: "What are the user's UI preferences?",

  limit: 5,

  type: "preference",

  min_relevance: 0.5

})

Parameters

Response

{

  "memories": [

    {

      "id": "mem_abc123",

      "content": "User prefers dark mode in all applications",

      "type": "preference",

      "category": "ui",

      "confidence": 0.92,

      "relevance": 0.87,

      "createdAt": "2025-01-20T10:30:00Z",

      "lastAccessedAt": "2025-01-23T14:15:00Z",

      "status": "ACTIVE",

      "freshness": "fresh",

      "evidence_count": 2

    }

  ],

  "total": 1

}

Confidence values in recall responses are ranking and lifecycle signals, not calibrated advisor-grade probability claims.

snipara_memories

List all memories with optional filters (no semantic search).

snipara_memories({

  type: "decision",

  limit: 20,

  offset: 0

})

snipara_forget

Delete specific memories by ID or filter.

// Delete by ID

snipara_forget({ memory_id: "mem_abc123" })

// Delete all memories of a type

snipara_forget({ type: "todo" })

Memory Lifecycle Tools

Use reviewed memory lifecycle tools when you need memory that can be traced back to evidence and updated safely over time instead of being hard-deleted.

snipara_memory_attach_source

Attach evidence to a memory, such as a document chunk, PR, issue, commit, or URL.

snipara_memory_attach_source({

  memory_id: "mem_abc123",

  evidence_type: "CHUNK",

  chunk_id: "chunk_456",

  snippet: "OAuth callback validates state before token exchange",

  weight: 1.0

})

Use this for fact, decision, and learning memories that should stay grounded in project evidence.

snipara_get_chunk

Retrieve the full content for a referenced chunk when you need to inspect the exact source behind a memory or a query result.

snipara_get_chunk({

  chunk_id: "chunk_456"

})

snipara_memory_verify

Verify whether a memory still has valid supporting evidence.

snipara_memory_verify({

  memory_id: "mem_abc123",

  mark_stale_if_missing: true

})

{

  "memory_id": "mem_v2_abc123",

  "verified": true,

  "total_evidence": 2,

  "valid_evidence": 2,

  "invalid_evidence": 0,

  "evidence_score": 1.0,

  "status": "ACTIVE"

}

snipara_memory_invalidate

Mark a memory as invalid when it is no longer true. This preserves the audit trail better than deleting it outright.

snipara_memory_invalidate({

  memory_id: "mem_abc123",

  invalidated_at: "2026-04-10T14:30:00Z",

  reason: "Legacy OAuth flow replaced by PKCE-only flow"

})

snipara_memory_supersede

Replace an outdated memory with a newer one while keeping the relationship explicit.

snipara_memory_supersede({

  old_memory_id: "mem_old_auth",

  new_memory_id: "mem_new_auth",

  reason: "Authorization server configuration changed"

})

From a terminal workflow, the companion equivalents are snipara-companion memory invalidate <memory-id> and snipara-companion memory supersede <old-memory-id> <new-memory-id>. These commands call the hosted lifecycle tools and keep mutation separate from read-only hygiene commands such as memory audit and memory compact.

Memory Hygiene Tools

Memory hygiene tools help teams review active memory quality without deleting useful history. Use them before and after cleanup workflows, especially when automation writes memories on behalf of agents.

snipara_memory_health

Inspect active memory counts, top categories, compaction settings, and known hygiene anomalies. This tool is read-only.

snipara_memory_health({

  sample_limit: 5

})

Hygiene reasons include document upload receipts, trivial decomposition receipts, execution-plan receipts, and active categories that still contain :superseded.

snipara_memory_clean_candidates

Return a bounded review packet for cleanup. It groups candidates into noise, possible stale rows, duplicate groups, category anomalies, and memories that need human review.

snipara_memory_clean_candidates({

  limit_per_bucket: 10,

  include_low_confidence: false

})

This tool does not mutate memory. Follow up with snipara_memory_invalidate, snipara_memory_supersede, or snipara_memory_compact after reviewing the candidates.

snipara_memory_duplicate_candidates

Return duplicate and supersession candidates only, for workflows that do not need the full hygiene review packet.

snipara_memory_duplicate_candidates({

  limit: 20

})

Decision Log Tools

Use decision tools when a memory is not enough and you need a structured, ADR-style record with rationale, alternatives, and a supersession chain.

snipara_decision_create

Create a formal technical or architectural decision record.

snipara_decision_create({

  title: "Use Redis for background job deduplication",

  owner: "platform-team",

  scope: "backend",

  impact: "HIGH",

  context: "Workers need a shared dedupe layer across deploys",

  decision: "Adopt Redis SETNX-based deduplication",

  rationale: "Faster operational rollout than queue-layer rewrite",

  alternatives: ["Postgres advisory locks", "Kafka compaction"],

  tags: ["jobs", "reliability", "redis"]

})

snipara_decision_query

Search decisions by free text, scope, impact, status, or tags.

snipara_decision_query({

  query: "redis deduplication",

  scope: "backend",

  impact: "HIGH",

  include_superseded: false,

  limit: 10

})

snipara_decision_supersede

Replace an existing decision with a new one while preserving the evolution chain between both records.

snipara_decision_supersede({

  old_decision_id: "DEC-014",

  title: "Move job deduplication to queue middleware",

  owner: "platform-team",

  scope: "backend",

  impact: "HIGH",

  context: "Redis hot key pressure increased with traffic growth",

  decision: "Shift deduplication into queue middleware",

  rationale: "Reduces operational hotspots and centralizes policy"

})

Confidence Decay

Memories naturally lose confidence over time unless they are accessed or reinforced. This prevents stale information from dominating recalls.

Confidence Decay Formula

new_confidence = base_confidence * (decay_rate ^ days_since_access)

Example: 0.9 confidence, 0.98 decay rate, 7 days

0.9 * (0.98 ^ 7) = 0.77

Reinforcement

When a memory is accessed via snipara_recall, its confidence is boosted slightly. Storing the same content again also reinforces the memory.

Memory Types

Best Practices

Guidelines

• Be specific— "User prefers tabs over spaces" not "User has code style preferences"
• Use appropriate types — Helps with filtering and organization
• Set TTL for temporary info — Prevent memory bloat
• Attach evidence for critical memories — Facts and decisions should be verifiable
• Invalidate or supersede stale knowledge — Keep history instead of deleting everything
• Let confidence decay work— Don't manually set confidence to 1.0
• Recall before storing — Check if similar memory exists to reinforce instead

Current Packaging

Next Steps