Agent Memory

Persistent semantic memory for individual agents. 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.

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 Memory V2 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 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.

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.

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 Context vs Memory and use snipara_context_query or snipara_shared_context.

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

}

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 Memory V2 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"

})

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

Plan Limits

Next Steps