# 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](https://huggingface.co/datasets/Mohammadta/BEAM-10M) (arXiv 2510.27246) is the long-context agent-memory benchmark on Vectorize's neutral [Agent Memory Benchmark](https://agentmemorybenchmark.ai). 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](https://genes.apexpots.com/research/donto-distributed-embedding-prd-2026-06-05.html).

**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:

| scaling move | vision it preserves |
|---|---|
| firehose bulk ingest | I3 append-only · evidence-anchored · bitemporal valid-time |
| distributed/GPU embedding | embeddings stay a *derived cache*; alignment + folding at query time |
| query-time recall/reasoning | emit-free / defer typing-alignment-joining to query time |
| paraconsistent holding | hold contradictions; re-rank by reality; never collapse to a winner |
| multi-resolution recall | join over the abundance at read time, no pre-built graph |

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.*