A Company With Legs
A company that can’t run without its founder is a shallow company — and shallow is the thing I keep arguing against. The same distinction I drew through the product in Deep AI and the End of the Disclaimer and through verification in The Adversarial Agent Fleet, turned on the org itself.
The same line, one more place
I keep coming back to one distinction. In Deep AI and the End of the Disclaimer I drew it between a thin wrapper that points a model at a whole problem and hopes, and a deep system that decomposes the problem until only an irreducible kernel of genuine judgment is left for the model to touch — grounded in retrieved evidence, constrained to its domain, and checked by something built to attack it. In The Adversarial Agent Fleet I drew the same line through verification: a single agent’s confidence is not evidence, and the fix is structural — an adversary built in from the start, not a better prompt bolted on at the end.
That distinction has an organizational form. It’s the difference between a company that can show its work and one that can only show its results.
If you got hit by a bus tomorrow, what is your company worth on Thursday?
For most early companies the honest answer is “a great deal less than it was on Monday.” That gap — between what the company is worth with the founder in the chair and what it’s worth without them — is the most important number nobody puts on a slide. It is also, precisely, the shallow-versus-deep line, drawn through the org instead of the product. This essay is about closing it.
The shallow company
A shallow company is one where the founder, or a handful of senior heads, is the system. It produces results — sometimes excellent ones — but it cannot show its work. It can’t trace why it works, can’t transfer how it works, can’t stand behind the output without the specific person who generated it standing right there. The run-rate is the confident answer. “It works because I’m in the room” is the disclaimer printed in the smallest available font.
And a shallow company fails the same way shallow AI does: it holds up beautifully right until something tests it. The founder leaves. A key engineer quits. A buyer runs diligence. The market moves under the assumptions nobody wrote down. In Deep AI I called the regulated-domain version of this better-looking documentation that fails faster. The org has the same failure mode — a company that looks more impressive every quarter and is no more able to survive the loss of any single person than it was the day it started.
John Warrillow has spent a career on the financial proof of this. We confuse profit with value, and they are not the same thing. A buyer isn’t paying for last quarter; they’re paying for the future earnings they can keep after you’re gone, discounted hard for the risk that those earnings walk out the door with you. His line in Built to Sell is blunt: a company that can’t run without its owner isn’t an asset, it’s a job. The evidence backs the slogan. Only twenty to thirty percent of businesses that go to market actually sell, and owner-dependence is the most common reason a deal dies; companies that demonstrably run without the owner sell for materially more, on the order of seventy percent above the average. Transferability is value. Everything else is a photograph of a good Monday.
This lands hardest on exactly the company I’ve spent these essays arguing for. The AI-native operating model runs lean and senior by design — every role a human running a fleet of agents that absorbs the volume. That is extraordinarily efficient, and it is extraordinarily concentrated. In The Ladder We Pulled Up I wrote that a company built entirely on senior operators is one retirement wave, one acquisition raid, one health event away from a knowledge cliff. I was talking about the talent pipeline then. The same fragility describes the whole company. The leaner and more senior you run, the more of your value lives in a small number of heads, and the more of it is a shallow system wearing an impressive number.
Deep is the alternative, and resilience is its output
The fix is the same one, one level up. You build the org the way you build a deep system. You decompose the work — figure out which parts are provably repeatable and which parts are the irreducible kernel of genuine judgment. The repeatable parts get encoded into systems you can inspect. The judgment kernel stays with a human, grounded in real context and checked the way I argued judgment has to be checked in the Adversarial Fleet — not trusted because it sounded confident.
Resilience is not a separate goal you bolt on. It is what comes out the other side of building the company deep. A deep company can show its work, so it can survive scrutiny. It has externalized the repeatable judgment into systems, so it can survive the loss of the person who first had it. That’s the asset. Not the revenue, and not even the systems — the fact that the performance no longer depends on any single piece, the founder included.
Resilience is not stability
Here the intuition goes wrong, and it’s worth slowing down. “A company with legs” sounds like solidity — lock the processes down, freeze the playbook, make it rigid enough to run without you. That instinct builds the wrong thing.
Nassim Taleb’s distinction is the useful one. The fragile breaks under stress. The robust withstands it. The antifragile gets stronger from it. Founders reaching for durability tend to build for robustness and accidentally build for rigidity — and rigidity, in a world where the facts on the ground decay fast, is just fragility on a delay. Your market moves. The tooling moves, faster than any category I’ve built in. The regulations move; I wrote a whole essay about four of them moving at once. A system cemented on last year’s truth and walked away from is a liability wearing the costume of an asset. It will keep executing, confidently, long after the ground it stood on is gone.
So resilience is not a pile of fixed systems. Resilience is governed adaptability — a system for changing systems. I spent years in fault-intolerant engineering before this, and the principle there is identical: a robust system is not one that never fails. It is one that expects to fail in parts, notices when it does, and reconfigures without the whole thing coming down. A company is the same problem, slower and messier, with people as the components and judgment as the thing you are trying hardest not to lose.
You can’t decompose what you haven’t survived yet
If the answer is to decompose the work into repeatable systems and irreducible judgment, the obvious move is to start decomposing immediately — write the runbooks, automate the workflows, get it all out of your head. In Building the AI-Native Company I called documentation the architecture of the company, and argued the runbook is the thing that encodes a founder’s expertise in a form that compounds and transfers instead of living in one head. I stand by every word. It is the core move toward a deep org.
But the timing matters more than the instinct admits, and getting it wrong produces a specific failure: a shallow company that looks deep. You cannot decompose a process you haven’t lived through yet. In the first year you do not actually know which parts of the business are stable and which only look stable because you have personally been holding them up. You feel like you’re running a process. A lot of the time you’re improvising, and the improvising is invisible to you because it’s simply how you think. Codify that too early and you don’t capture a repeatable system — you capture a snapshot of your own guesses, formatted to look official, and then people execute it faithfully after the ground has moved. A runbook written before you know what’s real transfers your assumptions with perfect fidelity. That is worse than no runbook, because it’s wrong with a straight face and a process diagram.
What the early money is actually for
This is why I’ve come to think a pre-seed raise has a different job than the one founders usually give it. The pitch is almost always fuel for growth — give me runway and I’ll go faster. But you can’t go faster in a useful direction until you know which direction holds up, and at the start, you don’t.
Get Ray Karnes, Founder & CEO @ auditRAMP(AI)’s stories in your inbox
Join Medium for free to get updates from this writer.
The data on this is old and brutal. The Startup Genome study of more than 3,200 high-growth startups found that 74% of them failed from premature scaling — committing money and people ahead of the evidence that justified it. The ones that scaled properly grew about twenty times faster than the ones that didn’t, and 93% of the prematurely-scaled never crossed $100K in monthly revenue. Premature scaling is efficiently executing the irrelevant. It is decomposing and codifying a business you have not yet earned the right to believe in.
What the early money actually buys is the room to find out what’s real. It buys enough time, and enough real cases, that the business runs into its own edges — over and over, in front of you — where you can watch exactly where it bends and where it snaps. You are not buying scale. You are buying the data that tells you which parts are provably repeatable and which are still you.
I am pre-seed, and I feel this directly. Every dollar I spend has to clear a bar that says this gets us to the next milestone, and under that bar the temptation is to systematize early so I look further along than I am. I’m trying to resist it. I’m not raising to scale. I’m raising to find the business’s real edges before I cement anything — and to do it with evidence rather than conviction.
Which is the same discipline the product runs on, and I’d be a fraud to build the company on a looser one. The product doesn’t point a model at a population and hope; it retrieves deterministically and lets the evidence decide. Its deep architecture solves as much as possible without the probabilistic component. The deep move in the company is the same: decide as little as possible on conviction, and let the cases tell you what to make permanent.
Which parts of this are provably repeatable, and which parts are still just me?
Codify what the evidence earns
When you do codify, treat it as an evidence question, not a matter of taste. A piece of work that showed up the same way across fifty cases and produced the same outcome every time is a candidate for a system — the system will be right about as often as you were. A piece that needed a fresh judgment call every single time, where the call was different because the situation was, is not a process yet. It is still a person thinking, and the right move is to leave a person on it and admit that you have.
The first version of that rule is too clean, and saying so is the whole discipline. Two things complicate it.
The first is that some of what makes a company valuable will never reduce to a rule — the founder’s read on a situation nobody has seen before, the values call underneath a decision. In the Adversarial Fleet I argued that judgment isn’t the reasoning — agents do reasoning now — it’s the values call the reasoning was dressing the whole time. That kernel is exactly what you must not automate away. The honest decomposition isn’t “systematize everything.” It’s separating the genuinely rote from the irreducibly human, encoding the first, and designing the seams carefully enough that when the expert is gone, the system bends instead of snapping.
The second is that early repeatability can be a small-sample illusion. A thing looks stable because it hasn’t been stressed yet. You are always codifying under uncertainty — which means the cemented version has to stay inspectable enough to un-cement when an assumption you trusted turns out wrong.
The keystone is governance
In The Ladder We Pulled Up I leaned on Eric Ries’s Incorruptible for one idea: the commitments that survive scale are the ones written into governance before financial gravity arrives, because afterward no individual has the standing to enforce them against quarterly pressure. I used it there to argue for locking in the talent pipeline. The same machinery does something harder here.
If you codify against the facts, and the facts decay, then a static system is a fast-aging liability no matter how good it was the day you wrote it. Cement a rule and walk away, and you’ve built next year’s constraint with last year’s confidence. What makes codification safe is the layer above the systems — the governance that watches a codified rule, notices when it has quietly stopped being true, and re-opens it on purpose instead of waiting for a failure to force the question. It needs sensing that doesn’t stop once the rule is written, a signal that fires when the rule starts to decay, and a real mechanism for un-cementing something and deciding again, run as routine maintenance rather than emergency.
I argued in the Adversarial Fleet that adversarial verification is an architecture decision, not a feature — that habits set at headcount three are impossible to dislodge at headcount thirty, because by then the habit is the architecture. Living governance is the same kind of decision. Build the capacity to re-open your own rules while the company is small enough that building it in is a configuration choice, or inherit a company whose every habit is to trust the cemented answer and ship.
There’s a failure mode on the other side. A company that re-litigates every rule constantly never gets the compounding benefit of having rules — the entire point of codifying is to stop re-deriving the same answer. The skill is in the thresholds: cement what’s earned it, watch it cheaply, re-open only when the signal actually fires. Living governance is bounded responsiveness. A company that changes everything all the time is exactly as fragile as one that changes nothing, for the opposite reason.
You can only govern what you can see
All of it rests on one requirement that is easy to miss and impossible to skip. You can only govern what you can see. A process you cannot inspect cannot be corrected, because no one can tell when it has gone wrong. It fails silently, and you find out from the customer.
This is the conviction under everything I’ve written. It’s why, in Deep AI, the grounding and the provenance are the product and the model is the smallest component inside them. It’s why, in the Adversarial Fleet, the disagreement gets logged and the verification is structural. And the distrust generalizes cleanly: a black box is a black box whether it’s a probabilistic model, a vendor you can’t see inside, a founder’s gut, or a process frozen on last year’s truth. None of them can be governed, because none of them can be observed going wrong. Inspectability isn’t a nicety bolted onto governance. It is the precondition that makes governance possible at all.
This is also exactly what auditRAMP sells — assurance you can reproduce and inspect, instead of trust on faith. I am building the company on the same principle as the product, because if inspectable, governed, evidence-driven systems beat black boxes for our customers, they beat black boxes in my own org chart and my own head too. The conviction doesn’t get to be load-bearing in the product and decorative in the company.
Where the durability comes from
Step back and it’s one line drawn through every piece of this. Deep over shallow in the product. Deep over shallow in the agent fleet. And deep over shallow in the company itself — a business that can show its work, trace its judgments, survive scrutiny, and keep running when any single piece is removed.
You don’t raise money to build a machine. You raise it to find your edges, to learn which parts of the work are provably repeatable and which are irreducibly yours, to encode the first into systems you can see into, and to govern those systems as living things while the world keeps moving the facts. The company that comes out the other side has legs — not because you froze it into a machine, but because you installed the loop that keeps rebuilding the machine. That loop is the asset. It’s what’s still worth something on Thursday.
Ray Karnes is the founder and CEO of auditRAMP(AI). He writes occasionally about company-building, AI-native organizations, and the discipline of building in this moment.
