Blog

Since March, Ogham has looked at your memories and guessed which pairs of words are somebody’s name. It tagged them person: and fed them into the entity graph, which feeds retrieval.

It was wrong almost every time. v0.18.0 removes the feature rather than fixing it, and this is the post explaining why deleting was the better engineering.

The number that ended the argument #

We measured our own production store. 5,606 entities, of which 4,170 – 74.4% – were tagged person:. A random sample of them turned up no actual people.

v0.16 gave Ogham a graph you can actually query – store_triple to write a typed edge, query_join to walk a predicate path and get the entities, edges, and citations along it. That closed the join-query gap. But a graph is only as useful as what is in it and whether you can trust what it tells you, and those are two different problems from “can you query it.”

v0.17 is three answers, one per problem. Get your context in without hand-feeding it. Give the edges a portable identity so they mean something outside Ogham. And record where a fact came from, so you can trace it back or ask what depends on it.

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.