I built a second brain for AI agents. Then I made it prove it worked.

I've been building a second brain in Obsidian for my engineering work.

That sentence is dangerously close to productivity theater.

So I wanted evidence.

The idea is simple: AI coding agents are very good at reading a repository, but every new session starts with a memory problem. Decisions made last week, traps already discovered, verification techniques that worked, architectural boundaries that took an hour to understand. If none of that survives outside the conversation, the next agent pays for it again.

My second brain is supposed to change that.

Then Lorekeeper gave me a real test.

Not a benchmark

I deliberately didn't invent a retrieval benchmark.

I took the next actual piece of work in Lorekeeper: ticket 04.4. The problem was subtle. Lorekeeper generates stable IDs for captured URLs. If a future domain-specific identity rule claims a host that used to use the generic rule, an existing source could silently get a different ID.

That's the kind of problem where old reasoning should matter.

So the agent started from the Second Brain index instead of loading everything.

The relevant corpus was 181 files, 45,431 words, about 360 KB.

It retrieved seven files.

3,254 words. 28,984 bytes.

That's roughly 8% of the corpus by bytes, meaning about 92% of the plausible context never entered the working set.

That was the first result I cared about.

The interesting part wasn't the 92%

Context reduction sounds good, but deleting useful context is easy.

The real question was: did the retrieved knowledge change the work?

It did.

One old Lorekeeper note already contained the three policy options for evolving URL identity rules. Those became the actual options presented for the ticket instead of being rediscovered from scratch.

Another note recorded the principle that normalization should split identities rather than merge them because over-normalization can be unrecoverable. That directly shaped the argument against the highest-blast-radius migration option.

Another pointed directly to the frozen identity contract in the project documentation. The agent read thirteen lines instead of searching a 200-line document or grepping the whole repository.

And one general engineering note said that a guard test should be proven capable of failing.

That one caused an actual verification step.

The agent deliberately mutated the rule set, adding a fake third rule, and confirmed that the new guard test failed. Then it restored the code and confirmed green.

That's what I wanted the brain to do. Not answer trivia. Change an engineering action.

It also knew what not to reopen

This part might be even more useful.

A previous risk note said that three neighboring questions around digest stability, fragments and credentials had already been resolved in the previous ticket.

So the agent didn't investigate them again.

That is a boring win, which is exactly why I like it.

A lot of AI-assisted engineering waste isn't the model getting an answer wrong. It's the model spending context and time proving something the project already proved.

Memory should eliminate that tax.

Then the repo beat the brain

This is where the test got useful.

The Second Brain did not have the most important implementation fact.

The retrieved notes framed the policy problem well, but none of them recorded that the existing RULE_PREFIX mapping already encoded which rule minted an ID.

The agent only learned that by opening url.ts.

That changed the decision. One of the options suggested by the stored knowledge would have duplicated information the ID already carried.

So the brain did not replace the repository.

Good.

I don't want an AI system that trusts its memory more than current evidence. The brain should shorten orientation and preserve reasoning. The repository still gets the final vote on what the code actually does.

One of the notes was also partly stale. Again, good to know.

The router is already becoming the next problem

The project index itself was 17,691 bytes.

That was 61% of everything retrieved.

So the index-first pattern worked, but it exposed its next scaling problem: the router is getting expensive as the vault grows.

That's the kind of result I want from testing this system. Not "Second Brain works!" followed by a victory lap.

The honest result was a B.

Moderately strong evidence. Useful, not decisive.

The task was also unusually favorable because notes already existed about almost this exact deferred risk. On a completely novel task, the advantage could be much smaller.

What it actually saved

The field test ended with a pretty concrete ledger:

Seven Second Brain files read.

Zero repo-wide searches.

Two repository files opened before a confident implementation decision.

A pre-analyzed option space reused.

A direct pointer to an architectural contract reused.

A known verification technique reused.

And roughly 92% of the plausible Second Brain corpus kept out of context.

The implementation still required reading the code. It should.

That's the architecture I'm converging on:

Index first. Retrieve narrowly. Treat memory as evidence, not truth. Read the current code. Verify the real effect.

There is a funny loop here.

I'm building Lorekeeper because I want durable, provenance-aware knowledge.

I'm also using the Second Brain as evidence for what Lorekeeper should eventually become.

And now the project itself is generating the field tests that tell me whether the memory system is any good.

That's much more interesting to me than having an AI that "remembers everything."

I don't need everything.

I need the right seven files.