Skip to content

Future

The system today covers the first, most repetitive slice of U2V's data work. Three bigger bets shape where it goes next — and all three deepen the same foundation the vision rests on: a company brain that is cheaper to run, and that gets smarter the more U2V uses it.

The first is about cost. The other two are about memory — and they map cleanly onto the brain analogy: a short-term loop that learns from how we act on recent deals and LPs, and a long-term store of the convictions we build up about sectors over years.

Directions, not commitments

This is where the thinking points, not a locked roadmap. Each project below is worth scoping properly before it's built.

1. Cost — offload the lighter work to open-weight models

The single biggest cost lever is not using a frontier model for every step. Much of the work in a workflow — extraction, classification, cheap structuring — doesn't need frontier-level reasoning. Those stages can be routed to open-weight models (for example Google's Gemma family) self-hosted on a cloud server, where the bill is hardware, not per-token. The genuinely hard judgment — LP matching, the scoring stages of dealflow, the research in LP intake — stays on Opus 4.8.

Why this is the biggest near-term lever:

  • The wiring is already there. Model choice is a per-stage config.yaml knob (see the reasoning layer), so redirecting a stage to a different model is configuration, not rearchitecting.
  • There's a real number to beat. A full startup intake costs roughly $1.80 today. Splitting the work — frontier where it matters, open-weight where it doesn't — should cut that materially.
  • It scales the right way. As volume grows toward the vision's 4,000 startups a year, unit cost should fall, not rise.

The concrete first step is analysis, not code: understand the pricing of cloud-hosted open-weight models against today's per-token costs, then decide, stage by stage, exactly what can be offloaded without losing quality.

2. A brain that learns — from our deals and our LPs

Today two things start from a fixed picture every single time: how a startup is scored, and what each LP is assumed to want. Neither learns from what the team does next — yet that behaviour is the most valuable signal U2V produces, and right now it evaporates.

The bet is a self-reinforcing feedback loop with a short memory window (roughly three to four weeks from when a record is created): it watches how the team actually acts, accumulates what it sees, and every couple of months surfaces proposals a human approves. It runs on two fronts.

Loop A — what's in scope (deal scoring)

The system watches how the team interacts with a deal after intake — funnel moves, call notes, the reason written when it's passed — and compares that to the score it originally gave. When a startup scored highly at intake sits at Passed four weeks later with a reason attached, that gap is the lesson. Over time it proposes refinements to the scoring rubrics so they mirror how U2V actually invests, not a thesis frozen at the moment of intake.

Loop B — what each LP wants (LP interests)

This one plugs straight into the matching mechanism that already exists. Today u2v-lp-match and u2v-lp-share read each LP's strategic_interests profile from the Soft LPs U2V list (the LPs with dealflow_sharing = Yes) and match startups by flagging them on a deal's lp_relevance attribute. But when a U2V team member adds or removes an LP under lp_relevance on a new deal, that's a correction — direct evidence of what that LP actually cares about — and today it teaches the system nothing: the strategic profile stays static.

The loop closes that gap. Over the window it tracks which topics get flagged to which LP via lp_relevance. When a sector keeps landing on the same LP — say warehouse logistics repeatedly gets flagged to Airbus — that's a signal. Every couple of months it proposes:

"Warehouse logistics has been flagged to Airbus several times this period — consider adding it to Airbus's strategic profile."

A human approves, the LP's strategic_interests grows, and every future match for that LP gets sharper — the fund's picture of each relationship compounds instead of resetting.

Both loops stay true to the principles

They produce proposals, not overwrites — the team always decides (see Design principles) — and u2v-dealflow already reserves a feedback/ seam for exactly this harvest. The result is the promise in the vision made literal: a system that gets smarter — about both deals and LPs — the more we use it.

3. Sector convictions as long-term memory

Where project 2 is short-term memory, this is long-term memory — and it may be the most valuable of the three.

Every deep dive into a startup or a thesis generates real proprietary conviction: a belief in a technology, a read on a market, a reason a space is or isn't for U2V. Today that conviction is lost. The work happens in Claude and the terminal, the debate happens on calls — and once a deal is passed, none of it is captured anywhere. The fund re-learns things it already knew.

The idea is to give the brain a place to keep those convictions, organised around topics that are exactly the U2V Sector-II taxonomy — Edge AI under AI & Novel Compute, and so on. Concretely:

  • A new Attio object per topic/sector — a living, collaborative scratchpad of everything U2V believes about that space.
  • Populated over time by consolidating deep dives and discussions into it (or having the system fetch and file work already done).
  • Pulled back into context whenever a new startup in that sector is evaluated — so the assessment stands on the fund's accumulated conviction, not a blank slate.

This runs in the same direction as project 2 — a brain that learns — but organised around sectors rather than individual deals. Done well, it captures the proprietary beliefs the U2V team has built over decades and makes them retrievable exactly when the next relevant decision comes up.

Shape this with us

These three are where the vision points hardest. The way to start any of them is the same as everything else here: name the task, and hand it to Klaus. When you want to scope one concretely, open the repo in Claude Code and build from the existing automations as templates.