Snipara
LoginStart Free

Agent Memory

Persistent semantic memory for individual agents. Store facts, decisions, and preferences with evidence links, lifecycle controls, and automatic relevance-based recall.

Available on All Plans

Agent Memory is available on all Snipara Agents plans starting at $15/month.

New in April 2026: Reviewable Memory Workflows

Agent Memory now supports review queues, transcript import, and automation-safe capture in addition to evidence links, verification, invalidation, and supersession workflows.

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.

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.

ModeWhat happens to automated writes
AUTOHook and automation writes are approved immediately and can be recalled later.
INBOXAutomated sources such as commit hooks and transcript imports become PENDING until reviewed in the dashboard.

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.

MCP Tools

rlm_remember

Store a new memory with optional metadata.

rlm_remember({
  text: "User prefers dark mode in all applications",
  type: "preference",
  category: "ui",
  scope: "project",
  ttl_days: null  // null = permanent
})

Parameters

ParameterTypeRequiredDescription
textstringYesThe memory content to store (alias: content for backward compatibility)
typestringNoClassification: "fact", "decision", "learning", "preference", "todo", "context"
categorystringNoCustom category for filtering (e.g., "auth", "ui")
scopestringNoVisibility: "agent", "project", "team", "user". Default "project"
ttl_daysnumberNoTime-to-live in days, null for permanent
document_refsstring[]NoReferenced document paths
related_tostring[]NoIDs of related memories

rlm_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.

rlm_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.

rlm_remember_bulk

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

rlm_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

ParameterTypeRequiredDescription
memoriesarrayYesArray of memory objects (max 50). Each object can have: text, type, category, scope, ttl_days

Response

{
  "stored": 3,
  "memory_ids": ["mem_abc", "mem_def", "mem_ghi"],
  "message": "Stored 3 memories"
}

Batch Efficiency

Use rlm_remember_bulk when storing 3+ memories at once. It uses batch embedding for faster processing and fewer API calls.

rlm_end_of_task_commit

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

rlm_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.

rlm_recall

Retrieve memories relevant to a query using semantic search.

rlm_recall({
  query: "What are the user's UI preferences?",
  limit: 5,
  type: "preference",
  min_relevance: 0.5
})

Parameters

ParameterTypeRequiredDescription
querystringYesNatural language query for semantic search
limitnumberNoMaximum memories to return, default 10
typestringNoFilter by memory type
categorystringNoFilter by category
min_relevancenumberNoMinimum relevance score (0-1), default 0.5
scopestringNoFilter by scope: "agent", "project", "team", "user"

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
}

rlm_memories

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

rlm_memories({
  type: "decision",
  limit: 20,
  offset: 0
})

rlm_forget

Delete specific memories by ID or filter.

// Delete by ID
rlm_forget({ memory_id: "mem_abc123" })
// Delete all memories of a type
rlm_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.

rlm_memory_attach_source

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

rlm_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.

rlm_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.

rlm_get_chunk({
  chunk_id: "chunk_456"
})

rlm_memory_verify

Verify whether a memory still has valid supporting evidence.

rlm_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"
}

rlm_memory_invalidate

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

rlm_memory_invalidate({
  memory_id: "mem_abc123",
  invalidated_at: "2026-04-10T14:30:00Z",
  reason: "Legacy OAuth flow replaced by PKCE-only flow"
})

rlm_memory_supersede

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

rlm_memory_supersede({
  old_memory_id: "mem_old_auth",
  new_memory_id: "mem_new_auth",
  reason: "Authorization server configuration changed"
})

Recommended Pattern

For durable project knowledge: rlm_remember → rlm_memory_attach_source → rlm_memory_verify. When reality changes, prefer rlm_memory_supersede or rlm_memory_invalidate over rlm_forget.

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.

rlm_decision_create

Create a formal technical or architectural decision record.

rlm_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"]
})

rlm_decision_query

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

rlm_decision_query({
  query: "redis deduplication",
  scope: "backend",
  impact: "HIGH",
  include_superseded: false,
  limit: 10
})

rlm_decision_supersede

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

rlm_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 rlm_recall, its confidence is boosted slightly. Storing the same content again also reinforces the memory.

Memory Types

TypeUse CaseExample
factObjective information"The API uses OAuth 2.0 for authentication"
preferenceUser preferences"User prefers TypeScript over JavaScript"
decisionPast decisions made"Decided to use PostgreSQL instead of MySQL"
learningLessons learned during work"The API rate limits at 100 req/min"
todoTasks and reminders"Need to add error handling to checkout flow"
contextSession context for continuity"Completed auth module, next: API endpoints"

Best Practices

Do

Store specific, actionable information that will be useful across sessions.

Don't

Store entire conversations or large code blocks — use Snipara Context for document storage.

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

PlanMax MemoriesRetentionRecall Rate
Starter1,0007 days100/hour
Pro5,00030 days500/hour
Team25,00090 days2,000/hour
EnterpriseUnlimitedUnlimitedUnlimited

Next Steps

Group Memory

Share memories across multiple agents and team members.

Multi-Agent Coordination

Build agent swarms with resource locking and task queues.