How to Build an AI Company Brain for GTM in 2026: The Complete Setup Guide

You do not need another GTM tool. You need one place that holds everything your company knows, with an AI running on top of it.

We call it a company brain. It is the system we run at Anfloy, and it feeds our content, our outbound, and our inbound from a single source of memory. This is the full build, not the concept. By the end you will have the folder structure, the actual Markdown templates, a local search layer, Claude running on top, and a path to scale it to a whole team with many offers, ICPs, campaigns, and voices. You build it once, and you own it.

What you are building

One repository, four layers, with an AI on top.

raw/      your immutable sources (calls, notes, competitor pages)
wiki/     short compiled pages, one per topic, written from raw/
index+log the catalog and the append only history
skills/   the jobs the AI can do (write, research, qualify)

Under it sits a local search engine so the AI can find anything by meaning or keyword. On top sits Claude, which reads through that search instead of guessing from its own training. Once the brain exists, your content engine and your outbound engine both plug into the same memory, and every result they produce flows back in. That feedback is the whole point, and it is what makes the system compound.

The build order never changes: memory first, search second, agents last. An agent is only as good as what it can read, so you build the thing it reads from before you build the agent.

What you need before you start

• Obsidian, to view and edit the vault as a linked graph of Markdown files.
• git, to version the vault and share it with your team.
• Python 3, for the local search script (three small packages, no GPU).
• Claude Code, the CLI that runs on top of the vault and executes your skills.
• A meeting recorder like Fireflies or Fathom, to capture call transcripts.
• Later, for GTM: a scraper such as Apify, an email sender such as Instantly, and a CRM.

Step 1: Create the vault and its structure

Make a git repository, open the folder in Obsidian, and create this structure. Every folder has one job.

company-brain/
  raw/            # immutable sources: nothing here ever gets edited
    calls/        # call transcripts (keep private, gitignored)
    competitors/  # saved competitor pages
    notes/        # meeting notes, docs, anything captured
  wiki/           # compiled knowledge, one short page per topic
    people/       # one page per key relationship
    competitors/  # one page per competitor
  skills/         # Claude Code skills, the output layer
  brain-search/   # the local search script
  content/        # the content engine (voice, pillars, calendar)
  projects/       # a case file per build or initiative
  INDEX.md        # the catalog every agent reads first
  log.md          # append only history of every change
  README.md       # what this repo is

Opening this folder in Obsidian gives you a linked graph for free. Any `[[page-name]]` link between two Markdown files becomes an edge in the graph, so your knowledge is navigable, not just stored.

Step 2: Load your raw sources, and keep them immutable

The raw layer is your ground truth. Everything lands here once and stays untouched. You compile from it, you do not rewrite it. The moment you tidy a transcript, you break the thing your agents are supposed to trust.

Your richest source is your sales and customer calls. Point a recorder like Fireflies at your calls, then export each transcript into `raw/calls/` as a Markdown file with a small header so it is machine readable:

---
type: sales-call
source: fireflies
date: 2026-01-07
title: "Discovery call with Acme"
participants: jane@acme.com, you@yourco.com
---

# Discovery call with Acme

## Summary
One paragraph, written after import: who, what they needed, the outcome.

## Transcript
**Speaker 1:** ...
**Speaker 2:** ...

Do the same for meeting notes and competitor pages under `raw/notes/` and `raw/competitors/`. Keep the header light and consistent, because the header is what lets a skill filter and cite these later.

One rule that saves you later: call transcripts and anything sensitive belong in a gitignored path so they never leave your machine. What you share with the team is the compiled layer, not the raw records.

Step 3: Compile a wiki from the raw

Raw transcripts are too long and too noisy for an agent to read every time. So you compile. An agent reads the raw layer and writes one short page per topic: your product, your ICP, your positioning, your pricing, each competitor, each key person. This is the pattern that keeps a brain from rotting. An append only pile of notes gets vaguer as it grows. A compiled wiki gets sharper, because every time new raw lands, you rewrite the affected page from the evidence.

A wiki page is short, cross linked, and cites the raw source behind each claim:

# ICP

Who we sell to. See [[positioning]] for why, and [[offer]] for what we sell them.

## The one-line filter
Fits if: clear revenue motion and a workflow worth owning. Fails if: pre-revenue or no budget.

## Who actually shows up
Agencies dominate the pipeline, wanting their own outbound engine
(raw/calls/2026-06-10_mike-x-dima.md). SaaS founders want a custom agent they
cannot build in-house (raw/calls/2026-04-21_marco.md).

Follow four rules and the wiki stays trustworthy:

• One topic per page, kept short. Link related pages with `[[page-name]]`.
• Compile from raw and cite it. The page summarizes, the source of truth stays in `raw/`.
• Keep it current. When new raw arrives, update the affected page.
• Re-index and log it after every edit (Steps 4 and 5).

To run the compile, you open the vault in Claude Code and ask it to read the relevant raw files and write or update the page. That is a skill, which you set up in Step 6.

Step 4: Add the memory spine

Two small files turn a folder into a system.

`INDEX.md` is the catalog every agent reads first, so it always knows what exists and where:

# Index

## By category
### Outbound
- [ariel-outbound](projects/ariel-outbound.md): engager to qualify to send

### Knowledge base
- [pear-growth-kb](projects/pear-growth-kb.md): chat over SOPs with citations

`log.md` is an append only history, one line per meaningful change, newest at the bottom. Never edit past entries, only append. It is your audit trail:

# Log
Format: `date | what changed | why`. Append only.

2026-07-02 | Added raw/calls and pulled transcripts | store all calls, retrievable
2026-07-02 | Compiled wiki/icp.md from ~290 calls | first ICP page

Together the index and the log are the memory spine. The index tells an agent where to look. The log tells you and the agent what happened and when.

Step 5: Make it searchable with local hybrid search

Now you make the brain answerable. Put a small search layer over the Markdown so an agent can find anything without reading every file. Use hybrid search, which blends two signals:

• Keyword search (BM25) catches exact terms, names, and acronyms.
• Vector search catches meaning, so a query for "pricing pushback" also finds "too expensive."

You fuse the two scores and return the top results. Keep it fully local so it is fast, private, and always reads the latest version of your brain. The entire footprint is three Python packages:

rank_bm25
fastembed
numpy

`fastembed` runs a small embedding model on your machine with no GPU and no API call, so your data never leaves. A few details make it production grade: split files on their Markdown headings so each chunk carries its heading path, key each chunk by a content hash so you only re-embed what changed, and normalize both score lists before blending them. You end up with two commands:

# rebuild the index after any edit (incremental, only changed chunks re-embed)
brain-search index

# ask the brain a question, top 6 results as JSON
brain-search search "top objections on pricing" -k 6 --json

The rule that makes retrieval trustworthy: an agent searches first and reads the cited files, then answers only from what it found. It does not answer from its own memory.

Step 6: Put Claude on top

The brain is now readable. Add the intelligence with Claude Code, which runs in the vault and reads it through that search layer. You give Claude jobs as skills. A skill is a folder under `.claude/skills/` with a `SKILL.md` that has a short header and a set of instructions:

---
name: brain-search
description: Search the company brain before answering. Trigger on any recall question.
---

Run `brain-search/brain-search search "<query>" -k 6` before you grep or answer from
memory. Open the cited files. Answer only from what they contain, and cite them.

Build one skill per job: a researcher, a content writer, an outbound writer, a call miner. Skills are the output layer, the part that turns memory into work.

For anything that writes, wrap it in a three step loop so it stays grounded:

• Plan. Classify the task and decide what to pull from the brain.
• Do. Draft it using only what the search returned.
• Check. A critic pass verifies the draft against your rules and the sources. If a claim is not in the brain, it does not ship.

That check is the difference between a system that occasionally invents things and one you can leave running.

Step 7: Wire your content engine onto the brain

With the brain in place, content stops being generic. Set up a `content/` folder and give the writer three things.

• A voice model. Save your best real posts as anchor files, plus a short spec of how you actually write and what to avoid. Every time you edit or reject a draft, append the correction as a reusable rule to a corrections log. Over a few weeks the writer learns your voice from your own feedback, not a template.
• Awareness of now. Pick a handful of influencers and competitors, and scrape their new posts on a schedule with a tool like Apify. Add the subreddits and topics your buyers actually talk in, and pull the day's relevant news. Each pass writes a dated digest into `content/news/` and flags the few angles worth posting into a backlog.
• Your own evidence. The writer reads your calls and shipped work, so a post can say "here is what we heard across forty calls this quarter" with real substance behind it. Anyone can prompt a model for a take. Only you can write from your own corpus.

Keep it draft only. The engine plans and writes, a human approves and posts.

Step 8: Wire your outbound engine onto the brain

Same brain, different output. The outbound engine runs signal first, not list first.

• Source from signal. Watch the people already in motion: those engaging with your competitors and the influencers your buyers follow. Treat those profiles as evergreen sources the system refreshes on its own, not a one time export.
• Qualify before you spend. Run cheap deterministic filters first (title, geography, blocklist) to drop the obvious no's for free. Only the survivors get scored by a model against your ICP, which you define once as a rubric the brain already holds.
• Route by offer and ICP. Qualification sorts each lead into the cohort that matches a specific offer, and each cohort maps to its own campaign with its own message.
• Verify reachability. Enrich contact details through a waterfall of providers, deduplicate against everyone you have already touched, and confirm an address is deliverable before anything sends. The engine emails no one until a stack of checks clears.
• Route models by difficulty. Send the routine bulk to a cheap model and reserve a frontier model like Claude for the hard calls where being wrong is expensive.

Spray and pray still gets the one to two percent reply rate it always has, because the whole market is buying the same lists. Signal based outbound off a brain that knows your ICP is a different game.

Step 9: Close the loop

This is the part that compounds. Every reply gets classified. Every deal and result gets captured. The messages that worked, the objections that came up, the wins you closed, all of it flows back into `raw/`, gets compiled into the affected wiki page, and gets re-indexed like everything else.

So the system does not just send and forget. It remembers. Next quarter's outreach is trained on last quarter's wins, and your content is grounded in the deals you actually closed. Content feeds the brain, outbound feeds the brain, inbound feeds the brain, and the brain feeds all three.

Step 10: Give your team access and scale it

At small-team size, sharing is a git clone, not a vendor seat. A teammate clones the repo, opens the vault in Obsidian, and has the compiled knowledge and the skills locally. Keep raw transcripts gitignored so you distribute compiled knowledge, not sensitive records, and keep secrets in an environment file outside the repo, never committed.

For a bigger team, take the same shape past files. This is where you go beyond a local vault:

• Move the store to a database. Put the compiled knowledge in Postgres with a vector extension, and embed with a hosted model so retrieval scales past one laptop. The retrieval pattern is identical: keyword plus vector, fused.
• Put it behind an authenticated app. Gate access by your team's email domain, deployed on your own cloud, so the brain is a shared internal service rather than a folder each person maintains.
• Automate the ingest. Run a nightly job that pulls new calls, recompiles the affected wiki pages, and rebuilds the search index, so the brain stays current without anyone running a command.
• Separate roles. Decide who can add raw sources, who can compile the wiki, and who can run outbound. The append only log is your audit trail across all of it.
• Add guardrails at scale. Keep an approval gate on anything client facing, and track token spend with a cap so an automated loop cannot run away.

Small team or company scale, the pattern holds. Raw in, compile, retrieve, Claude on top, results back in.

Run it at organizational scale

Everything above is the base build. A real company has more moving parts: several offers, several ICPs, a different offer for each ICP, many campaigns at once, and a team of people who each write in their own voice. The architecture handles all of it, but you model the complexity explicitly instead of hoping one global setting covers every case.

Model many offers and many ICPs

The mistake at scale is one global ICP and one qualification rubric. You separate them. Give every offer its own page and its own rubric, and give every ICP segment its own page. Then keep an explicit matrix of which offer goes to which segment, so the system always knows the right pairing:

Offer              ICP segment          Angle / proof
outbound-engine    GTM agencies         own your pipeline (ariel win)
recruiting-agent   staffing firms       auto-source and match
custom-ai-build    Series A/B SaaS      build vs hire an AI team

Now qualification scores a lead against the rubric for the offer it actually fits, not one blanket score. A company can be a strong yes for your recruiting offer and a clear no for your build offer, and the system treats those as different decisions. Each offer page holds its own fit signals, disqualifiers, and the wins that prove it, so both content and outbound pull the right proof for the right buyer.

Route many campaigns without collisions

Each offer and segment pair maps to its own campaign, with its own sequence, its own copy, and its own mailbox pool so deliverability stays clean as volume grows. The risk at scale is overlap: two campaigns, or two reps, hitting the same person or the same account. You prevent it with coordination the brain enforces:

• One active touch per person. A contact is only ever in one live campaign. Everyone you have already emailed or closed is a global suppression list the system checks before adding anyone.
• Account-level awareness. Treat the account, not just the person, as the unit. If anyone at a company is already in a live deal or sequence, suppress the rest of that company. This is what keeps outbound from stepping on an open opportunity.
• The CRM is the source of truth. Sync who is in play from your CRM into the brain as a blocklist on a schedule, so a rep adding a deal by hand instantly removes that account from automated outreach.

Give every voice its own model on one brand spine

A team does not share one voice, but it does share one brand. So you split content into two layers. A shared brand layer holds the things that are true for everyone: positioning, the claims you can and cannot make, banned words, the proof library. Then each person gets their own voice model, their own anchor posts, and their own corrections log on top of that spine.

The result is that five people post in five real voices, all grounded in the same brain and none of them able to drift off-brand or invent a claim. Pillars and the calendar can run per author or per product line, balanced so the team covers the mix without three people posting the same angle in the same week.

Retrieve with scope, not the whole corpus

A founder's brain is small enough that searching everything is fine. An org brain is not. Once you have tens of thousands of chunks across offers, segments, and products, unscoped search gets noisy and pulls the wrong context. Two upgrades fix it:

• Tag and filter. Every chunk carries scope tags, so a query filters to the relevant slice before it ranks:

offer: recruiting-agent
segment: staffing-firms
source: raw/calls/2026-05-12_acme.md

• Add a reranker. On a large corpus, run a rerank pass on top of the hybrid results for precision. The founder-tier local search is keyword plus vector only, which is enough at small scale. At org scale you add metadata filters and a reranker so the top results are actually the right ones.

Govern it like a system

At team size the loose folder becomes a governed system. Decide roles: who can add raw sources, who compiles the wiki, who owns each offer's rubric, and who can launch a campaign. Put an approval gate on anything client facing, and cap token spend so an automated loop cannot run away. Run the ingest and outbound work on a locked job queue so parallel workers never double-send, and keep the append only log as the audit trail across every team. If one deployment serves multiple brands or business units, isolate them at the query layer so each only ever sees its own data.

The point: you own the engine

The reason to build it this way is ownership. This is not a tool you rent that changes its pricing, or a black box only a vendor understands. It is your memory, your code, your infrastructure, running on your cloud, that your team can read and extend. Build it once and it is yours permanently, and it compounds instead of resetting every time a contract ends.

That is the real advantage in 2026. Not the agents. The brain they run on.

If you want this built into your stack and handed over so your team owns every line, that is exactly what we do at Anfloy.