Scaling donto to BEAM-10M — billion-token memory without sacrificing the vision

2026-06-05 · how donto takes on the hardest agent-memory benchmark split (Hindsight's worst, 64.1%) — what it requires (real code, new concepts, more hardware), and why every step is an expression of donto's vision rather than a compromise of it.

1. Why BEAM-10M is the right mountain

BEAM (arXiv 2510.27246) is the long-context agent-memory benchmark on Vectorize's neutral Agent Memory Benchmark. Its 10M-token split is where the current #1 system, Hindsight, is weakest: 64.1% — versus 92–95% on the small benchmarks (LoCoMo, LongMemEval). That gap is the whole point: on small conversations a frontier model can just read everything, so "memory" barely matters. At 10M tokens, full-context is physically impossible — the memory system is the system. This is the only regime that actually tests what donto is for.

It is also, precisely, the regime donto's vision was designed for. donto is a bitemporal, paraconsistent, evidence-first substrate built on the thesis that generation is now abundant and the hard problem is holding an unbounded, contradictory, evidence-anchored firehose and deferring typing / alignment / joining to query time. A 13-million-token conversation full of preference shifts, contradictions, and time-ordered events is that firehose. We do not need to bend donto to fit BEAM-10M; BEAM-10M is the shape donto was drawn around.

2. The real scale (measured, not guessed)

Downloaded a 10M shard and measured one conversation directly:

• ~10 conversations, each chat ≈ 53M chars ≈ 13.3M tokens.
• ~20 probing questions per conversation → ~200 questions for the split (so the judged answer cost is modest — ~400 codex calls; the bottleneck is not the LLM).
• Chunked at ~1.2–2 KB/chunk → ~250K–440K episodic chunks to store and embed.

So the challenge decomposes cleanly into two scale problems — ingest and embed — plus a recall/reasoning problem that is pure donto vision. None of them threaten the vision; two of them need new code and more hardware.

3. The three problems, and the vision-aligned solution to each

3a. Ingest — a firehose bulk path (code rewrite, I3-preserving)

Today donto-memory ingests one document per /memorize HTTP call: synchronous, doing extraction, evidence-anchoring, and a pg_notify. At ~7/call that is fine for chat but ~hours-to-days for 400K chunks. We need a firehose ingest path: batch-COPY episodic chunks into donto_statement + donto_x_memory_record in one transaction per conversation, carrying the session timestamp as valid-time and the source span as evidence — just without the per-row HTTP/notify overhead.

This is a new code path, not a new model. It honors invariant I3 (append-only, never overwrite), keeps every chunk evidence-anchored and bitemporal, and is literally named after the vision: donto's abundance thesis is a firehose; ingest should run at firehose speed.

3b. Embed — distributed + GPU (hardware, already-built fabric)

~300–440K chunks at bge-small. On this 4-vCPU box that's ~30–40 h; the embedding is embarrassingly parallel and we already built the machine for it this week:

• a distributed embedding coordinator (donto-embed-coordinator, live) with a work queue using FOR UPDATE SKIP LOCKED — hundreds of concurrent workers, zero double-work, self-healing leases;
• a dependency-free worker any machine runs (lease → fastembed → submit), documented for paste-and-run.

The resource ask lands here: one GPU box (a CUDA worker with fastembed-gpu) turns 400K chunks from days into ~1–2 hours. The embeddings remain a derived cache — never the substrate — so this is pure throughput, not a vision change. Alignment and folding still happen at query time.

3c. Recall + reasoning — deferred to query time (this is the vision)

Here is where donto differs from graph-building memories (Hindsight, Zep) — and why it can win. Those systems pay an expensive write-time cost to pre-compute an entity/temporal/causal graph over the whole conversation. At 10M tokens that pre-computation is the scaling wall. donto deliberately does not do this. It emits free, untyped, evidence-anchored chunks and defers the hard work — connecting facts across 13M tokens, resolving contradictions, ordering events — to query time, via:

• bitemporal recall — every chunk carries valid-time, so "what is true now" vs "what was true" is a query, not a write-time decision → directly serves BEAM's knowledge_update and temporal_reasoning / event_ordering categories;
• paraconsistent holding — contradictory claims are kept side-by-side and re-ranked by reality, not collapsed to a winner → directly serves contradiction_resolution (the category that breaks collapse-based memories);
• query-time alignment-closure + hybrid recall — fold synonymous predicates/entities and expand the candidate set at the moment of the question, over the abundance, instead of pre-baking a graph.

BEAM's ten categories (abstention, contradiction_resolution, event_ordering, information_extraction, instruction_following, knowledge_update, multi_session_reasoning, preference_following, summarization, temporal_reasoning) are, almost one-for-one, the things donto's paraconsistent-bitemporal-deferred design is built to do. Hindsight's 64.1% is partly because pre-built graphs degrade at this scale on exactly these contested categories. donto's vision is the competitive advantage here, not a handicap.

4. New concepts this forces us to invent (all vision-native)

1. Firehose ingest — bulk, transactional, I3-safe episodic ingest at abundance speed (§3a). Generalizes to the whole substrate (the frontier-violence corpus, the genealogy backlog).
2. Multi-resolution recall over abundance — at 400K chunks, flat top-k isn't enough. Coarse→fine recall (session-summary → chunk → turn), riding the existing pgvector HNSW + alignment closure. New, but a pure extension of query-time joining.
3. Query-time cross-session reasoning vs. write-time graphs — formalize donto's bet: pay at read time, not write time, so cost scales with questions asked (≈200) not tokens stored (13M). This is the thesis BEAM-10M lets us prove.

5. Resources to buy (you offered — here's the precise list)

• A GPU worker (cloud or local; one mid-range CUDA GPU) → embeds 400K chunks in ~1–2 h via the existing coordinator. The single highest-leverage purchase.
• Disk headroom on the data volume for ~400K chunks + 384-dim vectors (≈ a few GB — modest).
• A Gemini (or Groq) key → run the answer+judge on the standard AMB backend for leaderboard-exact comparability with Hindsight (codex works now for our own number; Gemini makes it apples-to-apples).
• (Optional) a second embedding worker / more cores → linear speedup; the fabric already supports N machines.

6. The vision-preservation contract

Every scaling move must express donto's vision, never bypass it. Concretely:

If any step required collapsing claims, picking winners at write time, or discarding evidence to go faster — we would not do it. We scale the firehose; we do not dam it.

7. The plan

1. Source + load BEAM-10M (done: data in hand, ~10 convs measured).
2. Build the firehose ingest path (bulk COPY, I3-safe, bitemporal) — the one real rewrite.
3. Embed via the coordinator + a GPU worker (the resource) — 400K chunks in hours.
4. Multi-resolution hybrid recall over the chunked conversation (extend recall).
5. Run AMB: omb run --dataset beam --split 10m --memory donto (~200 questions; codex now, Gemini for parity later) → donto vs Hindsight 64.1%, per the ten categories.
6. Then add the cross-encoder reranker (the one piece Hindsight has and donto lacks) and re-run — measured lift.

BEAM-10M is the benchmark where donto's vision stops being a philosophy and becomes a measurable advantage. We do it — and we sacrifice none of it.

Status: data measured; firehose-ingest + GPU-embed are the build/buy; the donto AMB provider already runs. Sequenced after the in-flight LongMemEval full-500 + the LoCoMo donto-vs-Hindsight signal.