Why AI Company Brains Fail

Pippa The phrase “company brain” is doing a LOT of work for something that usually means search, a chat box, and an extremely confident partial answer.

Tyler Yeah. The article’s real point is sharper than “RAG bad, graphs good.” It says retrieval systems fail when the question needs complete coverage, and a giant prebuilt graph is often an expensive way to notice that.

Pippa Right, Tyler. A pilot can look magical because everyone asks, “what did the 2017 memo say?” Then somebody asks for every company tied to a sector, and the magic quietly omits half the folder.

Tyler Exactly.

Pippa Also, tiny status check: this week feels like every product has suddenly developed a brain. I’m not against brains. I just want them to remember the whole meeting, not three sentences that happened to embed nicely.

Tyler The enterprise brain apparently has excellent vibes and selective recall. Which, honestly, is not the differentiator people think it is.

Pippa Okay, fair. But that is why I like the author starting with behavior. Don’t buy infrastructure because the architecture diagram is handsome. Ask whether it changes what someone can actually find and decide.

Tyler The three query shapes are useful. A needle question asks for one fact from one document, like the take rate in a valuation memo. Vector retrieval is genuinely good there. A portfolio question asks what the corpus knows about one company, while a counting question needs an exact list across the corpus. Top-k retrieval has no mechanism for proving it found everything.

Pippa Mm-hm.

Tyler And that silent omission is nastier than an obvious error. In diligence, contracts, or internal research, a polished list of seven companies is dangerous if there were actually twelve and the system gives no coverage signal.

Pippa That’s the practical split for me. Search can help someone start investigating. But once the answer implies completeness, the interface has to earn that claim. “Here are some relevant documents” and “here is every supplier mentioned” are wildly different product promises.

Tyler GraphRAG was meant to bridge that. Microsoft’s version extracts entities and relationships across the corpus, clusters them, and writes summaries ahead of time so it can answer global questions. Technically, that makes sense for cross-document sensemaking. The problem is the index cost arrives before there is any evidence anybody will ask those questions.

Pippa And the article cites LazyGraphRAG saying a plain vector index is about zero point one percent of the full GraphRAG indexing cost. That’s not a rounding error. That’s a founder looking at a mid-market customer and realizing the bill shows up before adoption does.

Tyler Right, right.

Tyler There’s a nice technical concession in the piece, too. Graph approaches can win on multi-hop and broad summary questions, while vanilla RAG wins on direct facts. A 2025 evaluation the author cites found routing between them worked best, and one production case reportedly sent only a single-digit share of queries through its graph.

Pippa So this is round whatever of our control-stack argument. The field keeps naming a grand architecture, then the useful product turns out to be selective routing and receipts. Nobody has settled the “agent harness” version of this either, but the camps are still basically full stack versus targeted tools.

Tyler You found the boring controls again. But yes, and this article’s middle path is pretty sensible: ordinary search index for passages, database records for entities, then co-occurrence links instead of a dedicated graph database.

Pippa It uses a fixed ontology of six entity types, plus labels like industry or topic. That’s a very product-shaped constraint. A custom ontology means workshops, consultants, and someone arguing for six weeks about whether “strategic initiative” is a project or an event.

Tyler It is always an event.

Pippa Exactly. And the fixed types are what let a private-equity workspace and a pharma workspace start without designing their own tiny universe.

Tyler The strongest bit is entity resolution. It checks known alternate names exactly, uses cheap similarity search for candidates, and asks a small model only when a match is ambiguous. Crucially, it prefers a missed merge over a wrong merge, because joining two different Acmes poisons every downstream answer. Reversible merges are the right call.

Pippa Sure.

Tyler I do have one real reservation. The author says their evaluation harness used thousands of real documents and graded questions, and that the entity layer clearly improved portfolio and counting queries. Great. But without the actual scores, breakdowns, and examples of bad merges, that is still a product claim, not evidence I can audit.

Pippa Yeah, no, you’re completely right. Especially because automatic scoring can miss the thing users care about most: whether the system surfaced the missing item that changes the decision. I’d want precision and recall by question type, plus a way to inspect why an entity was included or skipped.

Tyler And the system needs to expose its tool chain. The article says its agent can use plain search, exact resolve for one entity, expand through related entities, and exact counting. Watching that sequence is useful, but the user also needs the underlying documents and the boundary of the count. Otherwise we rebuilt confident chat with nicer plumbing.

Pippa That’s where it becomes something teams can adopt. Not “ask the company brain anything.” More like: use this when you need a research map, and see the documents, aliases, and count that produced it. That’s less cinematic, but it survives a security review and a bad Tuesday.

Tyler I’ll grant you the product optimism this time, Pippa. The architecture is not glamorous, but lazy summaries, cheap resolution, and query-specific tools are a credible way to avoid paying for graph theater.

Pippa I want the promised eval write-up next, plus a real comparison against Microsoft’s LazyGraphRAG on the same corpus. Until then, I’m calling this a strong design argument, not a proven replacement.

Pippa Anyway, episode seven thirty-seven has apparently made us pro-phone-book. I’ll take that over another heroic ontology workshop, Tyler.