Compare / vs Letta
Continuity above the editorvs an agent operating system.
Letta is a real agent runtime, and for teams that need one agent running as a service with deep memory primitives, it is the better answer. Zephr is the layer above the editor that lets every connected agent share the same worktree-scoped memory with trust governance. The right pick depends on whether your bottleneck is one agent or many.
Same problem space, different boundary.
Letta is an agent runtime that owns memory. Zephr is a continuity layer that sits above the editor. The columns are not a scorecard; they are different answers to different questions — pick the one whose failure you are more worried about.
| Feature | Letta | Zephr |
|---|---|---|
| Deployment shape | Agent runtime (server-hosted or self-hosted agent OS) | Continuity layer above the editor; memory follows the worktree |
| Memory scope | Per-agent (the runtime owns the context window) | Per-worktree, per-session, per-project — agent-agnostic |
| Cross-client | Agents that speak the Letta API | MCP-native — works across all connected agents, including ones you did not write |
| Memory consolidation | Sleep-time re-blocking; in-runtime memory rewriting | Append-only evidence graph; consolidation is reviewable, not automatic |
| Trust governance | Per-agent policy; in-runtime authorization | Trust Firewall — authorization before retrieval, signed by a human, audit-trailed |
| Provenance | Per-agent memory blocks, not source-anchored | Full chain: source → episode → worktree → session → authorization |
| Open-core | Yes (Apache-2.0 server) | Yes — local SQLite, no account required |
Public positioning snapshot, re-checked August 2026 — not live data. Letta is actively developed and may add comparable capabilities; this is a dated view, not a forecast.
Checkable capabilities, including where Zephr is partial.
A matrix that came out all-green for Zephr would mean the rows were chosen to flatter us. In-runtime memory is a real Letta win; cross-tool memory, authorization-before-retrieval, and signed review are the Zephr bets.
| Runtime boundary | In-runtime memory | Cross-tool memory | Auth before retrieve | Signed review |
|---|---|---|---|---|
| Letta | ●supported | ◐partial | ◐partial | ◐partial |
| Zephrthis page | ◐partial | ●supported | ●supported | ●supported |
Runtime lens · public positioning re-checked 2026-08-22 · ADR-Z-16 · packages/core/src/admission.ts · packages/mcp-server/src/transport.ts
verdicts are testable and dated — no scores, no winners
Letta is the better runtime for one agent as a service.
Zephr is not better at everything, and pretending otherwise would undermine the one thing this product is for. Letta's strengths below are real, and for teams that need a real agent OS they are the deciding factor.
Agent OS depth
A real runtime with sleep-time consolidation, persistent agents, and primitives the runtime can reason over. The agent is the deployment unit, not a wrapper.
Per-agent context windows
Memory blocks are first-class, addressable from the agent loop, and consolidated at scheduled intervals — the kind of plumbing a real product needs at scale.
Open-source server
Self-hostable, inspectable, and stable in a way the open-source server for many "agent" libraries is not. The platform is the product.
Agent-native memory model
If your entire workflow is one agent inside one runtime, Letta is the simpler stack: the memory, the agent, and the runtime are designed together.
Public positioning re-checked August 2026. Letta is a moving target; treat any single feature as a dated snapshot rather than a permanent ranking.
Where Zephr adds value.
Zephr is not a faster Letta. It is a different layer — cross-tool continuity, source-anchored provenance, and trust governance — and it is worth more the more agents and tools you move between.
Cross-tool portability
Memory is held above the editor, so it survives the moment you move from Claude Code to Cursor to a custom MCP client. The runtime is the agent's, not yours.
Trust governance
Authorization is evaluated before retrieval, signed by a human, and recorded in an audit trail. The Trust Firewall is a policy, not a preference.
Source-anchored provenance
A claim is stored with the files, commits, and line ranges it rests on — not as an opaque memory block whose origin the runtime rewrote overnight.
Human-signed review
Confirmation is recorded with a human identity and a `confirmation_audit` row. A runtime that auto-confirms beliefs is a runtime with no review, not a runtime with reviews.
Choose Letta or Zephr?
The choice comes down to which failure you are more worried about: one runtime that locks memory inside it, or many tools that share no continuity layer at all.
Neither failure mode is exotic: an agent OS that owns its memory is a first-class answer for one agent, and a missing continuity layer is a live risk every time a teammate moves between tools. Which one you are absorbing decides the category.
Choose Letta if…
You need a real agent OS with per-agent memory blocks, sleep-time consolidation, and a runtime that owns the agent loop — and your entire workflow lives inside that runtime.
Choose Zephr if…
You work across multiple coding agents, need per-worktree memory scope, and want every retrieval to prove authorization and carry a receipt you can inspect afterwards.
See how Zephr enforces trust.
The trust model covers authorization before retrieval, scope binding, and evidence receipts — the three things this comparison keeps returning to.