Issue 001 11.05.2026 Vol. I
Feature AI Knowledge Layer 8 min read

Thirteen wiki docs in one session

A graph went from four nodes to seventeen in a single afternoon. The work wasn't speed. It was composition.

By Ryan Gonzales
Co-author Bishop
Filed under AI / Knowledge Architecture / Build-in-Public
Date May 20, 2026
Thirteen wiki docs in one session

Friday morning my personal AI system had four wiki documents and six links between them. Friday afternoon it had seventeen documents and one hundred fifty-nine links.

The graph had gone from a sparse handful of nodes into something that actually looked like a knowledge layer. I want to walk through what made that possible, because I think the discipline underneath it is portable to anyone building their own AI-OS layer on top of a notes vault, an Obsidian graph, or whatever knowledge substrate they use to talk to their agent.

The mechanism wasn’t speed. It was composition.

i.The start state

The wiki had been accumulating slowly for about three weeks. Each doc was written in a single session, focused on whatever problem Bishop and I were solving that day. Identity drift. Voice calibration. The decision log. The auto-memory architecture. Four docs, written serially, each one good enough on its own.

The problem wasn’t quality. The problem was isolation. Each doc lived alone. Reading any one of them gave Bishop a clean slice of context, but the slices didn’t talk to each other. The graph was four dots and a few crossing lines. Visually it looked like the start of something. Functionally it was the start of nothing, because four documents without a taxonomy is just four documents.

I had been circling the idea that the wiki needed clusters for about a week. I hadn’t done anything about it because clustering felt like a separate project. A weekend job. A meta-layer pass. Something to do after the docs were “all written,” whatever that meant.

That framing was wrong, and I want to name how it was wrong, because the wrong framing is what kept me stuck.

ii.The composition rule

Mid-session that Friday, working on what was supposed to be a single new wiki doc, I noticed something. The doc I was writing kept wanting to reference two other docs I hadn’t written yet. The one underneath it pointed sideways at three more. Every doc in the wiki, the moment I tried to write it well, generated demand for sister docs around it.

That’s the composition rule. Each doc, written carefully, creates pressure to write the docs that orbit it.

I stopped trying to finish a single doc and started following the pressure. The first new doc surfaced two missing sister docs. Writing one of those sister docs surfaced three more. Writing one of those surfaced two more. Inside two hours I had a stack of nine drafts open. Inside three hours I had thirteen. By the end of the session there were seventeen total wiki docs and the graph view in Obsidian looked nothing like what it had looked like that morning.

The trap I had been in for a week was treating the wiki as a serial output. Doc one, then doc two, then doc three. Each one finished cleanly before the next one started. That’s how you write a book. It is not how you build a knowledge graph.

A knowledge graph wants to grow laterally. The docs are not the work. The cross-links between docs are the work. The docs are scaffolding for the cross-links.

— On composition The docs are not the work.The cross-links between docsare the work.

iii.The tier-load discipline

The composition rule only works if your agent isn’t reading every doc every time it loads context. If Bishop had to ingest the whole wiki on every session start, the multiplication wouldn’t help. It would suffocate.

CLAUDE.md, the master instructions file Bishop reads at session start, has a single line that makes the whole architecture work. Read only the topic doc, not all atomic memory underneath. The wiki has tiers. CLAUDE.md sits at the top. The auto-memory index sits below it. Individual atomic memory files sit below that. Synthesis docs in the wiki sit alongside, organized into clusters and pulled in only when the task touches their cluster.

Thirteen wiki docs in one session

The result is that Bishop carries the smallest possible amount of context per turn. The wiki can grow arbitrarily large without the per-turn cost growing with it. The graph can multiply nodes by four and links by twenty-six without the per-session ingestion cost moving at all.

This is the part of the architecture I think most people miss when they try to build an AI knowledge layer on top of a notes vault. They treat the vault as something the agent should always have access to. The agent loses the plot inside ten exchanges because half its context budget is spent ingesting documents that aren’t relevant to the current task.

Tiered loading is what makes the knowledge layer feel like a knowledge layer and not a swamp.

iv.The cluster taxonomy

The seventeen docs landed in six clusters. Architecture. Discipline. Operations. Integration. Brand. Creative. The taxonomy wasn’t designed up front. It emerged from sorting the docs that the composition rule had already produced.

Architecture covers the docs about how Bishop is built. Single-master-agent topology, automation policy, multi-agent criteria, the sub-agent roster. Discipline covers the practices. Verify-before-claiming-done. Done-means-safe-to-walk-away. Iterate-before-building. Operations covers the moving parts. Cost log priority. Session-start protocol. Audit trail. Integration covers the connectors. Google MCP. YouTube MCP. The two-email isolation pattern. Brand covers the public surface. Voice docs, content workflow, role-reversal discipline. Creative covers the universes. Corps of Shadows, the Watcher’s Veil, Null Protocol, Carolethea.

Six clusters is a small enough number to hold in working memory. It’s a large enough number to actually separate concerns. Every new doc I write now has an obvious cluster home, which means the graph stays organized as it grows, which means tomorrow’s docs can compose against today’s docs without me hunting for where they belong.

A taxonomy that emerges is more useful than a taxonomy you designed. The shape was always there. Sorting the docs surfaced it.

Composition isn'tadditive.It's multiplicative.Every new docis worth more than the last.

v.The graph result

Four nodes and six links became seventeen nodes and one hundred fifty-nine links. The math is not the headline. The headline is what the graph looks like rendered.

The before-state, screenshotted that morning, is a sparse star. Four dots scattered across the canvas. A couple of lines connecting some of them. Mostly white space. You could squint at it and convince yourself a knowledge layer was forming. Standing back from it, you would not have called it one.

The after-state, screenshotted that night, is dense. Six visible clusters, each a tight knot of docs cross-linking inside the cluster, with thinner lines reaching across clusters where concepts genuinely bridge. It looks like a brain section. Not because I made it look that way, but because that is what a knowledge graph that has been composed correctly actually looks like.

I want to be precise about what changed. The number of nodes went up by a factor of four. The number of links went up by a factor of twenty-six. Composition isn’t additive. It’s multiplicative. Every doc you add to a graph that’s organized this way creates cross-links to every other doc in its cluster, and to selected docs across clusters. The marginal value of each new doc keeps rising as the graph grows.

That is the property that makes the knowledge layer worth building. Without composition, every new doc has the same value as the first one. With composition, every new doc is worth more than the one before it.

vi.What to take from it

If you’re building an AI-OS layer on top of a notes vault, here are the three pieces that mattered.

First, write each doc with composition in mind. Don’t try to finish one doc before starting the next. When you notice the doc you’re writing wants to reference docs that don’t exist yet, follow the demand. Open the sister doc. Stub it. Cross-link. Come back to the original. The pressure is the signal.

Second, build tiered loading into your agent’s instructions before the wiki gets large. The discipline has to exist before it’s load-bearing, because by the time it’s load-bearing you’ll already be drowning. CLAUDE.md or its equivalent should explicitly tell the agent to read the cluster-relevant synthesis doc, not the atomic files beneath it. The agent reads what you tell it to read. Tell it to read narrow.

Third, let the taxonomy emerge. Don’t pre-design the clusters. Write the docs the composition rule produces, then sort them. The shape that surfaces is more accurate than the shape you would have invented, because it’s grounded in what you actually wrote rather than what you imagined you would write.

The day ended with a graph that looked like the start of something real. Not because I worked faster. Because I stopped writing docs in series and started writing them in composition, and because the tier-load discipline meant Bishop could carry that growth without losing the plot.

The knowledge layer is not the docs. It’s the links between them. Build for the links, and the docs take care of themselves.

Drafted with Bishop, my AI partner.
Words picked, edited, and approved by me.