SyBok: a context layer for AI that you actually own

🤖 AI-generated — written by Claude (Opus 4.8) in collaboration with Rob Jenkins.

The problem

If you work with AI coding agents across more than one project or machine, you keep paying the same tax: the model forgets. Context you built up in a long session evaporates. What you figured out on your desktop isn’t on your laptop. And “how do these projects relate?” gets re-derived from scratch every time — burning tokens to rebuild last week’s conclusion.

The usual answer is a vector database behind a service (Mem0, Zep, Letta). Those are fine, but your knowledge lives in someone else’s schema. SyBok — Synthesis and Body of Knowledge — takes a different bet: your context should be plain files you own, and derived answers should be compiled artifacts that rebuild themselves when their sources change.

The core idea

Three moves — borrowing the wiki shape from Karpathy’s “LLM Wiki” and adding the piece it lacks:

1. Markdown-in-git is the source of truth. Every fact is a human-readable page under version control. No proprietary store, no lock-in.
2. The search index is disposable. SyBok builds a SQLite (full-text + vector) index for retrieval — but it’s derived. Delete it and rebuild from the markdown anytime.
3. Synthesis is a compile step with a dependency graph. When SyBok answers a question it compiles the answer from evidence pages and caches it, recording exactly which pages (at which content-hash) it used. Ask again → instant cache hit. Change a source → SyBok knows which cached answers went stale and rebuilds only those. It’s make for knowledge.

Architecture, briefly

A SyBok instance holds several Bodies of Knowledge (e.g. projects, research), each a git repo with layers: raw sources/, a curated wiki/ (entities, concepts, summaries), the synthesis/ answer cache, autonomous findings/, an operator/ layer for human to-dos, and a portable skills/ library. Every page carries provenance — where it came from, how trusted it is, what it was derived from.

It runs server-authoritative: one always-on hub is the single source of truth, and every machine is a thin client over MCP and a web UI. Nothing to sync, no merge conflicts. Inference is hybrid — a local GPU model does the cheap, high-volume work for free, and a frontier model (Claude Opus) handles hard synthesis and web research.

The loops

Because the hub is always on, it runs background work a laptop can’t:

• Resynthesis (every 15 min): rebuilds cached answers whose sources changed — zero cost when nothing changed.
• Scout (daily): proposes and web-researches new directions, filing them as unverified findings.
• Verify: a skeptical pass that promotes only well-supported findings (it once caught fabricated paper IDs and refused to promote them).
• Backup (daily): git history + local tarballs + an off-box copy.

A day in the life: three Expo + Supabase apps

Say you build mobile apps — Expo Router front-end, Supabase back-end — and over a few months you ship three: a run-tracker, a plant-care reminder, a local-events app. Different products, near-identical plumbing. Here’s where SyBok earns its keep.

• Context. You ingested each repo, so on any machine a fresh session can ask “how do my Expo apps handle Supabase auth and session refresh?” and get one synthesized answer across all three — cached, instant next time. Refactor app #3 and re-ingest; fifteen minutes later the resynthesis loop has already rebuilt that answer.
• Research. You’ve meant to nail the right Supabase Row-Level-Security pattern but never had the afternoon. The nightly scout, seeing “Supabase” all over your projects, researches it on its own and leaves a sourced finding by morning — unverified until you promote it.
• Skills. A clean Expo Router scaffolding recipe you captured as a skill auto-materializes onto every machine via a session-start sync. You never copy a file.
• Skill promotion. Mid-build you work out a solid Supabase-migrations-in-Expo workflow; one command promotes it to the hub as trusted, and by app #3 it’s already installed on whatever machine you’re using.

By app #3 you start from your own accumulated context, not from zero. Each project makes the next one faster — which is the whole point.

The twist: I caught it failing at its own job

While building all this, SyBok did something that exposed a gap — and became my favorite feature.

I asked my agent about MiniBlogr (the platform this post is published on — my own project, thoroughly documented inside SyBok). It web-searched it like a stranger. The knowledge was right there; nothing prompted the agent to look.

That’s the quiet failure mode of any memory system: it’s pull — it only helps if something reaches for it. So I built the missing half:

• Consult-first, primed. Every session now opens with a compact digest of what the hub already knows — the projects, tools, and machines it has context on — plus a standing instruction to check the hub before web-searching my own things.
• A feedback layer. When an agent notices SyBok fell short — a miss, friction, an idea — it files a note into a dedicated meta knowledge base.
• A self-improvement loop. Weekly, the hub reads that feedback, researches how comparable systems solve each problem, and files concrete improvement proposals — a cited brief plus an action item — for me to review.

I dogfooded it on the spot: filed the MiniBlogr miss as the first piece of feedback. The loop read it and proposed — with twenty-odd sources each — session-start entity priming and a “consult-the-hub-first” routing policy: the exact fixes I’d just built, arrived at independently. A context system that noticed it wasn’t being used, and drafted its own upgrade.

And because config should travel like knowledge, a single command onboards a new machine — installing the session hooks and syncing both the skills and the standing guidance from the hub.

Why it’s worth it

• You own it — plain markdown in git, the most portable format there is.
• Durable and auditable — everything versioned, auto-committed, and backed up.
• Cross-machine with no sync tax — one hub, thin clients everywhere.
• Cheap by design — the cache stops re-derivation; bulk work runs on a local GPU.
• Trust is explicit — answers cite their evidence, autonomous findings must be verified, and executable skills are gated.

An honest note

SyBok isn’t trying to beat Mem0 or Zep — those are memory backends for products. It’s a personal, self-hosted context hub for one person across their own machines. The markdown-in-git wiki pattern isn’t novel either; credit for that goes to Karpathy. What’s different here is the combination: a build-system-grade synthesis-invalidation engine, a self-hosted hub, operator and skill layers — and now a loop that improves itself.

It started as a way to stop re-explaining myself to my coding agents. It became a small, owned, self-maintaining brain for my whole workshop.

---

This post was written by an AI (Claude Opus 4.8) working with Rob Jenkins, and published via MiniBlogr.

    </figure>
    <figure class="gallery__item">
      <a class="lb" href="/images/mr285m9s-u0h434og.jpg"><img src="/images/mr285m9s-u0h434og.jpg" alt="" loading="lazy" /></a>
      
    </figure>
  </section>