How it works¶

You don't need to be technical to use any of this — you just email Klaus. But it's worth having an honest, high-level picture of what's actually running when you do, what lives where, and — most usefully — how anyone on the team can change it. No code required to follow along.

One address, one flow¶

Everything runs through a single shared inbox. When you email klaus@u2v.vc, the system:

checks it's from the team (nobody else can trigger anything),
reads it and works out what you want — a deck to screen? an LP list? a task?,
does the work with the right automation, and
replies with the result — a score, a document, a confirmation.

flowchart TD
    You["You email klaus@u2v.vc<br/>(a deck, a name, a request)"] --> Klaus
    Klaus["Klaus figures out what you need"] --> Work["The right automation does the work"]
    Work --> Attio[("Attio — the company brain")]
    Work --> Reply["You get a reply:<br/>a score · a document · a confirmation"]

You write in plain language — no commands to memorise — and if your email is missing something it needs, Klaus writes back and asks instead of guessing.

What's actually running¶

A few honest facts about the machine behind Klaus:

It's mostly ordinary Python. The bulk of the work — reading files, moving data, building documents, deciding what's a duplicate — is deterministic code. Claude is only called where real judgment is needed: classifying an email, scoring a startup, researching an LP. That keeps the system reliable and cheap, and points the expensive thinking only at the parts that need it.
It runs on a schedule, not on a server. The code lives on GitHub, and GitHub Actions runs it automatically about every 30 minutes, kicked off by an external timer. There's no machine humming in an office and nothing on anyone's laptop — which also means there's up to a ~30-minute delay between sending an email and getting a reply.
Attio is the hub of everything. Every automation reads from and writes to Attio; it's the single source of truth the whole system runs on. Keep it clean and everything downstream gets better.

(The full picture — the exact tools and schedules — is on the technical Structure & orchestration page.)

The engine and the dials — what lives where¶

The most useful thing to understand is that the system is split in two on purpose:

The engine (the code)	The dials (settings & wording)
The pipeline logic and the machinery that scores a deal, talks to Attio, sends the email	The scoring weights and the scoring rubric wording, the sector lists, the document templates, and which Claude model runs each step
Changing it is a real code change (bigger, rarer)	Made to be tuned without touching the engine

So, for example: how a startup is scored — the exact rubric and how much "team" counts versus "market" — isn't buried in the engine and it isn't a hidden setting. It lives in editable files in the repo, deliberately pulled out so it can be adjusted on its own. Change those and the behaviour changes; the engine stays put. This separation is the one rule the whole codebase is built around (the technical name for it is the data-vs-logic seam).

Changing things: VS Code + Claude Code¶

Here's the part that makes the above practical. Everything — the engine and the dials — lives in one place (the repository), and the way you change any of it is by opening that repo in VS Code with Claude Code and asking in plain English.

"Make the team score count for more than the market score."

"Add 'Edge AI' as a sub-sector."

"Change the sample deck to five deals per sector instead of four."

Claude Code finds the right file and makes the edit — you don't have to write the code yourself. Tuning a dial (a weight, a rubric, a sector) is quick and low-risk; a change to the engine is bigger but works the same way — you describe what you want.

Never opened VS Code before?

The Getting set up in VS Code page walks you from zero — installing the editor, opening the repo, and asking Claude Code your first question.

The Claude side: models and cost¶

Because Claude is only used where judgment is needed, the system is cheap to run and easy to re-tune. Which model handles each step — a fast, cheap one for simple extraction, the strongest one for hard scoring — is itself just a dial: swapping a model is a one-line change, no engine work.

Today every one of those calls goes to a paid Claude model. The clearest lever for the future is to move the lighter steps to open-source models we host ourselves — keeping the strongest Claude models only for the hardest judgment — which could cut cost substantially. That's sketched out under Cost, in Future.

Guardrails, and always your call¶

The system is built to stay inside safe lines:

Only the U2V team can trigger it — an unknown sender is ignored.
It asks instead of guessing — unclear or missing details get a clarifying reply, never a speculative action.
Everything it does is recorded in Attio, visible and reversible.
A human always decides. The automations prepare, structure, score and surface — but the choice to pursue a startup, approach an LP, or send a document is always yours. Nothing moves forward without a person choosing it.

Want the plain-language tour of each automation? What it does today. Want the full engineering picture? Head to the Technical section.