Table of contents

Most of the AI industry is optimizing the wrong half of the problem. The frontier labs have made generation a solved commodity — GPT-5.2, Claude Opus 4.5, and Gemini 3 Pro will all write you a fluent, confident, beautifully structured meeting brief in seconds. None of that is our moat, and none of it should be theirs.

The durable, defensible work — the part that compounds — is grounding: guaranteeing that every claim in that brief is true, current, and about the right person. That is a much harder problem than generation, and it's the one we've spent the last two years building a system to solve. This post is about how that system works.

A wrong fact, said out loud, is catastrophic

Here's the constraint that makes meeting prep different from a chatbot. When a chatbot hallucinates, you catch it, sigh, and re-prompt. When a meeting brief hallucinates, you walk into a board meeting and tell an investor you're excited about their Series C — which closed eighteen months ago, at a different fund, before they left. You can't re-prompt your way out of that room.

So "mostly right" is a failing grade. A brief that's 95% accurate isn't 95% useful; it's a liability, because the 5% is delivered with the same confidence as the rest and you have no way to know which 5% it is. The entire engineering problem reduces to one question: how do you make a system that knows the difference between what it knows and what it's guessing — and refuses to guess?

What we learned shipping CRM agents

Before Evan, our team spent a long time building agents that operate enterprise CRMs — reading, aggregating, and writing across HubSpot, Salesforce, Close, and Attio. We took that work seriously enough to turn it into a published benchmark, RevOpsBench: 6,100 canonical tasks and 78,350 execution-grounded traces drawn from 1,487 enterprise users across 214 firms over 14 months. To our knowledge it's one of the largest real-world evaluations of LLM agents on enterprise systems of record.

The most useful thing we got out of it wasn't a leaderboard. It was a hand-labeled taxonomy of why agents fail. We tagged 600 errors by hand, and the failures clustered in a way that should worry anyone building research products on top of LLMs:

• Missing pagination (21%) — aggregates computed from partial data, because the agent stopped reading at page one.
• Schema-field mismatch (17%) — pulling "created date" when the task meant "closed date."
• Temporal-filter drift (15%) — off-by-one errors on rolling windows; last quarter bleeding into this one.
• Entity-resolution errors (14%) — duplicate or ambiguous names causing the agent to target the wrong record.

Look closely and these aren't reasoning failures. The models reason fine. They're grounding failures — the system confidently returns a result that's wrong because it misread the schema, truncated the data, drifted on time, or confused two entities. Fluency was never the bottleneck. Faithfulness was.

That finding is the spine of how we built Evan. Meeting prep is the same problem with the difficulty turned up, because now half the sources aren't a structured CRM — they're the open, messy, contradictory web.

The four ways meeting research goes wrong

Map those failure modes onto researching a human being before a meeting, and you get the four threats Evan's engine is designed to beat:

1. Entity resolution. The same person exists as different records in your CRM, your inbox, LinkedIn, a TechCrunch article, and a podcast transcript — under three spellings, two job titles, and one rebranded company. Get this wrong and every downstream fact is attached to the wrong human.
2. Temporal drift. Titles change, rounds close, champions leave. A fact that was true last quarter is a landmine today. Research without timestamps is research you can't trust.
3. Source conflict and trust. The press release says one thing, a blog says another, the CRM says a third. A naive system averages them or picks the loudest. A grounded system knows which source to believe and flags when it can't.
4. Confabulation under thin data. This is the dangerous one. When real signal is sparse, ungrounded models don't stay silent — they generate plausible detail to fill the gap. Any tool that infers a person's "personality" from a half-empty LinkedIn profile is shipping this failure mode as a feature.

The architecture: a verification-aware research engine

Evan's research engine is built as a pipeline that wraps every model call in deterministic checks — a planner, a retrieval layer, a context graph, grounded synthesis, and two gates that sit between the model and your eyes. It's the same verification-aware shape we validated in RevOpsBench, extended from one CRM to the entire surface of a person's public and private footprint.

1. The planner decomposes the meeting. Before retrieving anything, Evan breaks a meeting into research sub-questions — who is in the room, why this meeting matters now, what the relationship history is, what external signals are live — and decides which sources to hit and how many hops each question needs. This agentic decomposition is deliberate: single-shot retrieval is where most hallucinations are born. A simple fact takes one hop; "why did this account go quiet and who's the new decision-maker" takes four.

2. Hybrid retrieval across connected sources. Evan retrieves over both halves of your context: internal (CRM, email, call recordings, Slack, docs — connected through MCP so the integrations are first-class, not scraped) and external (LinkedIn, news, filings, podcasts, video transcripts, the open web). We don't rely on vector similarity alone — it fails the moment a query says "VPN" and the source says "GlobalProtect." We run dense retrieval, BM25 lexical search, and cross-encoder reranking together, because recall and precision fail in different places and you need both.

3. The context graph (this is the part that's hard to copy). Retrieved evidence doesn't go straight to the model. It's resolved into a per-meeting context graph — a typed knowledge graph of people, companies, deals, and events — using GraphRAG-style entity anchoring and lightweight resolution models to collapse "J. Smith," "John Smith," and "john@" into one verified node. Every node and edge carries provenance and a timestamp. This is what kills entity confusion at the root: in production graph-anchored systems, "stated a fact about the wrong entity" errors drop by an order of magnitude, and we see the same. The graph is also where temporal drift dies — because a claim without a date never makes it into the graph as current.

The context graph is the asset. Models are rented; the graph compounds. Every meeting you run makes the next one sharper, and that accumulated, resolved, time-stamped context is not something a competitor reproduces by calling the same API.

4. Grounded synthesis. Only now does a model write. Synthesis is constrained so that every sentence in the brief is bound to a source node in the graph — no free-floating claims, no "it is likely that." If it's in the brief, it traces to a source with a timestamp.

5. The factuality gate. This is the quiet shift the whole industry is making in 2026: separate generation from verification. After the brief is drafted, Evan decomposes it into atomic claims and checks each one against the context graph using entailment scoring — supported, refuted, or not-enough-evidence, in the FEVER tradition. Refuted claims are corrected or regenerated. Unsupported ones are cut. The model that writes is never the final authority on what's true; a separate verification layer is.

6. The abstention gate. Below a confidence threshold, Evan says "couldn't verify" instead of inventing. This is the single most important behavior in the product, and the hardest to get a model to do, because every instinct in a generative system is to produce text. It's the read-only sibling of the safety gate we built for destructive CRM writes — and in both cases, knowing when not to act is the feature.

We pay for all of this in latency — verification adds low hundreds of milliseconds per brief. We consider that the easiest trade we make. Nobody has ever lost a deal because their prep arrived 300 milliseconds later; people lose deals because their prep was wrong.

We don't ship vibes. We ship measured systems.

The reason we can make claims about grounding is that we measure it the way you'd measure a database, not the way you'd review prose.

RevOpsBench gave us execution-grounded metrics — Execution Accuracy for analytics, State-Delta F1 for writes, Confirmation Compliance and Action Overreach for safety — run against deterministic snapshots so results are reproducible. The headline result is the one that matters for this whole argument: wrapping the same model in our verification-aware scaffold improved execution accuracy by 7.7 points (78.4% → 86.1%) over calling tools directly, drove deployed confirmation compliance to 100%, and cut action overreach by more than half. Same model. Different system. The lift came from the scaffold, not the weights — which is precisely why we invest in the scaffold.

We hold meeting briefs to the same standard with an internal evaluation harness that scores groundedness (is every claim traceable to a source?), recency (is every time-sensitive fact current?), entity precision (is every fact attached to the right person?), and completeness — graded with a combination of LLM-as-judge and human spot-checks against held-out briefs. A brief that reads beautifully but can't ground a claim fails the eval, the same way a query that returns a confident wrong number fails RevOpsBench.

A failure we fixed

The cleanest illustration of why this architecture exists came from two executives with the same name at the same company — one who'd left a year ago and one who'd just been promoted into the role. Early on, our retrieval happily blended their histories: the departed exec's old objections, the current exec's new mandate, fused into one confident, completely wrong brief. The model wasn't hallucinating in the usual sense; it was faithfully summarizing a corrupted entity.

The context graph is what fixed it. Once resolution runs against typed nodes with provenance and recency rather than against a name string, the two people stay two people, the stale record gets dated out of "current," and the factuality gate catches any claim that tries to cross the boundary. That bug is the entire thesis of this post in one anecdote: the failure wasn't in the model, so the fix wasn't a better prompt. It was a better system around the model.

Why this compounds

Step back and the strategic shape is clear. The models are getting better and cheaper every quarter, and that's good for us — but it's good for everyone, which means it isn't an advantage. The advantage is everything we've described that isn't the model: the verification-aware scaffold, the resolved time-stamped context graph that gets richer with every meeting, the factuality and abstention gates, and a proprietary benchmark that lets us measure all of it while most teams are still eyeballing outputs.

That stack compounds in three directions at once. It compounds in data — every meeting deepens the graph. It compounds in evaluation — every failure we label sharpens the benchmark that guards quality. And it compounds in trust — the product that's right when it matters is the one people stop double-checking, and the one they bring into the room they can't afford to get wrong.

Generation is a commodity. Grounding is the moat. We're building the moat.

Evan is the AI meeting prep worker that researches every meeting so you walk in already knowing the room. Try it out →