How we analyse every deal with AI

There's a difference between bolting AI onto how you already work and rebuilding the work around it. One saves a few hours a week. We wanted the other — so we stopped looking at new deals for three months and pulled our investment process apart.

This is what came out the other side.

Everything we rebuilt comes down to one split. The engine does the repeatable work — sourcing, research, the first read on a deal, monitoring, drafting. People make the investment decisions. It runs on every inbound deal the second it lands, a full pass in about five minutes. A human makes the call at the end; the engine does the work that informs it.

In this piece.

How it works — The four layers · How the engine reads a deal · How we keep it honest

Why, and what it's worth — Why we built it this way · What it buys · What it asks of us

How it works

The four layers

The engine is built in four layers, each with one job and kept separate from the others: one to move the data, one to do the reasoning, one to watch and grade it, and the model that does the thinking.

Stack.

• n8n — moves the data. Triggers, payload normalisation, routing between workflows, retries, every read and write to an outside system.

• LangGraph — runs the reasoning as a stateful agent graph. The agents and their order are an explicit graph; because it holds state, a run can stop for a human at the gate and resume, or re-run just the part a changed input touches.

• LangSmith — sits over the top: traces every run, grades every change before it ships.

• OpenRouter — the model layer. No model of our own, trained or fine-tuned — one endpoint the harness routes through, so a task can be repointed at a better or cheaper model without re-plumbing. Today that's Claude: Opus for the deep agents, Sonnet for the lighter passes.

In one line: n8n moves the data, LangGraph runs the agents, LangSmith grades them, Claude thinks.

[ SCREENSHOT — n8n, the plumbing layer: the ingestor workflows (one per entry point) beside the completion-handler workflow that writes results to Attio / Supabase / Slack. Caption: the plumbing layer — deals in one end, results written out the other. ]

[ SCREENSHOT — the LangGraph graph view: nodes and edges for the reasoning graph (agents + the gate interrupt). Caption: the reasoning layer — the agents, and the order they fire in, as an explicit graph. ]

How the engine reads a deal

Seven stages, in order — every deal that lands runs the same path.

[ INTERACTIVE — "The journey of a deal." The seven stages below render as a walkable pipeline: each node shows its short label, tap reveals a one-line explanation + the stack beneath it, and "Run a deal" animates one deal through the line, pausing at the two human checkpoints (stages 3 and 7). Sits here on the page; the full-text stages below double as the fallback. ]

[ SCREENSHOT (alt/fallback to the interactive) — the LangGraph reasoning graph, zoomed to show all seven stages end to end (the plumbing bookends — ingestors and completion handler — live in n8n, shown in "The four layers" above). Caption: one deal's path through the engine, start to finish. ]

1. However it arrives, we read it the same way

A deal can come in four different doors. Whichever one it uses, the first thing that happens is we turn it into a single, standard record — one shape every downstream agent reads. Missing information is marked as missing, explicitly, never just dropped. Nothing gets analysed on a half-picture, and no two agents ever work from different versions of the facts.

Stack. Four entry points, each mapped to one fixed-schema canonical deal object by a Normalise node:

• a site webhook (the public submission form)

• a monitored deck inbox (internal forwards only)

• a manual ingestor (Attio / Cowork)

• the founder chatbot

Inbound email is parsed by a Sonnet pass first. Absent fields are set explicitly to null, never omitted. Orchestration and I/O run in n8n.

2. It works out what the company is, and who's behind it

Before anything deep runs, the engine builds a plan, then takes a first read: it parses the deck and the website together, and pulls the basic professional details on the team. This is the context everything downstream depends on — what the company is, and who's behind it.

Stack. On a first analysis the stages run as a fixed graph, in order — nothing decided on the fly. (An orchestrator only takes over on re-analysis, deciding which stages a new input actually touches.)

• Doc Intelligence (Opus) — first to run: reads deck + website via Firecrawl (deck OCR and site extraction). Pulls the founder names later agents need, plus any competitors the deck happens to name — a starting point only, since the competitive agent does its own research.

• Founder Check — a lightweight pass over LinkedIn headline + roles (Renidly) to ground who's on the team before the gate.

3. A gate checks fit — a human checks the gate

Once the engine knows what a company is, a first gate reads fit: the right stage, the right kind of company, the right part of the world, and whether it's something the fund can back at all. A few of these are hard gates — trip one and the deal is out. But the engine doesn't get to reject a company on its own. Every time a hard gate fires, the call goes to the team and a human signs off before it becomes a no — because the deals worth catching are the ones a rigid rule would wrongly kill. If nothing trips, the deal flows straight on to the deep work.

A clear non-fit gets a fast answer, rather than weeks of waiting for a soft no.

Stack. Pre-Screening Gate (Claude Sonnet) applies the hard gates (stage, type, geography, mandate fit) and soft flags:

• Hard-gate failure — routes the rejection to a Slack agree/disagree step, where a human confirms the decline before it's final.

• Soft flag — raises a concern to probe, rather than stopping the deal.

• No hard gate — the deep agents run automatically.

Declines are recorded in Attio.

4. The deep work runs

If no hard gate stopped it at the door, the deep agents run — in parallel where they can be, in sequence where one depends on another.

A founder pass builds the full professional history: prior companies, track record, anything the team has published. A market pass produces an independent market size with its own method and a "why now," then checks the deck's framing against it. A competitive pass — which runs once the market read is in — maps the field itself, cross-checking any names in the deck against what it turns up. And a separate enrichment pass fills the holes left in the record.

Stack. Post-gate Stage 1a, all Opus. Founder Intel and Market Trends run in parallel; Competitive Intel waits for the market read:

• Founder Intel — full professional history via Renidly + Firecrawl web search.

• Market Trends — an independent market size via Perplexity (synthesised, cited answers), with Exa as a fallback.

• Competitive Intel — an Apify actor over recent funding rounds and competitors.

• Enrichment — waterfall lookups across data vendors via Deepline (BYOK, one API), filling any gaps left in the founder/company record.

• Data Gap Enrichment — a separate workflow that backfills CRM gaps.

5. The memo, measured against memory — and checked against itself

Synthesis pulls every stage into three things a partner can use: a written investment memo, a scorecard, and a meeting briefing — the sharpest questions to put to the founder and the gaps still worth pressing on. It doesn't score a company in a vacuum. It pulls the closest real comparables from the deals we've analysed — with citations — and notes which version of our investment thesis it judged the deal against. A company is measured against real precedent, not against whatever a partner happened to see last week.

The briefing is the point where the engine hands the deal back to the human: it walks a partner into the room already knowing what's strong, what's unproven, and what to ask. It preps the meeting; it doesn't sit in it.

Then it's checked. A second pass re-reads the first against every piece of source material, line by line, with one job: catch anything the first pass claimed that the sources don't support, and confirm every statement traces back to where it came from. The note a partner reads has already survived a review of itself.

Stack.

• Synthesis A (Opus) — runs over all stages, drafts the memo, scorecard and meeting briefing (key questions + open gaps).

• Synthesis B (Opus) — a dedicated cross-check: re-reads A against the full canonical context and every agent artifact, flags unsupported or hallucinated claims, verifies sourcing before the note is written out.

• Comparable retrieval — a pgvector similarity search over the embedded deal_intelligence store, embedded on insert by a Supabase edge function; the active investment-thesis version is pulled and cited.

6. A committee built to disagree

Consensus is where early-stage deals go to die. The outlier gets talked down to the median view in the room. So we built a committee engineered to disagree with itself.

A panel reviews every deal from deliberately opposed stances — a sceptic hunting for the reason to pass, an optimist for the asymmetric upside, a futurist for where the world goes if it works, an operator for whether it can actually be built. Some are modelled on the reasoning styles of investors we respect. They argue it out, then return a consensus, the dissent that didn't resolve, and a recommended next step.

It forces the strongest case for and the strongest case against onto the table before a human makes it. The call stays human. A deal that survives only because nobody pushed back is exactly the deal we don't want to make.

Stack. A multi-agent debate orchestrated in LangGraph — each persona is its own agent with a distinct system prompt and stance. The panel runs, then a chair agent returns:

• a structured consensus

• the unresolved dissent

• a recommended next step

To be precise: the personas are stances set by system prompt — sceptic, optimist, futurist, operator — all running on the same model. The diversity is of viewpoint: one engine argued from four deliberately opposed angles. We did test the alternative — running the same deal across different models (Claude, GPT, Gemini, DeepSeek) — and they largely converged. With the rubric and the context doing the constraining, the engine barely moved the result, which is the harness working as intended. So the diversity we keep is the one that's actually informative: the viewpoints.

[ SCREENSHOT — the LangGraph committee sub-graph: the four persona agents fanning out from the deal and converging on the chair agent. Caption: a committee built to disagree — four opposed stances, one engine. ]

7. A human makes the call

The engine rules on fit and surfaces what's true — and even the deals it wants to turn away at the gate wait for a human to confirm the call. It never decides whether to back a founder. A partner does, with their name on it, because trust only exists where someone has something to lose, and software has nothing on the line. There's no "the engine flagged it" to hide behind here.

The division is simple to state and hard to hold. The engine is better than us at everything legible — screening, research, monitoring, drafting, the patterns buried in the data — and steadier than us where our instincts wobble. People are better at what actually wins a deal this early, and no model is closing that gap. The full case for where that line sits is in part one →

Mostly science, a bit of art, no religion.

So we're precise about the side no model touches:

• Finding the founder before they're findable. The deal that returns a fund is often the one no database has indexed yet, and the engine's strength at sourcing the sourceable is exactly why the human edge is the founder no one can source.

• Reading the room. A deck can be polished; a person across a table for an hour is harder to stage.

• The left-field question. The engine asks every sensible question; the one that actually changes the decision is usually the one it would never think to ask.

• Backing them, and being backed. Conviction, a reputation staked on a founder, a relationship built over years. None of that is a model's job.

Stack. When the analysis finishes, it writes out:

• the versioned note (Company Profile + Briefing Notes) as Attio notes

• the confidence score + fields to the Attio company record

• founder records to Attio people

• every artifact to Supabase deal_intelligence; binary files to Supabase Storage (deal-files bucket)

• a Slack alert

Re-analysis and stage-triggered work (DD Box folder, deal Slack channel) run as separate Attio-stage-triggered workflows.

How we keep it honest

Glass box, not black box

Most AI projects fail for the same reason. A multi-agent system is non-deterministic, and once it's a black box, nobody can see why it did what it did, catch it when it drifts, or improve it on purpose. That's how you end up in the 95% of pilots that return nothing. We made two decisions to stay out of that.

• Separate the plumbing from the thinking. All the deterministic work — triggers, normalising inputs, routing, retries, reading and writing to every outside system — runs completely apart from the reasoning. So a delivery failure never gets mistaken for a judgement failure, each layer gets fixed in its own place, and the logic of how a deal moves through the engine is something you can read rather than something buried inside a prompt.

• Put a layer over everything that watches it. Every run is traced end to end — every prompt, every step, every cost — and nothing changes without proving, against fixed test cases, that the change made the engine better rather than worse.

That second layer is the tell. Buying the tools is easy; building the instruments to run them safely is the costly, unglamorous part — and it's the line between an engineered pipeline and a pile of wired-together parts.

Stack.

• n8n (Cloud Pro, RBAC + Projects) — owns the outer orchestration and I/O, kept wholly separate from the reasoning.

• LangGraph — the analysis runs as a state graph, so control flow (including the human-in-the-loop interrupt at the gate and selective re-runs from persisted state) lives in explicit nodes and edges, not buried in prompt logic.

• LangSmith — sits over both: full run-tree tracing (prompt/response/tool-call chains with token, latency and per-run cost), managed prompt versioning, and dataset-backed evaluation with regression tests. The layer that makes a non-deterministic multi-agent system debuggable.

The engine is stateless: a deal's entire state lives in its record, so we can swap the model, re-run a single stage, or rebuild an analysis from source context and still get a clean, current result — nothing stale to migrate, and a re-run is just the affected work firing again.

Two failure modes, two defences

When you let AI screen companies, two things can go wrong. The engine can make things up. And a deck is built to win, so a founder's story can be better-packaged than it is true. We engineered against both — deliberately, and separately.

• The engine makes things up. We can't make a model infallible. We can stop a fabrication from ever reaching a decision.

The note is drafted by one pass and adversarially re-checked by a second whose only job is to catch unsupported claims and verify every source — nothing reaches a partner unchecked. Between stages, agents pass terse, structured data rather than prose, so a loose phrase in a write-up can't leak into the facts the decision rests on. Every claim in the briefing is tagged — verified, claimed, or unverified — with its source attached. Agents are told to return a gap rather than fill a blank, because most hallucinations happen when a model is forced to answer. And hard gates override the score: a strong overall number can't paper over a deal-breaker.

• The deck is built to win. A pitch is a founder's best case, as it should be. Our job is to read what's true, not what's well-packaged — and that protects the honest founder most of all.

Numbers are checked against real category and stage thresholds, not taken at face value. Claims are cross-checked across the deck, the public record and the team's own history — and where the story and the record disagree, the contradiction surfaces rather than getting buried. Scores are anchored to companies we've actually backed and watched play out — real outcomes, not a synthetic rubric — and that calibration tightens as more deals resolve. And a partner signs off on every deal: the engine surfaces the signal, a partner makes the call.

We can't make AI infallible. We can stop it making the wrong call alone.

Stack. Hallucination defences:

• the Synthesis A → B cross-check above

• per-claim source tagging

• gap-return prompting

• hard gates that override composite scores

Deck pressure-testing:

• benchmark reference data by stage and category

• cross-source checks across deck, Renidly and Firecrawl web evidence

• score calibration against the deal_intelligence outcome corpus

• mandatory partner sign-off via the Slack human-confirm step

The failure mode on our side

Those two failures are the engine's. The subtlest one is ours.

When a system hands you a clean, confident score, the pull is to nod and move on. Automation bias — trusting the machine exactly when you should be arguing with it — is the quiet way a process like this rots. The danger was never the model being wrong now and then; it's a partner believing it when it is.

So the defences point inward too. We don't surface a single number to rubber-stamp — we surface the disagreement between the personas, the bull case beside the bear case, every claim tagged with its source, and hard gates that won't let a strong average bury a dealbreaker. The engine is built to make a partner think harder, not less. And the final call carries a name, which is a very effective cure for nodding along.

Observable by design

A non-deterministic engine is only trustworthy if you can see inside it, and prove it's improving.

Every run is traced end to end: each prompt, each tool call, each result, nested under the deal it belongs to, with latency and cost down to the cent. When a call looks off, we open that exact run and read why the model landed where it did. No shrugging at a black box.

[ SCREENSHOT — a LangSmith trace for one deal: the run tree with the orchestrator at the top and sub-agents/tool calls nested beneath, token counts, latency and cost per span visible. Caption: one deal, one trace — every step, every cost, one filter away. ]

And nothing ships on a hunch. We keep an eval set — the deals we've scored and annotated, young now and growing with every run — and replay every change across it: a new prompt, a newer model, graded both by a model against a rubric and by us. If it regresses on any slice, it doesn't ship. We can point at the before and the after.

[ SCREENSHOT — the LangSmith experiment comparison: a prompt/model change scored side-by-side against the live baseline across the eval dataset, with the regressed slice flagged. Caption: nothing ships on a hunch — every change graded against the baseline before release. ]

[ SCREENSHOT — the LangSmith prompt hub: a prompt with its version history. Caption: every prompt versioned, diffable, and rolled back like code. ]

Stack. Everything is instrumented in LangSmith:

• Tracing — each analysis is one trace; the orchestrator and every sub-agent and tool call nest beneath it as child runs, with inputs, outputs, token counts, latency and cost per span, tagged by deal. Any run is one filter away.

• Prompts — versioned in the prompt hub and pulled at runtime, so a change is a tracked revision we can diff and roll back, not an edit buried in code.

• Evals — run off Datasets we build from the deals we score, each with our annotations as the reference. The set is young and grows with every run. Graded by LLM-as-judge evaluators against per-field rubrics plus deterministic checks; every prompt or model change runs as an experiment against the live baseline, and a regression on any slice blocks the release.

An analysis_runs table logs each orchestrator run. Models: Claude Opus for the deep agents, Sonnet for the lighter passes, all via OpenRouter.

Why, and what it's worth

Why we built it this way

We built our own rails

We didn't start here. We've run a rough version of this since GPT-4 first shipped — a handful of n8n workflows stitched together, ugly but working, screening real deals years before we rebuilt properly.

[ SCREENSHOT — the original n8n workflow, early 2023. Caption: version one. Crude, but working — and years before we rebuilt. ]

That rough version taught us more than any plan could have. We'd already run into the thousands of edge cases a live deal flow throws at you, and we'd made our first crude attempts at codifying the mandate into something a machine could apply. It was rudimentary — but it put us years ahead of a blank page, and it told us where the hard problems were before we spent real money on them.

So when we rebuilt in earnest, the build-versus-buy call split in two. The off-the-shelf VC products — Kruncher, Harmonic, one of the many shipping almost daily — are finished tools: buy one and you're running the fund on someone else's opinion of how to screen a deal, baked into a box you can't open or bend to your own mandate. Fast no. The general agent platforms — Relevance AI, Gumloop, Lindy — are a different animal: you don't buy an answer, you build on top of them. So the real question was whether to build on one of those or go a level lower.

We went lower, onto composable rails we own — orchestration, reasoning and an eval layer we can rewire ourselves rather than wait on a vendor to. The general platforms are opinionated and closed exactly where we needed the most control: how the agents are wired, and being able to see and change why a run did what it did. The week a better model lands and you want to re-point a workflow, a layer you don't own is the thing standing in your way.

Even inside our own rails there was a leaner version: run the whole thing in LangGraph and drop n8n entirely. LangGraph can orchestrate, and one fewer layer is one fewer thing to maintain. We kept n8n anyway, and the reason is the connectors. A deal touches dozens of outside systems — inbox, CRM, Slack, the data tools — and n8n already speaks to all of them, with the retries and rate-limit handling that plumbing needs, off the shelf and proven. Rebuild that inside LangGraph and we'd be hand-writing integration code that already exists, and threading every flaky API call through the layer we most need to keep clean. So n8n stays as the outer skin and hands off to LangGraph the moment there's something to actually reason about.

The ground moved under us mid-build more than once. The morning Anthropic shipped its agent platform, we were sure we'd been leapfrogged — then we looked closely, and it wasn't built for what we need. That will keep happening, and it's the point: we assume we'll be re-pointing this thing most weeks. Owning the rails is what makes that a Tuesday afternoon instead of a migration.

Stack. The rails we own:

• n8n — orchestration and I/O

• LangGraph — the reasoning state graph

• LangSmith — tracing and evals

n8n is the outer layer and calls LangGraph when it's time to reason: n8n handles the connectors and plumbing, LangGraph the stateful agent graph. Do it all in LangGraph and the I/O tangles into the reasoning; do it all in n8n and there's no real agent state to work with.

We passed on two kinds of off-the-shelf. The finished VC products (Kruncher, Harmonic and the rest) bake someone else's screening logic into a box we can't open or bend to our mandate. The general agent platforms (Relevance AI, Gumloop, Lindy) you build on top of — but they're opinionated and closed exactly where we need control: functionality you can't add, and no clear view of why a run did what it did. So we own the layer beneath both.

We made a few hundred calls like this one. The full set, tool by tool, lives in the build log →.

Bolting AI on is the easy part

Screening with AI is easy now — the tools are everywhere. The real choice is whether to bolt them onto a 2015 process or rebuild the process around them. We rebuilt from scratch, which is what the pause was for. Why we paused to do it →

And the hardest part of that rebuild had nothing to do with the AI.

The hard part was writing down what we believe

The engineering was the easy half. The hard half — the part that took longest and broke most often — was turning the part of a partnership's judgment we can actually score into something a machine could apply: the assessable dimensions of a deal, not the call itself. The call stays with the partner.

A fund runs on a thousand unwritten calls: what counts as too early, which "ugly industries" we'll back, how much a thin market matters when the founder is exceptional, whether a second-time founder who blew up the first company is a red flag or the best bet on the table. None of it was written down, because it never had to be. It lived in the partners' heads and came out in the room.

To screen against our mandate, we had to drag all of it into the open, as an explicit system: every criterion that matters written down with what strong, adequate and weak actually look like, the claims that sound impressive on a deck but shouldn't count, and — kept private — the hard numeric thresholds behind each one. That forced arguments we'd ducked for years, and the disagreements were the most useful part of the whole rebuild. You find out what a firm actually believes when you have to write it down and defend it against a held-out set of our own past deals.

Take one criterion: "is this founder a real insider." As an instinct it's a feeling in the room. As a rubric it's observable signals — domain depth, lived operating time in the industry against credentials on paper — with the impressive-sounding claims that don't count flagged as anti-patterns, so a polished deck can't score its way past a thin one. Each criterion rolls up into one of six dimensions we judge a company on, and the bar flexes by stage: what's strong at pre-seed isn't at seed.

[ SCREENSHOT — the Evaluation Rubrics database: each criterion scored Strong / Adequate / Weak, with the anti-patterns that shouldn't fool it. ]

[ SCREENSHOT — the Screening Rules database: hard gates and soft flags, each with the conditions that can redeem a flag. ]

Stack. Three linked Notion databases sync into the engine:

• Screening Rules — the gate. Hard gates (an automatic decline if failed) and soft flags (a concern to probe, each with explicit redemption conditions that can clear it).

• Evaluation Rubrics — each criterion defined at Strong / Adequate / Weak, with the anti-patterns that shouldn't score well and private quantitative anchors.

• Assessment Dimensions — the six dimensions criteria roll up into (Founder & Team, Market & Problem, Competitive Advantage, AI Depth, Traction & Validation, Business Model), each with stage modifiers and evidence weighting (which artifact to trust when they disagree).

Only rules marked Live feed the prompts.

It's never finished. The mandate shifts, a house position turns out wrong, the market moves — so the rubrics get re-tuned constantly, and nothing changes without being tested first.

You can't outsource this

This was built in-house. Our Operating Partner did the building; external developers came in only on the parts that needed them — the firm drove it and hired help where it made sense, never the other way round.

That order is the whole point, and getting it backwards is where these builds usually fail. You cannot brief this out, and you cannot "project-manage" it from across the room. Wiring up the tools is the part a freelancer can do. The actual work is knowing every intricacy of how the firm decides — what counts as too early here, which contrarian bet the partners would back, the house position we hold on a thin market — and none of that is written down anywhere. It takes five years inside a firm to absorb, and it only comes out of you under the pressure of having to encode it, call by call. Hand the whole thing to an agency and you get a polished system that automates a generic version of a job nobody actually does.

So you can't do this on the side, between board meetings. You have to stop — the way we did — and go deep yourself. We're not AI engineers, and we've never pretended to be: our edge is investing at seed and, now, knowing how to codify it. The engineering you can learn or hire. The judgment you have to already own — and be willing to put everything else down to write out.

What it buys

Time, and a fairer read

The point of all of it is time.

Hand the grunt work — the sourcing, the first reads, the market maps, the monitoring — to the engine, and the partners get back the hours that used to vanish into it. Those hours go where they always should have: across the table from a founder, phone down, doing the one thing that actually wins deals.

There's a second payoff, and it's the one we're quietest about. A model has no ego and no FOMO. It doesn't favour the founder who came through a friend, or talk itself into a weak deal because the deck was slick and the week was long. Left to our own devices, fund managers do all of that — bias, ego, nepotism and the fear of missing out are the oldest ways venture argues itself into bad calls and out of good ones. The engine gives every deal the same level read, and hands the partner a fairer starting point than instinct alone.

For the founder on the other side, that's the deal: their company gets the full work-up whether or not they know someone, they hear back faster, and a person decides in the end — not a score.

The brain gets sharper every deal

Every deal the engine analyses lands in the memory the next one is read against, logged with its result — win, loss or pass. Right now that memory is young: our own portfolio and the open market, thickening one screened deal at a time. But the loop is already running — as bets resolve, the scoring recalibrates against what actually happened, and when a partner overrides the engine we log who turned out right. The mechanism is live today; the edge it builds compounds from here — more shots, more signal, sharper pattern recognition.

Throw away every tool named in this piece and the brain keeps growing. The asset is a decade of judgement finally written down as a rubric, plus a decision log that gets denser every week. A fund that started screening with AI last quarter can't buy its way to it; it only accrues to whoever was reading deals this way first.

What it asks of us

What we're willing to risk

Building this way means being willing to let things break. Move at the pace the technology actually moves, and you accept that an agent will misread a deck now and then, a workflow will fall over overnight, a model update will shift an output you'd dialled in. We'd rather hit those and fix them than play so safe we never find the edges.

We can run that risk because of where the human sits. The engine can break in a hundred ways and the worst case is wasted compute and a re-run — annoying, never dangerous. The one decision that can't be allowed to break is walled off from all of it: a partner makes the final call on every deal, by hand. The plumbing is allowed to fail; the decision never is.

The edge cases we'll never close

The engine handles the deal it was built to handle. The catch is that the deals that return a fund are often the ones it wasn't built for.

Take a real one. The market agent sizes a market independently and checks the deck's framing against it. Point it at a company creating a category that doesn't exist yet and it does exactly what it's told: it finds no market data, because there isn't any to find, and flags a thin opportunity. On the engine's read, that's a decline. But "there's no market yet" is the precise shape of the best seed bets — the ones where the data says no, right up until they define the category. Trained only on the past, a model reads "different" as noise and deletes it; a partner who's seen the pattern reads the same signal the other way.

That's one. There are thousands: the insider with no legible CV, the metric that looks broken but isn't for this model, the regulatory hurdle that reads as a risk but is the moat. We catch the ones we can and write fresh rubrics for them. We will never catch them all — the supply of weird is endless, and the deals that matter most are the weird ones. That's not a flaw we're slowly engineering away. It's the permanent reason a human sits on the gate: the engine is superb on the deals that rhyme with the past, and a person is there to fish the outliers back out of the basket it files under too-hard.

We'll burn this down

None of this is finished. It can't be. Standing an AI system up is the easy day; keeping it honest — run after run, as the models shift underneath and a workflow falls over overnight — is the actual work, and it doesn't end. Anyone claiming their AI just runs itself is describing the one thing it never does. The tools underneath re-rank every few months, and models that didn't exist when we started are already better at half these jobs. So we hold the engine loosely. We expect to take a torch to most of it inside six months and build the next one — then do it again after that.

That only sounds reckless once you remember what survives the fire. The engine holds no memory of its own by design; the brain it feeds — the comparables, the calibration, the thesis — lives in the record, not the wiring. It's the same design that keeps the analysis live: when new context lands — a transcript, an email, an updated deck, a stage change — an orchestrator works out which stages it actually touches and re-fires only those, instead of starting over. Burn the tooling to the ground and every bit of that is still standing.

The next version of this will read nothing like the one you've just seen. That's the point.

The build log: every tool, and why we chose it →.

Part one — why we paused new investment for three months.