How to read this

An analysis tool for the AI agent stack. It helps you choose the components of an agent or multi-agent system (framework, models, memory, vector and graph stores, gateways, guardrails, tools, observability), check a stack you already run, and see why each pick was made: every fact it uses links to its source.

What this is

1,005 systems across 38 sections, scored on 69 columns (lifecycle, licence, deployment, pricing, compliance, integrations, …), connected by 2,542 typed edges (built-on, cites, integrates-with, …).

Counted from landscape.json when the site was built; data as of 2026-10-31.

Tier badges

Every record carries an ordinal tier from T1 (most battle-tested) to T5 (most speculative). Tier is not a quality score — a T5 manifesto and a T1 commercial product are different artefacts, both worth tracking.

  • T1 Battle-tested. Real customers, measurable enterprise adoption (commercial + mature OSS).
  • T2 Established / mature OSS. Significant traction, clear maintainer team, in production at known users.
  • T3 Peer-reviewed. Published at a recognised venue (ACL, EMNLP, NeurIPS, ICLR, …) with code.
  • T4 Preprint / unpublished. arXiv (or similar) with implementation but not yet peer-reviewed.
  • T5 Theoretical or informal. Idea-stage; blog post, manifesto, taxonomy entry, no code.

The 7 taxonomy axes

Each record is placed on seven independent axes. A record can have multiple values per axis (e.g. Mem0 is vector + graph + kv on the storage axis); exactly one value per axis is marked primary.

Storage
Where memory data sits — vector / graph / kv / file / latent / hybrid / …
Retrieval
How reads happen — semantic / structural / hybrid / parametric / …
Persistence
Durability of the memory — session / process / persistent / …
Update
How memory gets written — explicit / implicit / batch / …
Unit
Granularity of what's stored — fact / chunk / event / trajectory / …
Governance
Who decides what gets remembered — auto / curated / mixed / …
Conflict
How contradictions resolve — latest / vote / merge / ignore / …

Cell status indicators

Every cell in the 67-column table carries a status so a reader can tell "data" from "we tried and found nothing" from "doesn't apply here".

  • real-data Actual data, sourced and (usually) cited.
  • not-applicable Column doesn't apply to this record (e.g. funding on a research paper).
  • depth-floor-reached Searched in good faith; no info found. Honest gap.
  • no-data Placeholder for an un-researched cell. Rare in terminal data.

Where a fact comes from

Each cited cell shows who published its source, so a vendor's own claim reads differently from a third party's:

  • vendorThe system's own site or docs. A vendor-stated claim.
  • repoA code repository, usually the project's own.
  • registryA package or model registry (PyPI, npm, Hugging Face).
  • paperA paper or paper index (arXiv, ACL Anthology, OpenReview).
  • third-partyAnything else: press, analysts, funding databases, other vendors' integration docs.

A system page's header counts how many of its cited facts have a third-party source. The class is derived from the citation URL when the site is built and is published per cell as source_class in /api/systems/<id>.json.

Separately, each cell carries a verifiability tier: T1 (●) is auto-verifiable from GitHub, T2 needs a resolvable source URL, and T3 is an estimate or inference without a citation.

How edges work

The Graph and Lineages views are powered by a separate file of typed directed edges. Multiple edges between the same pair are allowed if the type differs (Letta succeeds MemGPT and is by the same team as MemGPT — both useful).

  • built-on — source's product is implemented on top of target (target is a dependency or runtime).
  • extends — source extends or generalises target's method, keeping the core idea.
  • forks — source is a literal code fork of target.
  • integrates-with — source has a first-class integration / connector / adapter to target.
  • competes-with — positioned by the market (or themselves) as alternatives in the same buyer's mind.
  • inspired-by — source cites target as conceptual inspiration without building on or extending it.
  • cites — source's paper cites target's paper; populated from Semantic Scholar.
  • same-team-as — same authors, lab, or company across two systems.
  • succeeds — explicit successor / next-version by the same team (e.g. MemGPT → Letta).

Methodology & provenance

Every entry was sourced from one of:

  • Curated lists (Agent-Memory-Paper-List, Awesome-GraphMemory).
  • Survey papers (arxiv.org/abs/2512.13564, arxiv.org/abs/2508.10824).
  • Benchmark leaderboards (LongMemEval, LoCoMo, ConvoMem).
  • Vendor websites and academic venue pages.
  • Targeted research-agent sweeps (~25 agents over multiple rounds).

Coverage of the memory-shaped core: ~88–92% as of the last terminal pass. URLs were verified at time of entry. Claims (the right-hand columns) are vendor-stated unless otherwise marked.

Scope. The catalog covers memory systems for AI and the adjacent infrastructure that touches them — training platforms and dataset stores, generic vector / search systems, and agent frameworks regardless of whether they ship a first-party memory layer. The goal is comprehensive landscape coverage of the sphere, not a strict memory-only filter. Coverage of the adjacent categories is lower than the memory core and being expanded incrementally.

Acknowledgements & complementary resources

  • dbdb.io — Carnegie Mellon's database-of-databases. Same form, different domain; roughly 17 systems overlap with this catalog.
  • Agent-Memory-Paper-List — source curated list for the research-side entries.
  • Awesome-GraphMemory — source curated list for graph-memory systems.
  • GitHub repo — issue tracker, build plan, decision log, raw landscape.json.