Your AI Needs a Brain, Not a Better Model

The problem

Over the past months I went back to our own sales team: SDRs, AEs, AMs and CSMs, from ICs to leadership. Every conversation landed on the same three facts.

• Everyone needs the complete picture of a customer.
• Everyone holds a recent, partial slice of it in their own head.
• The rest sits with other people and across a dozen tools, and no one can see all of it at once.

What we need is company context.What the company is, plus everything it has learned, in one place every person and every agent can reach.

As I’ve been actively building one in production, I’ve been digging into nearly every tool worth knowing about. This is the map I’m putting together as I learn, shared in case it’s useful to you too.

The Brain Is the Missing Layer

Andrej Karpathy’s framing is the cleanest one I’ve found. Think of the LLM as a new kind of OS. The model is the CPU. The context window is RAM. What almost nobody has yet is the disk: a persistent, queryable, evolving store of company knowledge that every agent can read and write.

That disk is what I’ll call the AI brain. It has two halves:

• Company context: what we are. Our mission, our positioning, what we sell, the one-pagers. It changes slowly, and it fits in markdown. OKF is the format I use for it, and an agent with search tools reads it directly.
• Customer context: what we know about each account and how it changes, pulled from Salesforce, HubSpot, Pendo and conversation transcripts. It changes every day.

The strategic stakes sit in the second half.

The companies that win the next decade won’t win because they have a smarter model. Every serious player is already running various AI projects in-house, or hiring outside experts to help them ship. They won’t win because they have more data either. Most of them already do. They’ll win because they’re the only ones who can reason over the years of context they’ve already collected: every customer conversation, every deal that closed and every one that didn’t, every support ticket, every internal decision, every Slack debate that turned into a roadmap.

That accumulated context is the moat. The brain is what lets a model use it. The GTM AI Brain project is the production version of the customer half: a temporal knowledge graph that unifies Salesforce, HubSpot, Pendo, and conversation transcripts into one shared memory for every GTM agent.

Underneath the brain, two threads converge:

• Memory: how an agent remembers what happened, who said what, and how facts change over time.
• Retrieval: how an agent pulls the right slice of company knowledge into context at the right moment.

A year ago these were separate ecosystems with separate vocabularies. Today they’re collapsing. The tools that matter blend graphs, embeddings, temporal reasoning, and agent-native APIs.

The tools, in one table

Here’s how I’d put the 14 tools worth knowing on a single page. Read it once, then we’ll go deeper on each.

Tool	Type	Form	Structure	Best for
Graphiti	Memory	OSS	Temporal graph	Facts that evolve over time
Zep	Memory	Hosted	Temporal graph	Enterprise drop-in with SLAs
Honcho	Memory	Hosted	Reasoning memory	Long-running agents, token reduction
Mem0	Memory	OSS + Hosted	Hybrid	Fastest path to ship memory today
Hindsight	Memory	Hosted	Vector + retrieval	Cross-session search and reasoning
Mnemosyne	Memory	OSS	Zero-dependency	Sub-millisecond agent memory, minimal deps
OpenViking	Memory	OSS	Context filesystem	Agents that think in files
Naive RAG	RAG	DIY	Vector	Simple Q&A over a small corpus
PageIndex	RAG	OSS	Hierarchical index	Long structured docs, no vector DB
HippoRAG 2	RAG	OSS	Neuro-inspired KG	Multi-hop questions across documents
LightRAG	RAG	OSS	KG-RAG (light)	Graph benefits without heavy ops
Onyx	Both	OSS + Hosted	Hybrid + connectors	Deploy chat over your stack fast
Agentic search	RAG	DIY	Harness + MCP tools	Company docs in context, MCPs as retrievers
OKF	Format	OSS spec	Markdown bundle	Company context agents parse as-is

A few patterns jump out of that table. Graphs are eating vectors. OSS is competitive with hosted. And almost every serious memory product is converging toward “graph plus temporal reasoning plus agent-native API,” with different bets on what to ship first.

Agent Memory and Stateful Systems

Memory is about continuity. Not “we saved the chat log,” but “the agent carries forward a working model of the user, the org, and the work.” If you want to see the simplest possible agent loop this all sits on top of, my walkthrough of a ReAct agent from scratch is the prerequisite I’d hand a teammate.

• Graphiti is the most opinionated piece in this category about how facts should evolve. It stores them as relationships with validity windows, so when a deal moves stage or a person changes role, the graph knows when. It’s what I picked as the backbone of the brain I’m building. If you want temporal knowledge in your own stack and you’re willing to run it, start here.
• Zep takes Graphiti-style temporal reasoning and ships it as a hosted product with the guardrails enterprises actually need. Sub-200ms retrieval is the headline, but the real story is that you get the graph without running it.
• Honcho treats memory as something that reasons over what it’s seen, not just stores it. The token-reduction claim is real if your agent runs long-lived sessions and would otherwise re-feed the same context every turn.
• Mem0 is the most popular drop-in memory SDK I’ve seen developers actually ship with. If you want memory in your product this week and you don’t care yet about graph semantics, this is where you start. Almost everyone does.
• Hindsight lets agents retain, search, and reason across sessions rather than starting cold. Vectorize’s retrieval pedigree shows up in how the indexing feels.
• Mnemosyne is a zero-dependency, sub-millisecond agent memory system. The bet here is minimalism: skip the heavyweight memory infrastructure and get fast retrieval with almost no deps. If your agent runtime is small and you want memory to stay small with it, this is the cleanest option I’ve seen.
• OpenViking has the most interesting framing in the list: a context filesystem for agents. Instead of a graph or a vector store, agent context is files the agent can mount, list, and read. It’s closer to how Claude-style agents already think, which makes it surprisingly natural.

RAG Frameworks

If memory is what the agent carries with it, RAG is what it can reach for. This category has matured fast in the past 18 months. Naive vector search is no longer the default for serious systems. If you’ve never watched an embedding model fail silently, my embeddings heatmap walkthrough is the cheapest way to see why.

• Naive RAG is the baseline. Chunk, embed, search top-k, stuff into prompt. It’s still the right answer for plenty of simple use cases. Just stop pretending it’s a strategy.
• PageIndex eliminates the vector database entirely. For long, structured documents (legal, scientific, financial), an LLM navigating a hierarchical index reliably beats embedding similarity. This is the most underrated tool in this list.
• HippoRAG 2 is neurobiologically inspired, which sounds like marketing until you read the paper. The point is multi-hop retrieval: connecting facts across documents the way humans connect ideas, not just retrieving the nearest neighbour.
• LightRAG is the cheap, fast way to get most of the contextual benefit of a knowledge graph without standing up the heavyweight graph infrastructure. If your team can’t justify a graph database yet but wants graph-style retrieval, this is the bridge.
• Onyx isn’t really a framework. It’s the answer when someone asks “can we get a deployable chat over our stack by next week?” The connector library is the real value.
• Agentic search is a harness with the company docs as context and MCPs as the retrievers. The harness is the loop that hands the agent its tools, its token budget and its stopping rule; Claude Code is the familiar example. The company documents sit in the agent’s context from the start. Everything else (CRM records, tickets, transcripts, the web) is reached through MCP servers the agent calls when it decides it needs them, the way an engineer runs grep and opens the file. No chunking, no embeddings in the path. It fits company context: a few hundred documents that change slowly, not millions of chunks. My ReAct walkthrough is the smallest version of that loop.
• OKF (Open Knowledge Format) is the format that makes the documents worth searching. A directory of markdown files with YAML frontmatter, an index.md that lists what’s inside, and a type on every file (concept, howto, reference, decision, metric). Agents parse it without adapters, and the team reviews it in git like code. It is based on the Google Cloud Markdown spec and MIT licensed.

What I’d Actually Pick

The honest answer is “it depends,” so here’s how I’d choose if you forced me.

• You’re a startup that needs memory in your agent this week: Mem0. Worry about graphs later.
• You’re enterprise and need temporal facts plus SLAs: Zep. If you have a strong platform team, Graphiti self-hosted.
• You have long structured documents (contracts, research, financials): PageIndex. Skip the vector DB.
• You need multi-hop reasoning across messy unstructured docs: HippoRAG 2.
• You want a chat-over-stack deployed before your next board meeting: Onyx.
• You want graph benefits without graph ops burden: LightRAG.
• You want agents to know what your company is (positioning, offers, decisions): write it as an OKF bundle and load it into the agent’s context. No vector DB.
• You want agents to pull live facts on demand (CRM records, tickets, transcripts, the web): agentic search. A harness with the company docs as context and MCP servers as the retrievers, so the agent fetches what it needs when it decides it needs it.
• You’re building a production brain that has to serve every agent in the company: a combination. Graphiti or Zep for the customer half, an OKF bundle in context with MCP retrievers for the company half, PageIndex or HippoRAG layered for long-doc retrieval, and a connector layer borrowed from Onyx-style projects.

Picking the stack is the easy part. Defining the ontology, the ingest contracts, and the freshness policy is where most brains die.

The Opinionated Take

After a year of reading, building, and arguing with vendors, here’s where I’ve landed.

The AI brain isn’t going to be one product. It’s going to be a stack. The winners will be the ones who unify memory and retrieval, embed the brain in the flow of work, and put it in the hands of every employee and every customer, not just a handful of engineers. Vector-only RAG is a finished story. Temporal knowledge graphs are the most underrated primitive in the field right now. Numerous companies are quietly building an AI substrate that everyone else will end up depending on.

Most companies are buying LLM tokens. Some are even stitching together premade tools on top. The ones that’ll pull ahead are building an AI brain: a single, evolving, queryable model of their own business that every agent, copilot, and workflow can plug into.

The model layer commoditises. The brain layer compounds.

If you’re a leader staring at a fragmented stack and a procurement queue full of “AI” vendors, the question isn’t “which tool is smartest.” It’s “whose brain is this feeding, and do we own it?”

The companies that answer that question well in the next 24 months will spend the rest of the decade with a compounding advantage. The ones that don’t will keep buying agents that can’t see anything.

---

Keep reading

• The GTM AI Brain in production: the project behind this post. A temporal knowledge graph (Graphiti on Neo4j) unifying Salesforce, HubSpot, Pendo, and conversation transcripts so every GTM agent works from the same fresh, time-aware view.
• AI agents that tripled sales-approved outbound meetings: what the brain enables on the revenue side. Research, then sequence, then enrol, wired into Salesforce.
• I built an AI outbound agent. Here’s what actually worked.: the honest write-up on Towards AI.
• RAG is broken: we need connected entities, not isolated chunks: why chunking destroys the context a brain is supposed to keep.
• Agentic AI: Simple ReAct Agent: the prompt loop every memory and RAG choice sits on top of.

---

I’m writing a series on building the AI brain in production: architecture, evals, the choices I’d make differently, and the failure modes nobody warns you about. Subscribe on Substack to get the next post when it lands.