| FMRS | 59 / 100 · C | 79 / 100 · B |
|---|
| Reliability | 10 / 20 | 12 / 20 |
|---|
| Security and permissions | 12 / 20 | 18 / 20 |
|---|
| Maintenance | 12 / 20 | 16 / 20 |
|---|
| Documentation | 11 / 20 | 18 / 20 |
|---|
| Setup experience | 14 / 20 | 15 / 20 |
|---|
| Best for | - Developers who use several MCP-compatible AI coding tools and are tired of re-explaining themselves.
- Users who want memory and identity data to stay on their own machine, inspectable and editable.
- Individuals or small teams long-term-accumulating quality standards, architecture decisions, and technical lessons.
- Vibe-coding workflows that need continuity across sessions, tools, and projects.
- Users who accept human review gates in exchange for local data sovereignty.
| - Engineering teams scaling AI coding agents while controlling spend
- Platform teams that need auditable, rollback-aware agent execution records
- Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
|
|---|
| Not for | - Multi-person collaboration, team-shared memory, or centrally managed server deployments (this is a personal identity layer).
- Anyone needing vendor SLAs, enterprise support, or a commercial license (AGPL-3.0, no separate commercial license).
- Storing passwords, API keys, or customer PII — the project explicitly advises against it.
- Users whose primary need is agent task memory/session history and who have already chosen Mem0/Zep/Letta-style tools.
- Scenarios demanding hardened access control over plaintext local files: restricted_fields and the governance layer are not encryption or a true ACL.
| - Developers who just want a simple code-completion helper without run governance
- Teams unwilling to accept local JSONL run records with HMAC signing
- Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
|
|---|
| Required permissions | - Read and write JSON/Markdown files under the local Engram data folder (default ~/.engram/).
- Write AI-client MCP config and instruction files during engram setup, only after your confirmation (backed up first; decline leaves them untouched).
- Write a local-only audit log at ~/.engram/audit.log, enabled by default (opt out with ENGRAM_AUDIT=0).
- Optional: read_web_content fetches a URL you provide, via a local sidecar or the built-in reader.
- Optional: ENGRAM_TOOLS=all exposes all 59 tools to the model, including owner/admin export, import, and trust-management interfaces.
- Optional: remote SSE mode requires ENGRAM_AUTH_TOKEN and should sit behind a TLS reverse proxy.
- Optional: telemetry is off by default; enabling remote telemetry or feedback is separate explicit opt-in and sends counts only.
| - Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
- Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
- Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
- Execution of user-configured verifier commands (e.g. npm test)
|
|---|
| Risks and side effects | - Data is plaintext JSON/Markdown by default, so any process that can read ~/.engram/ can read your data; field-level encryption is optional, not the default.
- The project explicitly warns against storing passwords, API keys, or client PII in Engram.
- restricted_fields only reduces what is emitted in cold-start context — it is not encryption or a real ACL.
- Caller identity comes from MCP environment variables rather than cryptographic authentication, so governance is a practical local policy boundary, not a hardened sandbox; the MCP spec does not pass tool identity.
- Export outputs (export_engram, get_identity_card, export_knowledge_report) contain full or broad content and should be treated as sensitive files.
- import_engram mutates the local store: always preview with dry_run=True first; applying requires explicit --apply --yes.
- Concurrent writes rely on a file lock plus atomic replace; network-filesystem edge cases are not guaranteed.
- Playbook auto-extraction redacts sensitive info before staging (keys, tokens, absolute paths, emails), but drafts remain untrusted until you confirm them.
- Remote deployment without proper HTTPS and token handling can expose identity data.
| - Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
- Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
- Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
- Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
|
|---|
| Supported clients | Claude Code, Codex, Cursor, Claude Desktop, Hermes, OpenClaw, Windsurf, GitHub Copilot, Cline, Roo Code, Amazon Q, Augment, Zed, Trae, Tencent CodeBuddy, ChatGPT / Gemini / Kimi | Claude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue |
|---|
| Tools | 58 | 0 |
|---|