Before you build AI agents, build your company brain first

The valueIQ company brain is a structured knowledge base that every agent reads before producing any output. Think of it less as a database and more as a carefully curated library, one that an agent reads from cover to cover before it does anything in your company’s name.

Most internal knowledge is organised for humans: folders, documents, wikis. Agents don’t browse. They read, reason, and produce. The Brain is organised for that pattern. Every file covers one thing completely: who we sell to, what we believe, who our personas are, what use cases we support. Each has a clear label at the top that tells the agent what it’s reading and when it was last updated.

The obvious first move was to take all our company documents and make them searchable. You’ve probably heard this described as RAG (Retrieval Augmented Generation): the idea that you load everything into a searchable database, and when the agent needs to know something, it pulls out whatever seems most relevant.

It sounds like the right approach. But in practice, we ran into three problems that kept getting worse.

The first: the agent only retrieves what looks similar to the question it was asked. If a critical brand rule is worded a bit differently from the prompt, it may never surface. The agent proceeds without it and produces something that’s confidently wrong.

The second: a searchable database doesn’t distinguish between your positioning from 18 months ago and the version you finalised last quarter. Both show up as equally relevant. The agent has no way to know which one you use.

The third: not everything in a company’s knowledge is equally important. Your core beliefs matter more than a single persona file. Your brand rules outrank a draft campaign brief. A searchable database treats everything as equally weighted, with no concept of “read this first and let it govern everything else.”

Andrej Karpathy, one of the original researchers at OpenAI and one of the clearest thinkers on how to build with AI, published a short but influential piece on GitHub about maintaining a personal knowledge base for LLMs.

His argument was almost too simple: instead of building complex retrieval systems, just maintain a well-structured set of plain text files and read them directly into the model. Curate them carefully. Keep them current. Feed them in a deliberate sequence. The model reads the whole thing and reasons from it. No retrieval, no searching, no probability. Just reading.

It sounds almost too simple. That’s the point.

What clicked for us: retrieval makes sense when you don’t know what’s relevant. When you do know what an agent needs, giving it exactly those files in a deliberate order is more reliable than letting it search for them.

We read that piece and immediately recognised what we’d been missing. We didn’t have a retrieval problem. We had a curation problem.

We organise the Brain as a collection of plain text files, one per topic. Each covers one thing completely and stays tightly scoped. No sprawling documents, no nested wikis, no slide decks.

The most important structural decision: keep two versions of every piece of source material. The raw version is the original: a verbatim transcript, a source document, a value model we built. The wiki version is the curated summary that agents actually read. The originals are archived and never touched. The summaries stay current. Agents read summaries. Humans update summaries when the source material changes.

Here is what ours actually looks like:

company-brain/
├── manifesto.md ← what we believe and what we reject
├── brand-vision.md ← voice, tone, words we use and avoid
├── icp.md ← who we sell to
├── goals.md ← current priorities and targets
├── AGENTS.md ← the mandatory read order for every agent
├── log.md ← an append-only record of every change
│
├── personas/ ← seven buyer and user profiles
├── use-cases/ ← ten use cases, each with an explicit status
├── messaging-positioning/ ← how we position and what we say
├── products/ ← what we've built and what's still on roadmap
├── competitive/ ← battle cards for each competitor
├── founders/ ← voice rules for each of the four founders
├── guidelines/ ← discipline-specific rules for each agent
├── inspiration/ ← published examples for tone calibration
│
└── raw/ ← original source material, archived forever
├── transcripts/
└── value-claims/

output/ ← everything the agents produce
├── emails/
├── sequences/
└── blog/

That’s years of thinking about how a B2B SaaS company works, compressed into a folder structure. Every folder exists because an agent needs it. Nothing is there for the sake of organisation.

One folder in the architecture deserves its own explanation.

Value claims are the foundation of everything a value-oriented agent does. They answer the question every serious buyer eventually asks: how exactly does your product create economic value for a customer like ours? Not in the abstract. With specific drivers, equations, and improvement claims that connect the two.

Ours consists of two parts. A value narrative: a structured explanation of how valueIQ creates value, written to survive a conversation with a financially literate buyer. And a value model: the quantitative foundation behind the narrative, built around value drivers, the equations that calculate their impact, and the improvement claims that give each driver its defensibility.

Both conform to The Value Project value-models standard (v1.0), an open standard for expressing product value in a format precise enough for a CFO’s team and structured enough for an AI agent to reason from.

When an agent builds a business case, it reads from these files first. The value model prevents it from inventing numbers. The value narrative prevents it from turning those numbers into a spreadsheet nobody reads.

If you want to build your own, you can do it for free. Create an account at valueIQ.ai and the agents will walk you through both the narrative and the model. The output is yours to use directly in your own company brain.

Every agent reads a fixed sequence of files before producing any output: not whatever seems relevant in the moment, but a set order that’s documented and enforced.

Consistency, we found, matters more than cleverness. Reading the manifesto before the messaging framework means the output is grounded in what we believe before it touches what we say. Reading the ideal customer profile before the persona files grounds it in who we sell to before the specific people we sell to. The sequence creates coherence across everything the agents produce.

It also makes accountability concrete. If an agent produces something that violates a brand rule, we can trace it directly: did the agent read the brand file? If yes, the rule wasn’t clear enough. If no, the process broke down somewhere. Either way, we know exactly what to fix.

We run a separate agent for each part of the business: Marketing, Sales, Product, Customer Success, and others. Each reads the same shared foundation (our beliefs, our brand, our customer profile, our messaging) but then loads the files specific to its job on top of that.

A marketing agent doesn’t need the sales objection handling library. A sales agent doesn’t need the product feature brief template. Keeping each one focused means the output reflects that focus from the very first sentence it produces.

Interacting with the Brain happens through a set of commands. Here are some examples of what we use every day.

Creating content:

/sales: “Write a CRO-focused cold email for a Series B SaaS company that just hired a new VP Sales.” The agent reads the full Brain, matches the request to our ICP and personas, checks the messaging framework, and writes in the right founder’s voice with all brand rules applied.

/marketing: “Summarise our value claims in email form.” Reads the Brain, finds the right value proposition to anchor to, checks the manifesto for consistency, and presents a draft.

/edit: “Run this draft through the editorial test.” Applies a six-question editorial standard line by line, annotates every line that fails, and produces a full rewrite.

/pmm: “Write a battle card for our primary competitor.” Reads the competitive file, applies the positioning framework, and produces an enablement-ready comparison.

Testing and checking:

/test-message: “Run this email through 100 synthetic CRO personas.” Returns individual reactions by segment, an inside-out/outside-in verdict on whether the messaging connects, rewrite suggestions, and a Go / No-Go.

/drift-check: “Check this LinkedIn post.” Returns a severity-rated report of anything that contradicts the Brain: wrong category claim, forbidden language, a roadmap feature described as available today.

Managing the Brain:

/ingest-transcript: Paste in a discovery call transcript. The agent extracts structured intelligence from it, proposes specific updates to the right files (add this pain to the ICP, add this objection to the persona file, update the competitive notes), and waits for confirmation before changing anything.

/update-icp, /update-messaging, /update-persona, /update-use-case: Each follows the same pattern: read the current file, apply the change, update the timestamp, stamp the log. Every update produces a clean version history entry.

The commands are what make the Brain useful day to day. Without them, it’s a well-organised folder of files. With them, it starts to feel like an operating system for how we communicate.

One of the most useful things we built into the Brain isn’t a fact. It’s a status field.

Every use case and capability has an explicit status: live, in build, or on roadmap. Agents cannot describe roadmap capabilities as available today. It’s a hard rule, and one that feels obvious until you see what happens without it. Without explicit status fields, an agent reads context that says “we’re planning to build this” and, reasoning from intent, describes it as something that exists right now.

We found that telling an agent to be accurate about what’s live doesn’t work. What works is giving it a data model where inaccuracy isn’t possible.

Status honesty has to be structural, not instructional.

Every discovery call, every customer conversation, every competitive signal has a path into the Brain. The ingest command takes raw input and runs a structured extraction: what pains came up, what objections were raised, what quotes are worth preserving. It then proposes targeted updates across the relevant files.

The pattern is extract, propose, confirm, apply. The agent never changes anything without human confirmation first. But it handles all the extraction and matching work, which turns what used to be a 90-minute curation task into about five minutes.

The result is a Brain that compounds. The more you use it, the more it knows. The more it knows, the better every agent that reads it performs.

The Brain lives in a version control system. Every change is recorded with a description of what changed and why. The history is permanent and searchable.

If an agent produces output that surprises us, we can go back and see exactly which version of the Brain it was working from, what had changed in that version, and who made the change. Nothing ends up unexplained.

There is also a running log inside the Brain itself: an append-only record of every command that changed it. The version history tells you what changed at the file level. The log tells you why: which command ran, what conversation triggered it, what was updated. Together, they mean no change is ever mysterious.

The instinct when building with AI is to focus on the models, the prompts, the workflows. The Brain is the part that gets skipped.

Agents are only as trustworthy as what they know. Structure is what makes the knowledge trustworthy.

The Brain isn’t documentation or a training dataset. It’s the thing an agent reads before it says anything in your company’s name.

Build the brain first.

Building the Brain was one of the most valuable things we’ve done at valueIQ, not just for the agents but for the clarity it forced. When you have to write down what you believe, who you sell to, and what makes you different in a way that an AI agent can reason from it, you quickly find out what you know versus what you’ve been assuming.

If you’re thinking about building something like this for your own company, I’m genuinely happy to talk. We’re still learning, still iterating, and I think the more people working on this problem and sharing what they’re figuring out, the better.

Reach out on LinkedIn or drop me a note at [email protected]. I’d love to compare notes.

A structured knowledge base of tightly scoped plain text files that every AI agent reads before producing output. It covers what the company believes, who it sells to, how it positions, what its personas care about, and what its product actually supports today. It is organised for how agents work (read, reason, produce), not for how humans browse.

RAG retrieves whatever looks most similar to the question, so a critical rule worded differently from the prompt can be missed, outdated files rank alongside current ones, and everything is weighted equally. A company brain is curated instead of retrieved: agents read a fixed set of files in a deliberate order, so what matters most always gets read first. Retrieval makes sense when you don’t know what’s relevant. When you do know, curation is more reliable.

Start with a manifesto (what you believe and reject), brand and voice rules, an ideal customer profile, personas, use cases with explicit status fields, messaging and positioning, value claims, and a read-order file that tells every agent what to read and in what sequence. Keep raw source material (transcripts, original documents) archived separately from the curated summaries agents actually read.

Structurally, not with instructions. Give every use case and capability an explicit status (live, in build, or on roadmap) and enforce a hard rule that agents cannot describe roadmap items as available today. Telling an agent to be accurate doesn’t work. Giving it a data model where inaccuracy isn’t possible does.

Give every input a path in. Ingest call transcripts, customer conversations, and competitive signals; have an agent extract the intelligence and propose targeted updates; confirm before anything changes. Keep the whole thing in version control with an append-only log, so every change is traceable to a command, a conversation, and a person.

It’s plain text files, not infrastructure, so start by writing down what you believe, who you sell to, and how you talk. The hardest part is usually the value claims: the drivers, equations, and improvement claims behind how your product creates economic value. You can build that piece for free at valueIQ.ai, and the output is yours to drop straight into your own company brain.