Skip to content
ONTO

ONTO vs Letta (MemGPT): Two Approaches to Long-Term Agent Memory

Letta (formerly MemGPT) pioneered the idea of agents managing their own memory through tool calls. ONTO takes a typed-graph approach. Same problem, different solutions.

· 9 min read · ONTO team

Letta (formerly MemGPT) is one of the most thoughtful research projects on agent memory in the past two years. The core idea: the agent itself manages its memory through tool calls. It writes to a “working memory” it can see directly, archives older entries to a searchable store, and pulls from the archive when needed.

ONTO takes a different approach: typed memory with explicit extraction, managed by the runtime rather than the agent.

This post compares the two architectures honestly.

Letta’s architecture in one paragraph

The agent’s prompt includes its working memory. It can call tools to write to working memory, search the archive, or move items between the two. Memory management is part of the agent’s task — the model decides what to remember and what to archive. The system provides storage and search; the agent provides the policy.

This is elegant. It means a smart model can build sophisticated memory behaviors without you writing schema. It also means the model is responsible for memory hygiene.

ONTO’s architecture in one paragraph

The agent reads typed memory at the start of each turn and proposes typed assertions through extraction. The runtime — not the agent — writes them, with provenance, decay, consent scopes, and routing by extraction level. Conflicts surface as Plan Mode tasks. Memory management is a system concern, not an agent concern.

This is more rigid. It also gives you an audit trail by construction, with provenance per fact, and lets you reason about “what does this agent know” outside the model.

Where Letta’s approach wins

  • No schema required. The agent figures out what to remember. You don’t have to pre-define predicates.
  • Memory behavior emerges from the model. A smarter model produces smarter memory behavior, automatically.
  • Conversational fluency. Memory operations happen inline with reasoning, so the agent can incorporate memory state into its responses naturally.

For use cases where you want a single agent personality with long-term coherence — companion chat, creative collaboration, ongoing research dialogue — Letta’s approach is well-suited.

Where ONTO’s approach wins

  • Auditability. Every assertion has provenance and routing through Policy Guard. You can answer “what did the agent learn, when, and how” with structured data, not a transcript.
  • Compliance. Regulation tags ([pii], [phi], [mnpi]) ride on every assertion. Retention and decay policies are properties of the typed row.
  • Multi-tenant scoping. Domain-level extraction partitions memory by tenant. Cross-tenant reads refuse structurally.
  • Cost discipline. Memory management doesn’t burn foreground tokens — extraction can run async or on a cheaper background model.

For use cases where memory is a system property you have to answer for — regulated industries, multi-tenant SaaS, long-running personal assistants where the user owns their data — ONTO’s approach maps better.

The model-agnostic question

Letta’s approach assumes the model is good at managing memory. When the model is changed, the memory behavior changes. With strong models, this is great. With weaker open-weight models, the memory behavior degrades — the agent forgets to archive, accumulates clutter, or paraphrases facts.

ONTO’s approach is largely model-agnostic. Extraction quality varies by model, but the structure of memory (typed, routed, audited) doesn’t change. This matters for ONTO’s open-weight default: extraction prompts that work on a 20B parameter model produce the same memory shape as extraction prompts on a frontier model.

The “what should the agent know” question

A subtle difference. In Letta, the agent’s working memory is what the agent decided to remember. In ONTO, the agent reads UPO at the start of each turn — a set of facts you can query independently.

This means:

  • In Letta, “what does the agent know about user X” is a question you ask the agent (and trust the agent’s answer).
  • In ONTO, “what does the system have stored for user X” is a Postgres query that returns the same answer regardless of which model runs.

For systems where the answer to that question has to be reliable independent of the model’s mood, ONTO’s externalized memory is more robust.

Can you use them together?

Less obviously than ONTO + LangChain or ONTO + LlamaIndex. Letta and ONTO are both opinionated about how memory should work, and the opinions don’t perfectly compose. The most practical pattern is to pick one as the spine.

If you choose Letta, you get the agent-managed memory model. If you choose ONTO, you get the typed-graph model with audit.

A simple choice flow

Need a typed, auditable, multi-tenant memory layer?           → ONTO.
Need model-managed memory with conversational fluency?         → Letta.
Need on-prem with open-weight defaults?                        → ONTO.
Want memory behavior to scale with model quality automatically? → Letta.
Need consent scopes on tools, not just memory?                 → ONTO.
Building a companion / ongoing-dialogue product?               → Letta.
Building an agent that acts on the world?                      → ONTO.

A bigger question

Both projects are placing real bets on how agent memory should work. Letta bets on the model: smarter models produce smarter memory. ONTO bets on the system: explicit structure gives you auditability and stability across models.

The bets compose at the field level. If frontier models keep getting much smarter, Letta’s approach will look more attractive — let the model do the work. If the production cost question keeps mattering and regulatory pressure keeps growing, ONTO’s approach will look more attractive — make the structure explicit so the system can answer for the model.

It’s not yet obvious which way the field will go. The healthy answer is “both, for different use cases,” and that’s where we are today.


See the typed memory thesis for the longer argument behind ONTO’s approach, and the features page for what UPO + SMO actually look like.

Frequently asked questions

Is Letta still called MemGPT?

The original research paper was MemGPT; the project was renamed Letta when it became a product. Both names refer to the same lineage. We'll use Letta throughout this post.

Does Letta use vectors or typed storage?

Letta uses a combination — a working memory the agent manipulates directly, plus archival storage with vector retrieval. The novelty is the agent-as-memory-manager pattern.

Which has better quality on long-conversation benchmarks?

Honestly, depends on the benchmark and the task. Letta excels at agent self-management of memory; ONTO excels at producing an auditable typed graph. They optimize for different goals.

Build with ONTO

The agent SDK where humans drive the state.

Plan Mode, typed memory, per-call consent scopes, and open-weight defaults. Open source under MIT or Apache-2.0.