Building an AI Second Brain for Enterprise Architecture

Enterprise architecture has a memory problem. Decisions live in slide decks, the application inventory lives in the CMDB, the reasoning lives in someone's head, and every new question starts with an afternoon of digging. So in 2024 I started building an AI-maintained knowledge base for my EA practice — an Obsidian vault that Claude reads, writes and keeps honest, with me directing. Here is what actually worked, and what I would tell anyone starting one.

The shape: three layers and a contract

The pattern lines up with the LLM wiki idea Andrej Karpathy later published: three layers, strictly separated:

• raw/ is immutable. Exports, transcripts, vendor docs, research. The AI reads it and never edits it. If a fact is wrong, the source is still the source.
• wiki/ belongs to the AI. Entity pages for applications, capabilities, decisions, vendors and standards, each with typed frontmatter. I review; the model writes and cross-links.
• CLAUDE.md is the operating contract. The schema, the page templates, the rules and the rituals. It is the most important file in the vault, and it co-evolves with the work.

That separation is the whole trick. When the AI is wrong, you can see exactly where it went wrong, because the evidence it worked from is still sitting untouched next to what it wrote.

Sessions forget. The vault must not.

An AI session has a context window, not a memory. The first month taught me that anything living only in the conversation is gone the moment the session ends. The fix was boring and it works:

• One resume page. NOW.md holds at most five active threads, each with a next action, a blocker and an absolute due date. It is the only page I open on a cold start.
• A close ritual. Before a session ends: run the validators, update NOW.md, append to the log, commit. State never ends a session living only in context.
• A boot ritual. Contract, then NOW.md, then the open backlog, then the last log entries. Same order every time, so a resume after two weeks rebuilds the same working state as a resume after two hours.
• Budgets on the boot files. Those pages are read whole on every start, so their size is paid on every session. A script flags when they grow past budget, and trimming follows a fixed order.

Split the work by how much thinking it needs

Most upkeep is deterministic: pull an export, diff it against a register, update status, log, commit. That does not need the most capable model. I run two tiers over one vault — an architect session on the strongest model for schema changes, synthesis and decisions, and an operator session on a cheaper model for repeatable, bounded skills and day-to-day capture. The vault is the shared memory; git and the resume page are the coordination layer. Cost dropped and quality went up, because each tier stays in its lane.

Never let the generator grade its own work

The single most valuable skill in the repo is a skeptical reviewer. It is a separate pass that assumes the artifact is wrong until proven otherwise, and it settles doubt by running things — validators, greps against cited sources, re-checking canonical figures — rather than by reading for plausibility. A model reviewing its own output in the same breath tends to agree with itself. A model told to find the defect finds defects.

Cite, don't restate

Synthesis is where drift hides. A digest copies a count from an entity page, the count changes, and the digest is now confidently wrong. Every durable figure now lives in exactly one canonical place, and anything that summarizes it links there instead of copying the number. Summary pages also carry a list of the pages they were derived from, so any claim can be traced back to evidence in one hop.

Verify from contents, not from the surface

The lessons I paid most for were all the same lesson. A green test suite encoded my assumption of an upstream schema instead of the real rows, so it passed while every traversal would have failed. A file looked truncated because it ended mid-sentence; its history showed it always had. A push was reported as deployed while ten consecutive deploys had failed quietly. In each case the metadata supported a hypothesis and I treated it as a verdict. The rule now: open the thing, read the real rows, check the run result — before you say done.

A starter CLAUDE.md you can copy

This is a trimmed version of the contract that runs my vault. Put it at the root of an empty folder, change the names, and let it grow as things break.

# CLAUDE.md - Knowledge Base Operating Contract

## Mission
You maintain a structured, cross-linked knowledge base for <team/practice>.
I curate, ask questions and direct. You read sources and write the wiki.

## Layers
- raw/   Immutable sources (exports, transcripts, docs). Read only. Never edit.
- wiki/  Pages you own. Create, update, cross-link and lint them.
- CLAUDE.md  This contract. We change it together.

## Special files in wiki/
- index.md  Catalog of every page, by type. Update on every change.
- inbox.md  Open questions and follow-ups.
- NOW.md    What is in flight right now. Read it first on every session.
- log/      Append-only activity log, one file per month.

## Rules
1. Enrich before you create. Check index.md for an existing page first.
2. Cite, don't restate. Each figure lives on one canonical page; link to it.
3. Every page has frontmatter: title, type, status, owner, updated, sources.
4. Every new page gets at least two inbound links.
5. Flag contradictions with a callout. Never silently overwrite.
6. Proceed on reversible edits. Stop and ask before deletes, production
   writes, or anything that changes a validated baseline.

## Session rituals
- Open: read CLAUDE.md, NOW.md, inbox.md, the last log entry.
- Close: update NOW.md, append to the log, list files touched, then commit.

What I would tell you before you start

• Write the contract first. A page schema and three rules beat a thousand clever prompts.
• Enrich before you create. Most new material belongs on a page that already exists. Duplicates are how a knowledge graph dies.
• Keep humans on the irreversible steps. Reversible edits, the AI proceeds. Production writes, deletes and anything that changes a validated baseline, it stops and asks.
• Use git as the real memory. Commit every session. It is the audit trail, the conflict resolver and the undo button.
• Put your frameworks in the repo. Grounding answers against a local copy of the reference material, rather than the model's recall, removed an entire class of confident mistakes.

I am extracting the reusable core of this into an industry-agnostic template, so the next team does not start from a blank folder. More on that soon.