Knowledge Base (AI Context)

Every LLM conversation starts from zero. The model has no memory of what you worked on yesterday, what decisions you made last week, what conventions your codebase follows, or what your goals actually are. You can get useful work done within a single session, but the moment you close the window, that context is gone.

This is the core limitation that an AI knowledge base addresses: it’s the mechanism for giving a stateless system a persistent memory of who you are, what you’re building, and how you work.

The Problem It Solves

Without persistent context, every conversation requires context reconstruction. You spend the first five minutes re-explaining your project, your tech stack, your naming conventions, what you tried last time and why it didn’t work. That’s not just inefficient — it’s error-prone. You forget to mention things. The model makes reasonable assumptions that don’t match your context. You get generic answers when you needed specific ones.

The problem compounds as projects grow. A simple blog might need a paragraph of context. A multi-repo system with complex entity relationships, custom tooling, and accumulated architectural decisions needs structured documentation that would take twenty minutes to narrate from scratch each time.

What Goes in a Knowledge Base

The content falls into a few categories:

Project structure: What exists, where it lives, how it’s organized. For a software project: repo structure, key files, what each component does. For a business: which entities own which assets, which tools do what.

Conventions and standards: How things are named, how code is formatted, what patterns are preferred, what’s explicitly off-limits. This is the context that makes the difference between generic code generation and code that actually fits your system.

Entity relationships: The connections between components, companies, people, and projects. Which company owns which product. Which repo feeds which site. Which decisions were made at the project level vs. the system level.

Decision history: Why things are the way they are. “We use static generation because dynamic rendering added complexity without meaningful benefit” is much more useful than just knowing the tech stack. Decision history prevents you from re-litigating resolved questions.

Current status and priorities: What’s done, what’s in progress, what’s blocked, what’s next.

Implementation Patterns

The simplest implementation is a set of Markdown files that get loaded into the context window at the start of each session. The model reads the relevant files, understands the project, and proceeds with that context active.

More sophisticated implementations use hierarchical structures: a root entry file that orients the model and points to detailed documentation for specific subsystems. The model reads what it needs for the current task rather than loading everything at once.

For multi-project environments, a central knowledge repository with per-project context files scales better than documenting everything in a single file. The model can navigate to the relevant project context when switching between work.

This site uses a system called ClaudioBrain — a dedicated repository that holds context files for all active projects, company entity maps, infrastructure documentation, and working style guidelines. The CLAUDE.md file in each project repo is the entry point; it orients the model and points to deeper context in ClaudioBrain when needed. Any non-trivial session starts with loading that context.

What to Store vs. What to Derive from Code

Not everything belongs in a knowledge base. Configuration that’s readable directly from code files doesn’t need to be documented separately — the model can read the code. What belongs in the knowledge base is context that isn’t visible in the code: the reasoning behind decisions, the relationships between components, the goals and constraints that shaped the architecture.

A useful test: if someone completely new to the project could answer this question by reading the codebase, it probably doesn’t need to be in the knowledge base. If they couldn’t — if the answer requires knowing things that aren’t written down anywhere — that’s what belongs in the knowledge base.

How It Changes the Interaction

The difference between working with and without a knowledge base is qualitative, not just quantitative. With context, you stop managing the model’s understanding of your situation and start having substantive conversations about the actual problem. Questions like “should I restructure this component?” can get specific, grounded answers instead of generic architectural advice.

The model becomes effective at the same kinds of tasks a well-onboarded colleague handles well: making decisions consistent with established patterns, flagging when something deviates from convention, remembering what was decided and why. Without the knowledge base, you’re working with a smart generalist. With it, you’re working with someone who knows your project.