Blog

A benchmark dropped in June that names the failure mode every multi-agent memory system shares. The numbers are uncomfortable enough that they are worth quoting before anything else.

Emmimal P Alexander, “Vector RAG Isn’t Enough: I Built a Context Graph Layer for Multi-Agent Memory”, Towards Data Science, June 2026. Five scenarios, 18 queries, three architectures, fully deterministic, reproduced byte-for-byte on two machines.

Read the join column. That is the structural argument. Everything else in this post is downstream of those two numbers.

I have been running Ogham’s memory backend on Supabase since day one. It works. It is fast enough. The free tier covers my personal profile with room to grow. But every store_memory call goes transatlantic, and every hybrid search waits on someone else’s autoscaler. This weekend I moved it home.

Home is a Proxmox VE box that already runs a handful of LXCs for other services. I have SSD and spinning-disk ZFS pools sitting there. Adding one more container for Postgres was a straight-line plan: dedicated LXC, PG 18 with pgvector, WAL on the SSD pool, backups on the NAS pool, Supabase parked as warm DR.

OKF v0.1 was published six days ago. Ogham now writes and reads it. The round-trip from your own database – Postgres, Supabase, or anything else Ogham backs onto – to a portable markdown bundle and back is in the v0.15 release on PyPI. Two hours after v0.15 shipped, v0.15.1 fixed an import-path bug I caught in the live demo. This is the post about both.

What Open Knowledge Format is #

On 2026-06-12, Google Cloud published Open Knowledge Format v0.1. It’s a markdown convention. A directory tree where every file is a markdown document with YAML frontmatter, every document is one “concept,” and the directory structure is the navigation. Frontmatter requires only type:. Bodies are free markdown. Cross-references are normal markdown links. A bundle-root index.md declaring okf_version: "0.1" makes the directory conformant.

In March we published a post called One config flag, 7% better retrieval. It was true. A 21MB cross-encoder (FlashRank) rescored our search results and lifted BEAM Recall@10 from 0.65 to 0.70. We shipped it as an optional flag and felt good about it.

This is the follow-up where we tell you it stopped being true – and why that’s the more useful story.

The win evaporated on its own #

After March we rebuilt the base retriever. Better embeddings (Gemini at 768 dims instead of Voyage), tuned fusion weights, a graph layer for entity-linked recall. None of it was about reranking. But the baseline climbed anyway – Recall@10 from 0.65 to 0.74, and MRR from 0.46 all the way to 0.70.

On April 28, Supabase posted a breaking change to platform defaults. New tables in the public schema will no longer be auto-exposed to the Data API. If you want PostgREST, GraphQL, or supabase-js to see a new table, you write the GRANT yourself. The post is by @inian, a Supabase maintainer, and it is worth reading in full.

We agree with the change. We are shipping for it. This post is the short version of why, and what you need to do if you self-host Ogham on Supabase.

Anthropic shipped Dreams on May 6. The framing is biological: agents work, then consolidate “between sessions, the way memory works in sleep.” Right metaphor. Old metaphor. The literature behind it is 30 years deep.

This is the lineage, in six waypoints. Anthropic Dreams is the latest step, not the first.

1. 1994-1995 – the neuroscience root #

Wilson and McNaughton recorded hippocampal neurons during sleep in rats and found that the same neural ensembles that fired during a maze run re-fired in the same temporal order during the slow-wave-sleep phase that followed ¹. Reactivation, not noise.

Anthropic announced Dreams for Managed Agents on May 6. It’s an async batch job: read an agent’s memory store and up to 100 past session transcripts, and emit a new memory store with duplicates merged, stale entries dropped, and new patterns surfaced. The input store is left alone. You review the output and either attach it to future sessions or throw it away.

The architecture is exactly what Ogham’s compile_wiki has been doing since v0.12.0 shipped on April 27. Same inputs, same shape of output, same biological framing – consolidation between work sessions, the way human memory does it during sleep.

Until v0.13, every Ogham wiki preamble was the same shape: the full compiled body. Useful on the first call. Expensive to inject on every turn. About 1,500 tokens per page. Top-3 by default. So the preamble alone runs past 4,000 tokens before you’ve seen a single hit.

v0.13 splits the cached summary into three forms. One sentence, one paragraph, full body. You pick which one rides along on each retrieval.

For the last couple of months, Ogham has been about pushing memory in – store this, link this, retrieve this. v0.12 flips the question. You can now ask “what does my memory know about X” and get back one coherent page, synthesized from every memory carrying that tag. Then you can dump the whole layer to a folder of plain markdown and open it in Obsidian.

A wiki layer over your memory, and an exporter that hands the wiki layer to you as files you own.

Three weeks ago I posted R@10 = 0.737 on BEAM and 91.8% QA on LongMemEval. Since then v0.10 shipped intent-gated reformulation, v0.11 shipped migration 026 (memory lifecycle), migration 028 (topic summary cache), Phase 4 prompt-injection guards, and a 2.4x batch-INSERT perf fix. The default embedding dim moved from 512 to 768.

Heavy change. Time to re-measure.

The scoreboard #

Same benchmarks, same 400 and 500 questions, run this week on v0.11 with the code that’s going to PyPI today.