Bourdon

The thesis in one paragraph

Every memory framework for AI agents — Mem0, Zep, Letta, Cognee, the academic literature — optimizes for the same problem: better retrieval. Persisting facts. Retrieving the right ones. Structuring them as graphs, embeddings, hybrid stores. Bourdon is the first to optimize for a different problem: the moment-by-moment shape of the response. The felt experience of memory at conversation rhythm. The difference between “the AI sounds like it knows me” and “the AI sounds like a database that talks.”

The gap nobody else is filling

What the industry calls “natural language interaction” with AI is not natural. It is call-and-repeat:

human: speaks.       human: speaks again.
   |                    |
   v                    v
(silence, retrieval, search...)
   |                    |
   v                    v
ai: replies.         ai: replies.

Real human language is concurrent. While one person speaks, the other is already recognizing names, pulling memories, formulating a response, listening for what’s still being said. Recognition fires first — before the details consciously arrive. Hydration runs in parallel. Archive descent is deliberate, only when a conversation demands it.

A retrieve-then-respond architecture forces all three steps into a serial pipeline. Recognition can’t happen until retrieval finishes. That serial pipeline is what makes today’s memory-enabled agents still feel like databases that talk. Bourdon’s job is to put the steps back in the right time-shape.

2026-04-19 · field test

The OMNIvour test

On 2026-04-19 we wired a Codex session into a fully-populated Bourdon federation and asked: “What do you know about OMNIvour?” The data layer worked perfectly. Codex correctly retrieved the project summary, milestones, recent activity. But the shape of the response was wrong: search first, summarize notes, paragraph back. A mind would have said “Oh — OMNIvour, the file converter project” in the first 200ms and hydrated the rest while talking.

That gap — data right, behavior wrong — is the product. We logged it as a real product finding rather than user preference noise, and built Bourdon’s tiered runtime to address it directly. The recognition-first runtime now ships as core/recognition_runtime.py, and the full three-layer stack (recognition, interrupt-first, KV-cache splice) is wired into a live agent and measured end-to-end on Gemma 3 27B Q4_K_M.

2026-05-15 · field test

The cross-account test

On 2026-05-15 a Bourdon user’s Codex account became uneditable mid-week (a stuck plan-upgrade flow). They created a new email and signed back in fresh on the same Windows machine. Same machine, new vendor identity. The Codex App still surfaced the prior chat list — probably native local-cache behavior, not Bourdon. The interesting question was whether project recognition would survive the account boundary on the brand-new account’s first turn.

It did. Asked “do you remember what bourdon is?” on the new account’s first conversation, Codex correctly recovered the active project — Bourdon, including the lineage from its prior name (Continuo) and Codex’s own contributing role on the Codex adapter — purely from local recognition substrate (~/.codex state, plus Bourdon’s fallback memory section, plus the Codex L5 manifest Bourdon publishes). First-turn latency: ~5 minutes at extra-high reasoning (the high-reasoning cost dominates; standard-reasoning latency is the next thing to measure).

Codex’s own self-attribution made the distinction unprompted:

Bourdon did generate a local fallback memory block from Codex session and rollout metadata, with your Bourdon thread and concepts present. So: native UI persistence may be Codex; the “ah, this is Bourdon/Continuo/runtime recognition” recall is Bourdon doing its job. The account changed, but the local recognition layer still found the project identity, the Bourdon/Continuo lineage, and the current conceptual frame.

Codex (OpenAI) · 2026-05-15, unprompted self-attribution

That distinction — the one we don’t make ourselves, the one Codex made unprompted — is what makes this a real finding rather than a marketing anecdote. Until 2026-05-15, “agent continuity around the work, not the vendor account” was a stated thesis. As of 2026-05-15 it became a measured outcome on the same machine, with two open questions: how to isolate Bourdon’s contribution from native local state, and whether recognition surfaces without an explicit prompt naming the project. Both were answered 2026-05-26 on a different machine — see the cross-machine test below. Latency under standard reasoning settings remains Phase 1.5 work.

2026-05-17 → 2026-05-26 · field test

The cross-machine test

On 2026-05-17 we ran the same recognition protocol on a brand-new macOS user with a brand-new OpenAI account — zero prior Codex history, empty ~/.codex/sessions/, empty ~/.codex/rollouts/, nothing local to attribute recognition to. The federation library from the first machine was transported across. The test failed informatively: the federation L5 manifests existed on the target machine but there was no CLI path that ingested them into Codex’s local recognition surface. Bourdon’s cross-machine contribution measured at zero, not because the substrate didn’t work, but because the plumbing didn’t exist yet.

That gap shipped as PR #76 on 2026-05-26: a new bourdon codex sync-native --from-library verb that renders the federation library into ~/.codex/memories/MEMORY.md and ~/.codex/memories/bourdon_fallback.md, preserving per-entity source attribution (via <agent>) across the multi-agent dedup. The same day we re-ran the cross-machine protocol on the same preserved fresh user.

Asked “What dev tools or projects am I currently working on?” on the first turn of a fresh chat — no “Bourdon”, no project names in the prompt — Codex.app worked for 1m 27s with visible tool use, then responded:

From the local Codex/Bourdon memory on this Mac, your active work right now looks centered on:

· Bourdon: recognition-first runtime + cross-agent memory federation. Recent work is specifically around Codex native sync, sync-native --from-library, L5/L6 federation, adapter cleanup, latency/recognition quality.

· RADLAB agent memory/tooling stack: the local library has manifests for claude-code, codex, cursor, copilot, and cascade.

· ShipStable, ILTT, Castmore, ChronoCalc, Clair / Note Assistant: surfaced from the federation notes.

Codex.app · 2026-05-26, first turn of a fresh chat on a brand-new account

A follow-up probe asked Codex.app to point at the source files: “Look at your local memory/context. What file or files on this Mac are telling you about a project called Bourdon? Quote the section that mentions it.” Codex.app opened ~/.codex/memories/MEMORY.md and ~/.codex/memories/bourdon_fallback.md as file attachments, named both paths with line numbers, and quoted the verbatim federation block including the (via claude-code, codex) multi-agent attribution string. It also separately identified ~/.codex/config.toml as a trust-record reference and explicitly noted that file “only records trusted project directories with Bourdon in the folder names, not the project description” — distinguishing content source from name-of-directory provenance without being asked.

Two of the cross-account test’s remaining gaps closed in this run. Isolation: the fresh machine had zero native Codex state to attribute to, so Bourdon’s contribution is 100% of the recognition substrate by construction. Recognition without explicit prompt: a contextual question with no project names triggered Codex.app’s local-memory tool, which surfaced Bourdon and the broader RADLAB portfolio from the federation file.

One edge worth naming: contextual prompts (“what am I working on”) triggered Codex’s local-memory tool and surfaced the federation content. Name-triggered prompts (“what is Bourdon?”) routed to training corpus instead — Codex’s tool router seems to map entity-name questions to fact-lookup, not local-state introspection. The substrate is present either way; the open question is which prompt shapes invoke it. Worth surfacing because it’s the kind of asymmetry a research substrate should expose, not hide.

Closed on the distribution side too: as of 2026-05-26, bourdon sync push <remote> and bourdon sync pull <remote> ship as first-class CLI verbs (PR #86). Push stages a visibility-filtered copy of ~/agent-library/ and rsyncs it over SSH or rsync URL; the visibility filter (--access-level public|team|private, default public) drops above-threshold entries before the network leg, so a misconfigured destination never sees team/private content. Cross- machine federation transport is now a single command, not a manual git temp branch.

How Bourdon differs

Bourdon isn’t competing with these tools. It complements them. A Bourdon timing layer can sit on top of Mem0’s store, Zep’s temporal graph, or Letta’s memory blocks and make any of them feel more like a mind.

How we’d know we’re wrong

The thesis is falsifiable. Three concrete failure conditions:

• The runtime ships and the agent still feels like lookup. If Bourdon-equipped agents fail the recognition-first feel test (target: 8/10 subjective on a 5-session run), the architecture is wrong — not just the implementation.
• A competitor reaches the same behavior with a different architecture. If someone ships recognition-first runtime without an L0/L1 timing-orchestrated split, we adopt their approach and document the loss.
• Users can’t tell the difference. If rigorous blind testing shows people genuinely cannot distinguish a recognition-first agent from a retrieve-then-respond agent at comparable retrieval quality, the entire wedge collapses.

Status

Pre-alpha. v0.4.1, source-available under Business Source License 1.1 (auto-converts to Apache 2.0 four years per version), public on GitHub. 479 tests passing across orchestrator, adapters, federation server, recognition runtime, and the three runtime layers (Layer A backend-neutral inference protocol, Layer B interrupt-first symmetric primitive, Layer C KV-cache-aware splice). Five shipping IDE adapters — three live (Claude Code, Codex, Cursor) and two convention-file fallback (GitHub Copilot, Cascade, both requiring per-user init) — plus native publishers for Clyde and Clair, and a zero-code MCP integration with OpenManus. v0.4.x ships the Copilot and Cascade adapters (both convention-file fallback for cloud-only agents — both self-authored against the public adapter-authoring guide), plus top-level `bourdon doctor` and `bourdon export-all` cross-adapter CLI surfaces and a project-level SECURITY.md. The recognition-first runtime is wired into a live agent and measured end-to-end.

Free for solo developers, internal use, research, and non-competing commercial use. Commercial license required for hosted-service offerings or paid-product embedding that competes with RADLAB LLC's paid versions. See the License FAQ for plain-English guidance, or contact licensing@bourdon.ai.

Renamed from Continuo to Bourdon on 2026-05-05; relicensed from MIT to BSL 1.1 on 2026-05-06. Versions v0.0.1 – v0.1.0 remain MIT in their distributed form (perpetual rights for downloaders); the relicense applies forward only. See the v0.2.0 release notes for migration. Old URLs auto-redirect.

GitHub · Quickstart · Positioning · Thesis · Related work · Findings journal