Somewhere between my 400th commit and the 800th draft of the PRD, I stopped and asked myself what category this thing actually belongs to. Not feature by feature. The whole shape. If I had to explain it to someone who doesn't care about my codebase, what would I call it?
For a few weeks I've had a nagging feeling that the answer was hiding in plain sight. It came out of the analogy I kept reaching for in conversations. You know what Cursor or Claude Code did to coding. There's now an ambient layer sitting on top of an engineer's work, reading their codebase, remembering what they've been doing, writing with them instead of for them. I kept trying to explain what I was building by pointing at that. Not an AI assistant. Not another project management tool. Something more like that thing Cursor does, but for running a venture studio.
And then the word showed up: harness.
Those tools aren't apps. They're harnesses.
So here's the question I'm trying to answer with this piece. Is that what I'm building? A venture harness? And if it is, what does that mean, both for the thing I'm shipping and for the people I'd hand it to.
What a harness actually is
Cursor isn't a smarter text editor. Claude Code isn't a chatbot in your terminal. Those descriptions miss the point.
Functionally, they're three things fused into one. A memory of your codebase that is always there and always current. The context doesn't live in a browser tab you lost or a chat history you'll never read again. It lives in the tool. A reasoning layer that does multi-step work, not single-shot answers. It plans, iterates, checks its own output, and revises. And then the last piece: it actually does the work. Writes the code, runs the tests, stages the commit. You approve or redirect. You don't type every line.
That's the harness. Persistent context, real reasoning, and the ability to execute. The human is still the judgment layer. But the bandwidth bottleneck ("I have to hold every file in my head and remember what I was doing yesterday") is gone.
The reason engineering teams started running 3x faster isn't because the AI is brilliant. It's because the harness eliminated a specific kind of tax.
My work has that same tax. Worse, maybe.
I run a venture studio with my co-founders. We don't have a clean separation between consulting and product. Every conversation with a potential client is also a potential venture. Every venture has underlying insights that keep showing up across other ventures. Most of what makes or breaks a deal is relationships and timing, not a slide deck.
The day-to-day looks like this. Monday I'm on a call with a guy who runs an AV installation company. Wednesday I'm in a war room for a client. Thursday someone sends me a pest control opportunity worth thinking through. Friday I've recovered enough to look at the notes I took on Monday, and I notice that something the AV guy said is actually the exact same dynamic as the pest control business. The problem isn't the service. It's the rebooking friction. Now I have a pattern.
But the Monday notes are in Notion. The Wednesday war room thoughts are in a Google Doc. The Thursday pest control stuff is in a voice memo I never transcribed. The Friday connection is in my head and will probably leak out of it by Sunday.
Every studio I know runs this way. The good ones have someone whose full-time job is being the connective tissue. That person is expensive, burns out, and can't scale.
What I actually need, at the size we're at, is a harness. Not an app. Not a PM tool. A layer that sits on top of all of it and doesn't forget.
What a venture harness has to do
If I take the engineering analogy seriously and work out its implications, three things fall out.
One: the context has to be real, and it has to compound. When I talk to the AV guy, the system should take the raw transcript and break it into structured observations (one per venture or domain the call touched) and tie them to the people involved, the open opportunities, and anything relevant I've said or noticed before. The tenth conversation about local service businesses should be smarter than the first nine. That's the spine. Persistent, structured memory that lives outside any one chat.
Two: the thinking has to be multi-perspective, not one confident voice. Engineering harnesses get away with "just do the thing" because code is verifiable. You can run it. A venture decision isn't, and doesn't. It fails quietly six months later. So the reasoning layer needs to act like a council, not a consultant. Five agents running in parallel, each with its own prompt, its own tools, its own view of the context: a market strategist, a feasibility analyst, an operator, a devil's advocate, a financial modeler. They each read the spine, each produce an independent evaluation, and then a synthesis agent consolidates them into one briefing that surfaces where they agree, where they disagree, and what's missing. The thing I'm supposed to decide on gets decided with actual debate behind it, not one confident voice pretending to be five.
Three: it has to do the damn work. This is the part I got wrong at first, and Tomas pushed me on it. If the system just files observations and writes nice summaries, it's a librarian. A harness doesn't do that. If I mention the AV guy is ready for a pricing conversation, the harness should already be drafting three pricing options, pulling comps from similar deals, writing a stakeholder questionnaire for his operations lead, and sizing what this looks like at scale. It presents all of it as drafts I approve or redirect, the way a coding harness shows me a diff.
Spine, brain, hands. Those are my names for the layers. The three-layer pattern itself isn't mine. It's what engineering harnesses already do, translated into a domain where the primitives happen to be ventures instead of files.
What this changes if it works
The honest version of why this matters: small studios with strong judgment lose to big firms with bad judgment, because big firms can afford five people to be the connective tissue. If the harness works, that structural disadvantage goes away. Three of us can operate across thirty opportunities and a dozen active ventures without things leaking between calls, tabs, and notebooks.
Judgment becomes the scarce resource. Which is the right answer, because judgment is the thing humans are good at. Bandwidth stops being scarce, which is also the right answer, because bandwidth is the thing AI gives you cheaply.
The other shift, which I think is under-appreciated: the harness is where the studio actually learns. Right now most studios run on one person's head. Every pattern noticed, every lesson paid for in a failed deal, every "this kind of conversation always goes sideways at month three" intuition lives in whoever remembers it. When that person leaves or burns out, the learning goes with them. A harness that holds the observations, the insights, the half-drafted work product means the studio is learning as a system, not as a collection of individuals. My co-founder walks into something I started and just keeps going, because the learning lives outside my head.
Zoom out further: if this shape works for a venture studio, it plausibly works for any business where ambient context is the bottleneck. Agencies. Holding companies. Family offices. Small investment shops. Anywhere a few people with strong judgment are managing a portfolio of things that don't fit cleanly into one tool.
That's the thing that makes "harness" the right word instead of "app."
What I'm not sure about
A few things I'm still working through.
The engineering analogy is load-bearing in this whole piece. Engineering harnesses work partly because code is objectively testable. You can run it. The loop is tight. Venture work is squishier. You find out months later whether you were right. That makes the multi-perspective council pattern important, but it also means I can't use "does the code work?" as a forcing function for whether the harness is useful. I'm going to have to invent the equivalent. I'm not sure yet what it looks like. Maybe it's revenue. Maybe it's velocity through stage gates. Maybe it's something I haven't thought of.
The other thing: engineering harnesses had the advantage of a clean primitive. The file. The function. The commit. A studio's primitives are messier. Observations, insights, opportunities, ventures, people, work items, documents. I've picked seven. That might be the right number. It might be three too many or three too few. I'll know in a month.
And the thing I keep going back to: if this is real, why isn't anyone else doing it? The most likely answer is that the venture studio as a category is small enough that the opportunity looks niche. The answer I'm hoping for is that the underlying tooling (agent APIs that can actually hold state, run multi-step work, and do things) wasn't good enough until now, and that window just opened. Probably some of both.
If you run anything where context leakage is the actual bottleneck (a studio, an agency, a holding company, an investment shop), tell me whether this framing clicks or whether I'm just fitting an analogy too cleanly to a thing that resists it.
I'm going to keep building either way. The worst outcome isn't failing. It's building the wrong thing well.