Most founders think building a "second brain" with AI means dumping documents into a folder and hoping Claude figures out the rest.

That is not a system. That is a mess with a nice name.

The real shift happening right now — enabled by frontier models like Claude with extended context and multi-step reasoning — is not about storing information. It is about building a structured AI operating context: a layered architecture where a routing file directs the model to the right knowledge, each business function has its own mapped folder, and the whole thing connects to RAG pipelines, multiple LLMs, and a management UI for your agents.

In this issue, I will break down exactly how to build that system from the ground up.

The common pattern looks like this: a founder creates a big context.md file, copies in their company description, a few SOPs, some product notes, and starts prompting Claude with it.

For the first few days, it feels powerful. Claude seems to "know" the business.

Then it breaks.

The model starts hallucinating details from the wrong department. A customer support instruction bleeds into a sales response. The pricing policy from six months ago overrides the current one. Nobody can tell which folder is authoritative.

The problem is not the model. The problem is that the system has no routing logic, no folder hierarchy mapped to actual business functions, and no way to distinguish what is reference material from what is an active instruction.

A functional AI operating context solves all three problems.

This is the entry point for every agent and every workflow. Think of it as the operating manual for how your AI should navigate the rest of the system.

A well-built routing file does three things:

Describes the business. Not in a vague, marketing sense — in an operational sense. Who are the customers. What are the core services. What markets are served. What the company does not do. This grounding prevents the model from making assumptions that do not fit your business reality.

Maps queries to folders. When a query comes in, the routing file tells the model: if this is about pricing, go to /commercial/pricing.md. If this is about client onboarding, go to /operations/onboarding/. If this involves a contract review, reference /legal/contract-templates/ and also load /reference/compliance-rules.md.

Sets agent behavior rules. Tone, escalation logic, output format expectations, when to ask for human review, and when to proceed autonomously.

The routing file is not a summary of your business. It is a structured decision tree written in plain language that a language model can follow reliably.

Each folder in the system corresponds to a real business function — and the folder structure mirrors the actual workflow of that function.

A practical folder map for a small AI consultancy or productized service business looks like this:

The key principle: every folder maps to a real process, not just a topic.

This matters because AI agents do not think in topics. They execute tasks. When a task involves generating a client proposal, the agent needs to navigate from the routing file → /commercial/offer-descriptions.md → /commercial/pricing.md → /operations/project-delivery-sop.md → output a draft → flag for human review.

That traversal only works if the folder structure is built around workflows, not around what feels organizationally tidy to a human.

The reference layer is separate from the functional folders for an important reason: it contains information that is used across multiple workflows but belongs to none of them specifically.

This layer includes:

Company glossary. Every acronym, product name, service tier, and internal term defined in one place. This single file eliminates a significant percentage of model confusion in multi-step tasks.

Brand voice rules. Tone, vocabulary restrictions, formatting preferences. If your brand never uses em dashes and avoids AI-sounding phrases, those rules live here — and every content-generation task references this file.

Competitor and market notes. Not for the model to make competitive claims, but so that when generating positioning language or analyzing an opportunity, it has accurate context about the landscape.

The tools folder is equally important. This is where you document the MCP servers your agents can call, the n8n workflow configurations they connect to, and the skill definitions that tell each agent what it is authorized to do. Without this layer, your agents operate with undefined capabilities — which means either they hallucinate tool calls or they fail silently.

This is where the system moves from a well-organized folder structure to a live operating context.

RAG (Retrieval-Augmented Generation) ensures that when an agent needs a specific piece of information — a past proposal, a client preference note, a specific compliance clause — it retrieves the most relevant content dynamically instead of stuffing everything into context at once. This keeps context windows clean, reduces hallucination risk, and makes the system scalable as the knowledge base grows.

The practical implementation for a solo operator or small team: use Supabase with pgvector for document embeddings, and build retrieval calls into your n8n workflows. Each agent task triggers a vector search before loading the full prompt, so the model always works with the most relevant slice of your knowledge base.

Multi-LLM routing means not every task runs on the most expensive model. A structured routing layer decides:

This is not about cost optimization alone. It is about fitting the right model to the right task so quality is consistent and the system does not bottleneck on one API.

Agent management UI is the operator's control panel. For a solo founder running multiple agent workflows, a simple dashboard that shows which agents are active, what tasks are in queue, where human review is required, and what the last outputs were is the difference between a system you trust and a black box you are afraid to run.

You do not need to build this from scratch. Tools like n8n's workflow dashboard, combined with a lightweight Supabase-backed status tracker and a simple Next.js or Bubble.io front end, give you operational visibility without months of development.

The biggest failure mode in AI operating systems is not bad architecture at launch. It is entropy over six months.

Most teams start with clean folders and good intentions. Then one person saves a file in the wrong place. A pricing update gets made in the routing file but not in the commercial folder. A new service gets added to the offer descriptions but nobody updates the agent skill definitions. Three months later, the model is confidently generating outputs based on outdated information, and nobody knows which file is authoritative.

This is called context rot. And it kills more AI systems than technical complexity ever does.

Preventing it requires three operational habits built into the system from day one.

A single source-of-truth rule. Every piece of business information lives in exactly one place. The routing file points to it. Other files reference it. Nothing duplicates it. When the pricing changes, one file gets updated, and every agent task that touches pricing is automatically current.

A changelog discipline. At the bottom of every functional folder's main file, maintain a simple changelog. Date, what changed, who approved it. This takes thirty seconds per update and creates an audit trail that makes debugging agent errors fast. When a proposal comes out wrong, you check the changelog before you assume the model failed.

A quarterly folder audit. Once every three months, run every folder against the current state of the business. Archive anything that is no longer active. Update anything that has drifted. This is the equivalent of clearing technical debt in a codebase — it keeps the system sharp and prevents the model from drawing on stale context.

A system built with these habits in place does not just work at launch. It works better at month twelve than it did at month one, because the knowledge base has grown and the routing logic has been refined by real usage.

Let us say you run a small B2B consultancy. A new inquiry arrives by email.

The intake agent reads the email, loads the routing file, retrieves the relevant commercial and operations files, classifies the inquiry by service type and budget signal, and generates a structured lead summary with a recommended next step.

That output goes to a queue in the agent management UI. You review it in under two minutes, approve the recommended action, and the system drafts a proposal using the /commercial/proposal-templates/ folder, cross-referenced with /commercial/pricing.md and the brand voice rules from /reference/brand-voice.md.

The draft comes back to you for a final human review before sending.

The whole cycle — from email received to proposal draft ready — takes under ten minutes of total human time. The quality is consistent because every step references the same structured knowledge base.

That is what a functional AI operating context looks like in production.

The temptation is to build the entire system before using it. That is how it stays a project forever.

Start with three files this week:

1. A routing file. Write two paragraphs describing your business operationally. Then add a simple mapping: "If the query is about X, load Y file." Five mappings is enough to start.

2. One functional folder. Pick the business function you automate most often — likely sales, content, or client delivery. Build out that folder with the documents and SOPs that already exist. Do not write new content. Organize what you have.

3. A reference file. Start with your company glossary. Fifty terms is plenty. This single investment pays back every time you run an agent task.

Once these three files are in place and you have run ten to fifteen real agent tasks against them, you will know exactly what the system needs next. You will see where the model gets confused, which folders are missing, and which reference documents are doing the most work.

Build from evidence, not from planning.

A well-built AI operating context does not just make you faster. It changes what you can offer.

Because the system holds structured business knowledge, you can spin up a new agent task for a new client workflow without rebuilding context from scratch. Because the RAG layer handles retrieval, the knowledge base can grow without degrading performance. Because the multi-LLM routing is explicit, you own the architecture and can swap models as the market evolves without rebuilding everything.

This is the "tool-agnostic" principle applied properly. You are not betting on one model staying optimal forever. You are building a knowledge structure and routing logic that any capable model can operate.

The IP is yours. The system compounds. The leverage scales.

Pick one business function — sales, content, operations, or client delivery.

Write down:

Map those three things into a folder. Add a five-line routing entry to your context file.

That is your first functional module of a system that can run your business.