Garry Tan Just Described My Setup. Then I Noticed What He Left Out.

Validation is a strange drug. You get a hit of it and for about ten minutes you feel like a genius. Then, if you're paying attention, you start asking why you needed it.

Last week Garry Tan, president of Y Combinator, gave a 21-minute talk called The New Physics of Business. His argument: the leverage in AI isn't in the model. Everyone gets the same Claude, the same weights. The difference between the person getting 2x and the person getting 100x is entirely in how the work is wired around it. Skill files that act like employees. Routing tables that act like an org chart. A curated library of everything you know, with a librarian deciding what goes into the model's context for each job. He called it "a workforce made of markdown."

I sat there watching the president of YC describe my Tuesday.

The machine he was describing

For the past several months I've been building exactly this, without knowing it had physics. A vault of plain markdown files that holds everything: projects, research, health logs, a schema that says where each kind of thing lives. Skills that encode how I write, how I capture, how I publish. A routing file that tells the AI which environment handles which job. A fleet of specialised agents for the software side. A mission-control register so nothing lives in my head, because my head, like everyone's, holds about seven things.

That last point is the core of Tan's argument, and it's the bit I'd defend to anyone. Human working memory caps at roughly seven items. An AI agent's context window holds about a million tokens, which he translates as three Harry Potter books. But your accumulated knowledge is a library, not three books. So the decisive skill isn't prompting. It's deciding which three books are open on the desk when the agent starts work. He calls the asset a company brain: a library plus a librarian. The retrieval technology is a commodity. Being worth retrieving from is not.

I didn't build my version because a talk told me to. I built it because I kept losing things: decisions, half-finished projects, the reason I'd started something three weeks earlier. The system exists because my memory doesn't scale. It turns out that's the same reason a 400-person organisation exists, which is roughly Tan's point.

The two gaps he found in my machine

Smugness has a short shelf life. Two of his disciplines landed as direct criticism of how I actually operate.

The first he states as a rule: never do one-off work. If a task comes out right, capture the method as a skill before you move on. If you find yourself asking for the same thing twice, the failure already happened. I do this maybe half the time. The other half, I solve something by hand, feel clever, and solve it by hand again a month later.

The second is hygiene. A knowledge library without provenance checks, contradiction checks and active pruning doesn't stay a library. His phrase for the failure state is a garbage dump with great search. My vault is now large enough for that to be a live risk: notes that were true in May, confidently retrieved in July.

Here's the thing about writing in public: you can't describe a gap and then not close it. So the same day I watched the talk, both went into the operating system. The skillify rule is now a numbered line in my working protocol, and the AI runs the check at every task close, because any rule that depends on me remembering it is already dead. The hygiene pass is now a monthly recurring job: staleness, contradictions, pruning, with a human eyeball on anything that gets merged or deleted. Two gaps named on a Tuesday, closed on a Tuesday. The machine is why that's possible.

I even checked his open-source memory layer, GBrain, to see if I should swap anything out. Verdict: no. It's good work, but it would mean adopting a database, a young codebase and someone else's conventions to get what the vault already does. The concepts travel. The tooling can stay where it is.

The word the talk never says

Now the uncomfortable part, and the actual reason I'm writing this.

Tan's evidence is YC companies: nine-figure revenue in months, tiny headcounts, batches that are the most profitable in history. Fine. But every one of those examples had YC's capital, YC's network and YC's distribution behind it before the first agent was ever wired up. The talk is 21 minutes about production capacity, and it does not contain the word customers.

I noticed because that's my gap too. I run the machine he describes. It works. In the last two months it has shipped a trading system, an open-source estate tool, a newsletter, and around 140 build-in-public posts, on evenings and weekends around a full-time bank job, after thirty-eight years in corporate life. Production capacity was never my constraint.

Demand is. Most of my portfolio is pre-revenue. That's not the machine's fault. No agent fleet fixes it, because it isn't a wiring problem. It's the older, harder problem of making something enough people want and putting it in front of them. A perfect brain with no one asking it questions is still just a very well-organised diary.

So the honest summary of the best talk I've watched this year: the president of YC confirmed my architecture and, by omission, confirmed my real problem. Building the machine flatters the builder instinct. Mine needs no more flattering. The next season of this blog is the unglamorous half: audience, offers, revenue, in public, with real numbers, using the machine rather than improving it.

If you're building your own workforce of markdown, genuinely, start. The architecture is right, the cost is near zero, and you own it in a way you'll never own a model subscription.

Steal these three

If you take nothing else from Tan's talk or this post, take these. Each is specific enough to do today.

1. The skillify rule. The second time you do any workflow by hand, capture it before you move on. Captured means a plain markdown file your AI actually reads: what triggers it, the steps, what done looks like. Mine went in as a numbered rule in my working protocol plus one trigger line in the AI's own instructions, so the check runs at every task close without me having to remember it. Any rule that depends on your memory is already dead.

2. The monthly hygiene pass. Thirty minutes, once a month, four checks: notes that claim things which are no longer true (start with the ten your AI retrieves most); two notes that disagree with each other (ask the AI to find them, it's good at this); anything you'd be embarrassed to have confidently retrieved (delete or archive it); and provenance, meaning every claim that decisions rest on says where it came from. Mine is a recurring register entry with a date on it. A library without a librarian is a garbage dump with great search.

3. The one file the whole system serves. Here's the problem with everything above: the vault, the skills, the hygiene pass all help you build. Nothing in the system asks whether anyone wants what you're building. So create one file that does. Mine is called WHO-IS-THIS-FOR.md and it sits at the root of the vault. At the top, the question: who is this for, and have I asked them? Underneath, the honest current answer, in writing. Mine names the people I'm actually doing this for, people using AI to build a better life and stay relevant in what's coming, and then admits that I've barely asked them anything: posts published at them, not conversations with them. The mechanism is what makes it work: the file gets read at the start of every working day, before any new building, so the question stands in the doorway each time the builder instinct reaches for something shiny. Two minutes to create. The only item on this list aimed at the gap Tan's talk never mentions.

The full walkthrough of the machine, actual files on screen, is coming as a video. The newsletter will tell you when it ships.

I created my file while writing this post. The answer under the question is thin, and it's going to be embarrassing to read every morning until it isn't. That's the point.