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.