Build your own brain

Define scope and governance

Decide what this brain covers before you touch a tool. What's in, what's never in, who sees what, and the questions it should answer when it's done.

The most expensive mistake happens here, and you won't find out until stage F.

Start with coverage. One project? One client? The whole business? Pick something. "Everything" isn't a scope, it's a decision you're putting off.

Then inventory what you've actually got. Where the documents live, how many, what formats, how much of it is still current versus how much is three years stale. Most people find it more scattered than they expected.

The part that gets skipped: what should never go in. Drafts. Scratch notes. Anything you'd wince at if it surfaced in an answer six months from now. Write it down properly, because in stage B it becomes a policy the pipeline enforces.

Who should see what? This one matters more than it looks. A brain shared across a team can hand the wrong document to the wrong person, and it will look like it's working perfectly while it does. Access is a stage A decision. If you leave it until stage E you'll be retrofitting.

Last thing. Write down what "good" looks like. A handful of real questions this brain should be able to answer, and a couple it should decline because the material genuinely isn't there. You'll test against these in stage F, and without them the question "does it work?" doesn't have an answer.

Prepare the source of truth

Get everything into one reliable place. Kill duplicates, decide which copy is real, give every document a stable identity. A messy source means a messy brain, at scale.

Your brain is only as trustworthy as what feeds it, so this stage is about making the feed trustworthy.

Consolidate first. Scattered drives, old folders, three versions of the same SOP. Get it into one location the sync process can reach every single time, not most of the time.

Deduplicate. When you find the same document twice, and you will, decide which copy is authoritative and archive the other. If you index both, the brain will happily cite the outdated one and you won't know until it does.

Turn the stage A exclusion list and access decisions into policies the stage D pipeline can apply automatically. Not a note in a document somewhere. Something the system reads.

Give every document a stable identifier and a small amount of metadata: title, source path, type, modified date, who's allowed to see it. Without stable identifiers you can't tell later whether a document was updated or replaced, you can't delete cleanly, and your answers have nothing to point back to.

Then confirm whatever runs your sync can actually get to the source. Test the connection now rather than discovering it's broken when the first ingest fails overnight.

Choose your foundation

Now pick tools, and only now, because you know what you're building for. Retrieval store, embedding provider, where the sync runs, how you'll enforce access.

Notice the order. Tools come third. By now you know your volume, your sensitivity, your access model, so you can choose against those instead of against whatever's trending this month.

Four decisions.

Where chunks live: a vector database or retrieval store. Free tiers on several are generous enough for a real first version.

How text becomes searchable: an embedding model and provider. It's replaceable, but not casually. Changing it later means regenerating every embedding, rebuilding or migrating the index, and re-running your test set. Pick something sensible now rather than assuming you'll swap freely.

Where the work runs: ingestion and sync need to execute somewhere. A scheduled script is enough to start. You don't need a server on day one.

How access is enforced: you decided who sees what back in stage A. Now decide how the system actually enforces that at query time, because the exclusion list only governs what goes in, not what comes out.

The trap in this stage is spending three weeks comparing vector databases. They're more alike than they are different. Pick one. If it turns out wrong you'll know by stage F, and it's cheaper to fix then than to keep deliberating now.

Build and run the ingestion pipeline

Parse, chunk, embed, store, with exclusion policies and access metadata applied at write time, and permissions enforced at query time. Run it once against everything, then reconcile what actually got in.

This is where documents become retrievable.

Parse and chunk. Break each document into pieces small enough to retrieve precisely but large enough to carry meaning. Chunking that follows the document's own headings is often a good starting point for structured documents. It tends to preserve meaning better than cutting at a fixed size that can split mid-thought.

Embed each chunk. Store the chunk, its embedding, its metadata, and a reference back to the source document. That reference is what lets answers cite their sources later, so don't drop it to save a column.

Apply your exclusion and access policies here, at write time. A document that shouldn't be in the brain never gets embedded, and a restricted document carries its access metadata into storage. That's half the job, not the whole thing. The other half happens in stage E: every query gets filtered against the requester's current permissions, because permissions can change long after a document was ingested. Write time keeps the wrong material out of the corpus. Query time keeps it out of the wrong hands. You need both.

Now run it. The full first ingest, against everything in scope. Treat this as its own step. It's easy to build the pipeline, test it on ten files, and assume the rest will follow.

Then reconcile. What did you expect to index, what got indexed, what was skipped, what failed. If the numbers don't match your stage A inventory, find out why before you go further. A silent gap here becomes a confident wrong answer later.

Make it queryable by an AI

Build retrieval and ranking, return evidence with every answer, expose it so an AI can call it, connect it to the assistant you actually use. Enforce permissions on every query.

Your brain has content. Now it needs to answer.

Build retrieval and ranking. Semantic search over your store, returning the most relevant chunks. Hybrid retrieval, semantic plus keyword, usually beats either on its own for business documents where exact names and terms matter.

Return evidence, not just answers. Every result should carry its source. An answer without a citation is an assertion; an answer with one is something you can check. That's the whole difference between a brain you trust and one you second-guess every time.

Expose it. An MCP server if you want it inside Claude, ChatGPT, or custom agents. A simple API if you're wiring it into something else.

Connect it to the assistant you actually open every morning. The real one, not a sandbox you'll forget about.

Enforce permissions at query time. Whoever's asking, the brain returns only what they're allowed to see. You set this up in A and C. This is where it does its job.

Verify it actually works

Test retrieval separately from answers. Did it find the right source, or just produce something plausible? Check it grounds, declines when it should, and never leaks. Keep the test set.

"It works" isn't one test. It's five. Most builders run one and call it done.

Does retrieval find the right source? Ask a question from your stage A list. Before you read the answer, look at what got retrieved. Was the correct document there, and ranked high enough to matter? A plausible answer built on the wrong source is worse than no answer, because you'll believe it.

Is the answer grounded in that evidence? Now read the answer. Does it actually draw on what was retrieved, or is the model filling gaps from general knowledge? The citation should match the claim.

Does it decline correctly? Ask the questions from stage A that the material doesn't cover. The right response is "I don't have that," not a confident guess. A brain that never says no is a brain you can't trust when it says yes.

Did the exclusions hold? Try to retrieve something you excluded. Try it as a user who shouldn't have access. If anything comes back, that's the first thing you fix, before anything else on this list.

Is anything important missing? Walk your inventory and spot-check that key documents are present, indexed, and traceable to their source.

Then keep the test set. Write it down. You'll run it again in stage G every time the corpus materially changes, and it will catch things you'd never notice by hand.

Keep it current and trustworthy

Sync new, changed, moved, deleted, and newly excluded documents. Deletion matters as much as addition. Never leave the index half updated. Know when the automation stops.

A brain that isn't maintained rots.

Sync everything that changes, and "changes" means more than "new files." Modified, moved, renamed, deleted, newly excluded. A brain that only ever adds will confidently retrieve a document you deleted three months ago, or a policy you superseded last quarter. Deletion isn't an edge case. It's half the job.

Never leave the index in a mixed state. A sync that fails halfway can leave queries seeing an inconsistent mixture of old and new document versions. Either publish completed syncs atomically, so a sync only goes live once it's fully done, or recover cleanly from partial runs. Just noticing the problem doesn't fix it.

Know when the automation stops, because it will. A token expires, a path changes, a job fails without complaining. It doesn't need to be sophisticated: knowing when the last successful run was, whether anything failed, and roughly how many documents you'd expect is enough to start with. The point is noticing before "it stopped working" gets discovered by a wrong answer in front of a client.

Re-run your stage F test set after material changes. That's what you kept it for.

And revisit the policies now and then. Exclusions drift. Access needs change. What was fine to include last quarter may not be now.

Put it to work

Make it the default, not a side tool. Bring teammates on with the right access. Feed decisions and lessons back into the source docs. Every retrieval miss makes the corpus better.

Everything so far was setup.

Make it how you actually work. Not a tool you remember to use on Fridays. The default context every AI conversation starts from. If you're still opening a blank chat and re-explaining your business, you built it and then didn't use it.

Bring teammates on, with the access you decided in stage A. The whole team working from the same brain, each seeing what they should, is the point where this stops being a personal productivity trick and starts being institutional memory.

Feed decisions and lessons back into the source documents. Every project closes with something learned. Every meaningful decision gets written down where the brain can find it. The corpus should grow because the work happened, not because someone was assigned a documentation project.

When retrieval misses, when it fails to find or rank evidence that's actually in the corpus, treat that as information. Was the document missing? Badly chunked? Excluded by mistake? Fix the corpus, add the question to your test set, move on. If the right evidence was retrieved and the answer was still poor, that's a different problem: an answer or grounding failure, not a retrieval one, and stage F is where you catch it. Every retrieval miss handled this way makes the next hundred queries better.

That's the loop. Work produces documents, documents feed the brain, the brain makes the next piece of work sharper. The arrow from H back to A on the map isn't decoration.