BetterBrain×Viridon
Part 1 of 2
Retrieval · two worked examples, on your questions

Where a graph keeps up — and where it may not be able to.

Two questions. In the first, a knowledge graph and agentic retrieval reach the same answer. In the second, only agentic can — and the reason why is exactly why we'd start with agentic retrieval and build the graph on what it teaches us.

Example 1 · both reach the same answer

A graph can absolutely handle this one

Question "Based on past selection-report feedback, how do we strengthen our upcoming bid?"
Knowledge graphfollows edges
match entity
Bid
↓ edge · informed by
node
Selection-report feedback
↓ edge · recurring theme
node
Cost containment
↓ edge · trades off against
node
Routing risk
✓ Reaches the insight — every edge it needs exists.
Agentic retrievalreasons per query
1
Plan. Scope to selection-report feedback (tagged); draft sub-questions.
2
Search in parallel. "What did sponsors praise or penalize across our bids and competitors'?"
3
Read & re-plan. Cost containment recurs as a driver → fan out 5+ searches on cost, routing, schedule.
4
Synthesize the retrieved pieces into a recommendation.
Specific pieces it pulls
Selection-report line: sponsor flagged cost Prior proposal's cost-containment section Internal note: why cost couldn't just be cut Upcoming project's route options + cost deltas
✓ Reaches the same insight — dynamically.
Same destination
"Lead with cost containment — and proactively address the routing-risk tradeoff, since cutting cost via a riskier route has lost before."
When the relationships are well-modeled, the graph traverses them cleanly. This is the case the SMEs have in mind — and we agree a graph works here.
Example 2 · most likely, only agentic can answer

Now a question the graph structurally can't reach

Question "We're eyeing Route B on the upcoming bid to cut cost — is there any reason that could backfire?"
Knowledge graphfollows edges
match entity
Route B
↓ edge · cost
node
Lower cost than Route A
↓ no edge to the actual risk · ✗
node it never reaches
Landowner / deliverability risk
Why the graph can't get there
  • No node. The landowner's track record was an off-hand remark in a project-review call — never extracted into an entity.
  • No edge. The ontology was built around proposals and selection reports; it never modeled "landowner → blocked → project," let alone linked it to a route or a bid outcome.
  • Traversal can't infer. A graph only follows edges that already exist. It has no mechanism to go read the transcript and reason that it's relevant.
✗ Returns "Route B is cheaper" — and misses the reason it backfires.
Agentic retrievalreasons per query
1
Plan. Question is about Route B risk for this bid — not just its cost.
2
Search broadly, in parallel. Route B corridor · landowners · deliverability risk · this ISO's evaluation patterns · past route-driven losses.
3
Read & recognize. A project-review transcript mentions a landowner on Route B's corridor who reportedly blocked two prior projects; this ISO weights deliverability risk heavily.
4
Synthesize. The cost saving is likely outweighed by selection risk.
Specific pieces it pulls
Review-call transcript: landowner blocked 2 projects Past selection report dinging a riskier route Route B vs Route A cost delta
✓ "Route B has likely killed bids before — don't lead with it to save cost."
Why only one got there
The connection was never an edge — it lived in one sentence someone said once.
A graph can only follow edges that exist, so a relationship no one anticipated and modeled is simply invisible to it. Agentic retrieval doesn't need the edge — it reads the content and reasons the connection at query time. That's the whole difference.
AGENTIC RETRIEVAL KNOWLEDGE GRAPH
The principle behind both examples
Agentic retrieval is a superset of the knowledge graph.

Everything a graph can answer, agentic can answer too (Example 1) (except for specific niche cases, i.e. aggregation queries for analytics (not needed here)) — and agentic also reaches answers the graph structurally may not be able to (Example 2). In raw capability, it contains the graph. The graph still earns its place where its narrow strengths matter most — predictable low latency, deterministic paths, and high-frequency lookups that don't need fresh reasoning each time — which is exactly why it stays a module we build rather than a box we skip. We lead with the more capable approach, and bring in the knowledge graph when it leads to latency or other benefits that are needed.

Why start agentic — the compounding part

Agentic-first builds a better graph

We're not choosing agentic instead of the knowledge graph — concept mapping & linkages is a module we will build. The point is sequence: running agentic first is what tells us the right ontology to build the graph on, so the graph we eventually ship covers the Example-2 cases instead of missing them.

Start here
Run agentic retrieval
Dynamic, works on day one over your hybrid store. Real answers for the proposal workflow immediately.
It reveals
The real questions & paths
We see which questions Erin actually asks, how we traverse your data, and which entities and relationships truly matter.
So we build
A graph on a proven ontology
The graph gets built on a schema we've validated against real usage — so the relationships that mattered in Example 2 actually become edges.
✗ Graph-first — the trap
Guess the ontology up front over 300-page proposals and selection reports. Spend months building the "perfect" graph — discover later it's the wrong one, and it's missing the Example-2 relationships. Brittle, and expensive to unwind.
✓ Agentic-first — the compounding path
Ship value now, learn the ontology from real questions, then build the graph deliberately. Every week of agentic use makes the eventual graph sharper — not a sunk bet.
The one line for the room
Starting agentic isn't skipping the knowledge graph. It's how we earn a knowledge graph worth having — the dynamic phase writes the ontology the durable graph is built on.
Part 2 of 2
The vision · institutional knowledge as an asset

Capture the experts. Agentic gets you there faster.

The goal Eric cares about — getting senior people's judgment out of their heads so it survives retirement — is exactly the case where a hand-built graph is most brittle and agentic retrieval works out of the box. The instinct that this "needs a knowledge graph" is backwards on this kind of data.

What Viridon wants
Capture the judgment and experience of senior experts so it stays with the company when they retire — in a small industry where you can't simply rehire that depth. A repository of knowledge first; automation later.
BetterBrain's mission — 3 years running
Companies carry huge institutional knowledge locked in people's heads. People won't document it — they never have. Our whole reason for existing: extract it, make it accessible, and put it to work.
↑  the same goal  ↑
The catch

This knowledge is messy by nature

It doesn't live in tidy documents with clean filenames. It lives in conversation — senior people thinking out loud, explaining the why behind a call. The value is in the implicit judgment, not in keywords.

SME transcript a senior developer, thinking out loud
SME:"…yeah, on paper the cheaper route looks better, but you can't just go cheapest — that corridor has a landowner who's killed two projects, and the ISO weights deliverability risk heavily there. So we paid up for the safer route on purpose. People see the cost line and think we overspent — we didn't, we were buying down the risk that actually loses bids…"
Nothing here is a clean entity or a labeled relationship. The gold is the unwritten judgment — "cheaper isn't better here, and this is why." That's precisely what gets lost when the expert leaves.
The same data, two approaches

Where each one lands on conversational knowledge

This is the example where the two genuinely diverge — and it cuts against the graph, not for it.

Knowledge graphweakest here
Must impose structure on unstructured talk
  • Entities are implicit and fuzzy — "that corridor," "the landowner" — hard to extract reliably.
  • The relationships are judgment, not fact — "we paid up on purpose" doesn't fit a clean edge type.
  • You must guess an ontology for experiential knowledge you don't yet understand.
  • Extraction errors over rambling transcripts compound — and a wrong edge silently corrupts answers.
→ Maximum brittleness, maximum maintenance.
Agentic retrievalnative fit
Reasons over the talk as-is
  • Throw the transcripts in — it works on day one. No ontology, no extraction pipeline.
  • It reasons over concepts and experience dynamically, the way a person reading the transcript would.
  • It surfaces the implicit judgment — "cheaper isn't better here, because…" — without anyone pre-wiring it.
  • "Deep research on your data": ask a question, it goes and finds the reasoning wherever it's buried.
→ The vision, working immediately.
Why it matters for the decision

The vision is better served by starting agentic

Better served — and faster
The "capture our experts" vision doesn't require a fragile, hand-built graph over conversational data — that's the slowest, riskiest path to it. Agentic retrieval makes the expertise accessible right away, and exactly as a repository of knowledge, which is what Eric is actually after.
And it's still the asset
The captured knowledge — the layer now, the graph we build later on a proven ontology — is owned IP that transfers with the company. The expertise that would have walked out the door becomes a line item in the data room.
The one line for the room
Cloning your experts is the vision we were built for — and on the messy, conversational knowledge it actually lives in, agentic retrieval is the robust path and the hand-built graph is the brittle one. Our recommendation is to build the graph on the knowledge that agentic retrieval reveals, rather than trying to guess the ontology up front. We recognize that there are benefits to the knowledge graph (latency, deterministic paths, high-frequency lookups), but we believe that agentic retrieval is the more capable approach for this use case, and will help inform a far more powerful knowledge graph build in the near future.