Mirix Personal Memory Assistant
Turns screen activity and conversations into searchable personal memory.
Per-dimension scores and reasoning
Evidence: README claims privacy-first with local storage, but no implementation details; API key management exists (conftest.py), but least privilege not demonstrated; external dependencies (composio, aiogoogle) may have external effects, but no user confirmation mechanism; many dependencies without security audit; no rollback; source attribution partially clear (acknowledges Letta). Deductions: lack of user confirmation, insufficient data flow transparency, dependency security not assessed, no rollback.
Evidence: Test files exist (test_agent_prompt_update.py etc.), but tests depend on external API keys and manual server start, not deterministic; many dependencies with wide version ranges, potentially unstable; error handling tests exist (test_error_handling_nonexistent_agent), but overall failure message quality not fully assessed. Deductions: tests depend on external services, dependency availability unverified, failure message coverage limited.
Evidence: README describes multiple use cases (screen tracking, multimodal input), but target audience not explicit; capability boundaries not clearly defined; trigger mechanisms (e.g., auto-dream) documented, but precision unverified; environment fit (Docker, Python versions) described, but not all platforms covered. Deductions: vague capability boundaries, trigger precision unverified, limited environment fit.
Evidence: README well-structured with quick start and examples; install notes (Docker, pip) present; naming (MIRIX) stable; example code provided; but no known limitations section, no changelog, maintenance responsibility unclear (only contact email). Deductions: missing known limitations, changelog, unclear maintenance responsibility.
Evidence: Output usability (API returns memories) exemplified, but actual effectiveness unverified; marginal value (multi-agent memory system) described, but not compared to alternatives; cost-benefit not discussed. Deductions: output usability unverified, cost-benefit not analyzed.
Evidence: README claims (e.g., privacy-first) lack implementation evidence; test files exist but depend on external services, cannot be independently verified; facts and inferences not clearly separated. Deductions: claims lack traceability, cross-source corroboration insufficient, facts and inferences conflated.
- Many dependencies without security audit, posing supply chain risk.
- Tests depend on external API keys and manual server start, not automatable.
- Privacy claims lack implementation details, data security needs careful evaluation.
- No changelog, maintenance responsibility unclear.
What does this agent do, and when should you use it?
Mirix is a multi-agent personal assistant centered on building long-term memory from screen observation and natural conversation. It separates memory into six components—Core, Episodic, Semantic, Procedural, Resource, and Knowledge Vault—managed by dedicated memory agents. The system accepts text, images, voice, and screen captures, and supports retrieval through PostgreSQL-native BM25 full-text search and vector similarity. Its backend and dashboard run through Docker Compose, with the dashboard on port 5173 and API on port 8531 by default; Python applications interact through MirixClient. Long-term data is described as locally stored with user-controlled privacy settings, while the supplied material does not specify screen-capture permissions, supported operating systems, or resource requirements.
Run docker compose up -d --pull always to start the backend and Dashboard, then create MIRIX_API_KEY in the Dashboard. A Python application connects to http://localhost:8531 with MirixClient and calls initialize_meta_agent to configure the model, embedding model, and six memory-agent components. client.add accepts user- and assistant-role message content under a user_id, while client.retrieve_with_conversation uses the current conversation to return relevant memories, with the example limiting output to five results. Mirix also exposes POST /memory/auto_dream?user_id=demo-user and client.auto_dream to review selected memory components, merge duplicates, attempt to resolve stale or conflicting entries, and write results back. Setting dry_run=true reports processing counts without applying updates.
- An individual who wants to revisit recent work seen on screen and discussed in chat can retrieve topics associated with their user identity over recent days.
- A researcher or knowledge worker who wants to consolidate chats, images, voice, and screen captures into a personal memory store can submit those modalities to one service.
- A Python developer building a personal assistant with persistent memory can initialize the memory agents and call add and retrieve_with_conversation from an application.
- A self-hosted administrator facing duplicate or conflicting memory records can inspect an auto-dream run first, then consolidate Episodic, Semantic, and Knowledge Vault memory through experience mode.
- A team that requires long-term data to remain locally stored and wants user-controlled privacy settings can deploy Mirix as a self-hosted memory service in its Docker environment.
What are this agent's strengths and limitations?
- Organizes information into six explicit memory components instead of keeping all history as one undifferentiated context.
- Handles text, images, voice, and screen captures, with screen activity serving as a memory input.
- Offers both PostgreSQL-native BM25 full-text search and vector-similarity retrieval.
- Auto-dream can consolidate a chosen memory category, including duplicate merging and stale or conflicting-entry handling, with a dry-run option.
- Long-term data is described as locally stored with user-controlled privacy settings.
- The supplied model and embedding example depends on Google AI, Gemini 2.0 Flash, and text-embedding-004; support and configuration for other providers are not documented.
- Deployment involves Docker Compose, a Python client, API keys, and PostgreSQL search capabilities, creating more operational overhead than a hosted chat product.
- The material does not document supported operating systems, permission flow, retention policy, or performance impact for continuous screen capture.
- Although image, voice, and screen-capture inputs are named, acquisition methods, format constraints, and failure handling are not specified.
- Auto-dream writes consolidation results back to memory; dry run is available, but no rollback or version-recovery mechanism is documented.
How do you install or deploy this agent?
Prerequisites: Docker Compose is required for the backend and Dashboard, and Python is required for the client. In the deployment directory, run:
docker compose up -d --pull alwaysOpen http://localhost:5173, create an API key in the Dashboard, and set it as MIRIX_API_KEY. Then install the client:
pip install mirix-clientThe documented default API base URL is http://localhost:8531.
How do you use this agent?
Create MirixClient(api_key="your-api-key", base_url="http://localhost:8531"). Call initialize_meta_agent with llm_config, embedding_config, and meta_agent_config; the supplied example uses Gemini 2.0 Flash, Google AI endpoints, and text-embedding-004. Write conversation records with client.add(user_id=..., messages=[...]), then retrieve related memories using client.retrieve_with_conversation(user_id=..., messages=[...], limit=5). To consolidate memories, call client.auto_dream(user_id="demo-user", mode="experience", dry_run=False); use dry_run=True first to preview processing counts.
How does this agent compare with similar options?
The README credits Letta as the framework that served as a foundation for Mirix's memory system, but provides no feature-by-feature comparison or benchmark.