How does Jarvis manage memory?

Jarvis (getjarvis.eu) stores memory in two layers. Short-term: every message in a conversation stays in context until the conversation ends. Long-term: a structured memory store keyed to your account holds facts the model has decided to remember — your priority contacts, project nicknames, tone profile, preferences. The memory layer uses PostgreSQL with pgvector for semantic recall. The agent runtime exposes four tools to the model — memory_store, memory_query, memory_update, memory_task_complete — that the model calls automatically when a fact is worth saving or recalling. You can review every memory entry in Settings → Memory, edit any fact, delete entries, or wipe all memory with one click. Memory is encrypted at rest with AES-256-GCM, GDPR-aligned for GDPR compliance, and never used for training. Works the same on macOS, Windows, and Linux because memory lives server-side.

Jarvis uses a layered memory architecture documented in the project's memory-architecture.html spec. (1) Working memory: the current conversation. Sent to the model on every turn so the model sees what was discussed earlier. Reset when the conversation ends. (2) Episodic memory: completed conversations stored as embeddings, retrievable via semantic search. Used when the model needs to recall "what we discussed last Tuesday about Q3 planning." (3) Semantic memory: structured facts (key-value with tags) — your CEO's email, your tone preferences, project nicknames. The most heavily used layer. (4) Procedural memory: how-to knowledge Jarvis has learned about your workflows. All four sit in PostgreSQL with pgvector for similarity search and are encrypted at rest with AES-256-GCM. GDPR-aligned for GDPR data-residency.

The model decides what's worth remembering — Jarvis doesn't ask you to manually save facts. The runtime exposes memory_store as a tool the model can call. Example: you say "my CEO is Jeff, his email is [email protected] — please prioritize his threads." The model recognizes this as a durable fact and calls memory_store({key: 'ceo', value: {name: 'Jeff', email: '[email protected]'}, tags: ['contact', 'priority']}). Next time you ask "summarize my unread mail," Jarvis retrieves the CEO memory via memory_query, prepends it to the system prompt, and the model surfaces Jeff's threads first. Updates use memory_update — "actually my CEO is now Sarah" triggers the model to call memory_update on the existing entry. Each write is visible in Settings → Memory with timestamp.

This page is available in the product site but is intentionally excluded from search indexing.

Memory & context