The diligence gap: four questions a strong LLM still gets wrong
We gave a leading language model web search and asked four diligence questions about a promoted micro-cap. It failed all four — and a better model or fresher search fixes none of them.
The pitch for AI research is that a strong language model with web search can do diligence for you. For a single large-cap, it often can — the facts are everywhere and the model has read them. So we tested the harder, more common case: a promoted micro-cap, the kind an analyst actually has to vet. We used a top model with live web search and asked four questions. It failed all four — and, importantly, none of the four failures is the kind a bigger model or fresher index would fix.
1. Namesakes: it resolved the wrong person
We asked it to profile a company director named David Bogart. The model retrieved pages for Christopher Bogart — the well-known CEO of Burford Capital — decided they were the same person, and wrote a confident biography attaching Burford's litigation-finance career to our unrelated director. Retrieval matches on strings; it has no notion of identity. A graph resolves by identifier, not by name, so the wrong Bogart never enters the answer in the first place.
2. Multi-hop: the chain was too long to hold
"For each of this company's 14 directors, find their prior public companies and how those ended." That is roughly 30–40 dependent retrieval hops — director to companies, companies to outcomes — and every hop is a chance to drift onto the wrong entity or drop a result. The model got a few directors right, silently skipped others, and mixed in a namesake or two. In the graph, the same question is a single traversal: the path is the query, and it either exists or it doesn't.
3. The reverse screen: there was no document to find
"Which other public companies share a director with this one?" There is no filing that states this — it only exists as structure, latent across thousands of separate filings. Retrieval had nothing to fetch and returned nothing useful. A graph answers it directly, because the shared-director edge already exists between the two company nodes.
4. Absence: it couldn't prove a negative
"Has any company these directors previously ran been delisted or gone bankrupt?" The honest and material answer might be "none." But retrieval can only ever say "I didn't find any," which is not the same claim and not one you can stake a position on. Because the graph works over a bounded, enumerated universe, it can say "zero delistings, zero bankruptcies across these eleven prior companies" — and show the eleven it checked.
It's a structure problem, not a model problem
Every one of these failures survives a smarter model and a fresher search index, because they aren't about knowledge — they're about identity, connection, structure and completeness. That is exactly what a resolved graph provides. And it composes with the tools people already use: point an agent at the Capital Graph through our MCP server and the same model gets resolved, cited, point-in-time answers handed to it, instead of being left to retrieve and guess.
