Naval's leverage + an HR veteran's playbook — the real compounding in the AI era is in Agents, not in Prompts.
Last week a friend asked me to coffee. He works at an AI company valued at ten billion. First thing he said when he sat down: "Uncle J, why aren't you starting an AI company?"
I didn't answer. Not because I didn't know how. Something else was running in my head — the question had an assumption baked into it. The assumption was that AI companies are short on people who can write code.
I picked up the cup. Said nothing.
He told me it was a good window. Models exist. Money exists. Market exists. The only thing missing was "people with technical skill." He meant it.
I asked him: how many Agents are running at your company right now? Two, he said. One for customer service, one for pulling data. How long have they been running? Three months. Still tuning.
I stopped asking. Three months of tuning is not a technical problem. It means nobody figured out what state that Agent should be working in, and what state the system should land in once the Agent is done. Code doesn't fix that.
China has a million people who can write code. Fewer than ten thousand have seriously managed an organization. Fewer than a hundred have done both.
I've been on the edge of that hundred for a while. Six years at Longfor. Managed a few hundred people. Ran promotions, terminations, team restructurings. Grew a department from twelve to sixty, then shrank it back.
Now I manage 200+ Agents.
A year in, the feeling keeps getting stronger: this is the same job. Different leverage.
What my friend wanted wasn't a co-founder who could write code. He wanted someone who knew how to put the AI team's work in the right order — not who wrote the cleanest functions, but who knew which move comes first, which move comes second, and what state the system enters once the move is done.
We talked for two hours. At the end he asked: what do you actually do for these companies?
I said: I help them figure out where the next move for their Agents should land — so the road after that opens up instead of closing down.
He said: isn't that what a PM does?
I didn't answer. The question itself was the answer.
I Used to Do HR
Not the kind that fills out spreadsheets and sends offer letters. The kind that sits next to the CEO deciding whether a director is worth keeping.
Those years at Longfor, I saw what the best managers actually look like. They don't out-work anyone. They just see further than anyone else: if I put this person in this seat, three moves from now, what state does the team enter?
That sentence is how I run Agents now.
In 2026 I started building my own Agent system. The first month, I managed Agents the way you manage software. Error here, fix here. Prompt off, tweak prompt. Tool call failed, debug the tool call.
Three months in, my meta-warden had been reworked 23 times.
I thought my prompts weren't sharp enough. Then one day I opened the commit log and saw the pattern — every rework happened because meta-warden had done something it wasn't supposed to do. It went hands-on. Wrote code itself. Edited files itself.
It wasn't disobedience. I had never told it clearly: you are the orchestrator, not the executor. The orchestrator going hands-on is a violation.
That isn't a prompt problem. That's an undefined role.
When I ran a 500-person team, the biggest source of rework was never weak employees. It was blurry role boundaries.
Directors doing VP work. Managers doing director work. Everyone "covering" for everyone else. The covering compounds, the core decisions go unmade, and the execution layer ends up self-rescuing.
In an Agent system the problem is identical. The only thing that changed is the cast — meta-warden, meta-conductor, backend-engineer instead of humans. If you don't write down who manages whom, who goes hands-on and who doesn't, system entropy keeps climbing. Rework never stops.
Someone told me: managing AI is easier than managing humans, AI doesn't have moods. I said: easier by an order of magnitude. True.
But 95% of companies are managing AI the way you manage software.
Managing software — fix the bug, add the feature, ship the version. Managing an organization — who owns what, where decision rights live, which seat this role sits in, and what state the system enters three moves later.
Software management is tactics. Organization management is strategy. AI systems need the second one.
That's why these companies are all turning in blank papers. Their engineers are fine. They're fighting a strategic war with tactical thinking.
I Later Named This "State Leverage"
After more than a year building Agent systems, I finally figured out what all my worst rework decisions had in common.
The action itself was fine. But after that action, the system landed in a state that was harder to work with. I fixed this, that got more tangled. I added this feature, the next feature became harder to add. I shipped this Agent, the next three Agents had to route around it.
I thought I was moving forward. I was actually manufacturing friction.
I eventually gave this thing a name: state leverage. Because it's the same animal Naval talks about when he talks about leverage — just pointed in a different direction.
Naval describes four kinds of leverage — Labor, Capital, Code, and Media.
The way a person goes from "trading hours for money" to "making money while they sleep" is by trading labor up the stack — you write one line of code, the world copies it for free; you record one video, the world distributes it for free.
Naval is talking about wealth leverage. Leverage doesn't decide how hard you work today. It decides whether the work you did today gets multiplied automatically.
What I started feeling, after a year inside Agent systems, is that the AI era has a kind of leverage that isn't on Naval's list. I call it state leverage.
Its core isn't "amplification" — it's "handoff." After this step is done, will the world be friendlier to the next step, or harder?
Capital leverage multiplies your money. Code leverage multiplies your output. Media leverage multiplies your reach. State leverage multiplies the world that future-you walks into — smoother, or more clogged.
Most people do work by playing one game: how do I spend the least effort right now, how do I extract the most return from this single step. Computer science has a name for this. It's called the greedy algorithm.
Throwing the ribs straight in the freezer is greedy. Shipping an Agent without writing its identity card is greedy. Endlessly tweaking a prompt instead of taking the time to define a role boundary is greedy.
The ending of every greedy algorithm: a sequence of locally optimal moves that add up to a global disaster.
The opposite of greedy is dynamic programming. Behind it sits an old equation Richard Bellman wrote down in 1954, and the whole thing reduces to one sentence:
Total reward = immediate payoff + the latent value of the next state you're walking into.
Most people only compute the first term. How much did I just earn, how much effort did I just save, how many points did the answer quality go up after this prompt edit.
Nobody computes the second term — after this step is done, what state did my system just enter? Will that state make the next step easier, or harder?
State leverage = Naval's leverage + Bellman's dynamic programming.
One is about amplification. The other is about handoff. Put them together and you get the real compounding of the AI era.
A prompt engineer only computes the first term: is this answer good enough. An Agent engineer has to compute the second term: after this Agent finishes running, what state is the system in, and will the next Agent have an easier time picking up from there.
This isn't a technical difference. It's a difference in cognitive framework.
One person is building Agents with a greedy algorithm. Another is building Agents with dynamic programming. On the surface, the greedy one looks faster in the short run — tweak a prompt, see the effect immediately, ship the same day.
Six months later, the greedy system is a knot. Every new feature has to negotiate with historical debt before it can be added. The dynamic-programming system gets smoother the longer it runs. Faster the longer it runs. The state keeps improving as it goes.
I used to run teams the same way — I just didn't know it was called the Bellman equation. All I knew was: better to take three more months to hire than to hire the wrong person and spend a year cleaning up afterward.
That's exactly computing the second term: if this person joins, what state does the team enter?
Managing Agents now, same logic: if this Agent ships, what state does the system enter? After this step, will the next step be easier, or harder?
If it makes the next step harder, then even when this step is "done right," it's wrong.
Lever 1: Front-Loading — The Cut Made Furthest Upstream
I eventually realized state leverage breaks into three forces. The first is front-loading — actions taken at the upstream end of a system. The earlier you act, the more of the downstream you lock in.
NASA ran the math on this once. The design phase of a project consumes only 15% of the total budget. But that 15% locks in roughly 75% of the lifecycle cost.
The first time I saw that number, I wasn't thinking about rockets. I was thinking about the period in my HR career when I wrote job descriptions.
I spent a stretch handling mid-to-senior recruiting. The company was scaling. New roles every month.
For some JDs, I'd spend two or three days thinking carefully. What's the first decision this person makes after they walk in? Where does their authority end? Who do they collaborate with most, and what does that interface look like?
For other JDs, I'd bang them out in half a day. Responsibilities, requirements, salary, standard template, sent.
Later I ran the numbers. The roles I wrote in two or three days had near-zero attrition within 90 days. The ones I rushed in half a day — about a third turned over within three months. Re-hire required.
Three days writing the JD, or three months re-running the search? It's a math problem. Not a hard one.
The instinct, though, is to save the three days.
In the Agent system, this is what writing an identity card looks like. Writing meta-warden's identity card took me a day and a half.
Not writing a Prompt. Working out what the role is. What it owns. What it doesn't. When it's forbidden to step in and execute. When it must stop and wait for confirmation.
One line in particular I stared at for a long time after I wrote it. "The orchestrator does not step onto the field. If code or file contents appear in its output, that's a violation signal."
I tracked it afterward. That single line saved me about 40 reworks over the next six months. At an average of two hours per rework, that line was worth 80 hours. The identity card took 12 hours to write. ROI: 6.7x.
NASA says 15% of the budget locks in 75% of the cost. My own version: the identity card took about 8% of the system build time, and it determined roughly 70% of the eventual stability.
Different ratios. Same logic. A little extra time at the upstream end, and the system enters a low-friction state. Every step after that compounds inside the low-friction state — smoother, faster. Skip it, and you save a few hours up front. Then for the next six months, you pay that bill every month.
Someone said to me: of course it's worth it for you, you have a lot of Agents. I only have a few. Not worth the trouble.
How many do you have, I asked. Three, he said. Planning to scale to ten.
I said: don't write it now. Wait until you hit ten. Then tell me how it feels. He didn't answer.
Lever 2: Sequencing — 90% of Bosses Let Everyone Start at Once
Back when I managed 500 people, the worst pain wasn't anyone slacking off. It was that everyone was working hard, and the sequence was wrong. They were manufacturing waste for each other.
Sales chasing revenue. Marketing chasing leads. Product chasing delivery. HR chasing headcount. Every team's KPIs looked good. Total output didn't move.
Quarterly review was when it clicked. The deals sales signed, product couldn't ship. The leads marketing pulled, sales couldn't absorb. The people HR hired, half churned within three months because the business side hadn't actually prepared a seat for them.
Every link pulling hard. Every link pulling in a direction that created rework for the next link.
I started calling this organizational sequence collapse. Letting everyone start before doing the sequencing is like laying the floor before running the wiring. The floor goes down. Then you discover the wiring. So you tear the floor up. Then you lay it again.
Whose fault? Nobody's. Every individual KPI was met. The waste gets bucketed under "coordination loss." Nobody owns it.
When I moved into the AI era, I watched the exact same script play out. Word for word. Just swap "500 employees" for "500 prompts."
90% of people get a task and immediately open Cursor and ask the AI to write code. 90% of bosses see an AI tool and buy it. They buy it and they roll it out to everyone.
Nobody asks: is this a query, an execution, a planning task, or a decision? Nobody asks: in the existing capability stack, who already does this? Nobody asks: after this gets done, will the next step be smoother or more clogged?
Everyone just starts.
A trap I walked into myself. Saturday afternoon. I was drinking tea. The AI was running the work. I asked it to restructure a folder in my Obsidian vault. "Reorganize by topic. Make the structure cleaner." That's what I said. I didn't say anything about the links. I assumed it would "just know."
It went. Briskly. Renamed 200 files. Reorganized scattered notes into 8 thematic directories. I opened the first note. Glanced at it. The structure was indeed cleaner. I took a sip of tea. Reached for the next note.
The next note wouldn't open. The link was broken.
I went back to the index. 13,000 wikilinks across the vault. Most of them broken.
The tea stopped tasting like tea.
The first thing I did was git status. The screen was a wall of red. 200 renamed files. Every renamed file dragged a chain of files that referenced it down with it.
The 13,000 broken wikilinks weren't something the AI changed. They were a side effect of changing filenames. Rename a file, and every link pointing at it dies. Obsidian isn't an IDE. It doesn't auto-update references.
I spent two hours hand-chasing. Eventually I gave up and reverted from git log, one commit at a time. After the revert finished I sat in the chair and stared at a clean git status and finally understood something.
This wasn't the AI's fault. My sequence was wrong.
The right sequence: scan the dependency graph first — which files are linked, where they're linked from. Then design the new structure, mapping every link in advance. Then rename files in batch — with link updates folded into the same step. Finally, run a link integrity check. Zero broken links.
Four steps. None of them skippable. None of them reorderable.
What I lost that day wasn't two hours. It was my baseline trust in "just let the AI do it."
I have a name for this sequence now. Dispatch before Execute.
Task arrives. Step one isn't opening Cursor. It's judging the type, complexity, and capability requirement. Step two isn't writing a Prompt. It's Fetch — looking at the existing Agents, Skills, and tools to find who can do it. Step three isn't moving. It's Thinking — walking the plan through your head, predicting the rework points. Step four is finally Spawn — dispatch an Agent to execute.
Four steps. Five times faster than just starting.
You think the AI got better. It didn't. The sequence got right.
I now run 8 governance Agents and 100+ execution Agents in Meta HQ. The way I run them is the same way I ran a 500-person department.
The only difference: people will protest "why does your task go first." Agents won't. Agents do exactly what you sequence. Which makes it more dangerous. Sequence them wrong and the entire org silently manufactures waste. Not even a complaint to alert you.
Lever 3: Constraint — Judgment Is the Organization's Bottleneck
Goldratt spent a lifetime on the Theory of Constraints. The whole thing collapses to one sentence: the output of any system is determined by its narrowest segment. Not the average waterline. The lowest one.
I've watched too many companies do AI transformation. Buy ChatGPT for everyone. Mandate AI training for everyone. Cursor, Claude Code, Notion AI, Gemini — a whole rack of tools. Expense reports running ten grand a month. Six months in, output unchanged.
Why? Because the bottleneck isn't the tooling. It's the boss's judgment, single-threaded. The boss won't learn, won't use it, won't delegate authority. The people below can learn all they want. The system's throughput is locked at him — every plan needs his nod, every change needs his approval, every AI output needs his eyes.
He can review 10 plans a day. Buy 100 tools, the bottleneck is still 10. The other 90 tools' capacity gets burned waiting in line for the boss to look.
A client came to me last week. He'd bought Claude Opus. Two hundred dollars a month. He wanted my help accelerating a task — turn three years of company hiring records into a single spreadsheet.
I looked at it and asked: why are you doing this? My boss said to, he replied. I asked: what's it for after it's done? He said his boss didn't say. Probably just to glance at.
I couldn't hold it in. I said: you're spending $200 to accelerate a task that shouldn't exist. That's not productivity. That's accelerated waste.
The logic most people use to buy AI tools: make what I'm currently doing faster. The correct logic should be: stop me from doing the things I shouldn't be doing.
The first is flooring the gas pedal. The second is checking whether you're in the right lane.
I've also mapped my own bottleneck. Not the model — I'm already on Opus, there's nothing more expensive. Not the Prompts — 400+ Skills written, the craft is mature. Not the tools — Claude Code, Codex, Tony, Max, the whole stack is running.
It's my judgment. Whether this task is worth doing. Whether this Agent's design is sound. Whether the system's output has actual value. Which clients are worth signing and which aren't. Which direction is worth going All in.
The AI can't do these. Only I can.
I've also measured how many hours a day I can produce high-quality judgments. 9 to 11 in the morning, the best two-hour window. The judgments I make there hold up. The ones I make after 3 PM, I usually find wrong on review. The ones I make at night — I wake up the next day and have to overturn most of them.
My judgment has hours. My entire AI system's throughput is locked inside that two-hour window. Doesn't matter how many Agents I add. Doesn't matter how expensive the model is.
Once I knew this, I made three changes.
One: 9 to 11 every morning is reserved for judgment. No meetings. No messages. No code. Just judging.
Two: anything that doesn't require my judgment, dispatch to Agents. Reviewing drafts, editing docs, writing code, scraping data — there's no "is this worth doing" judgment in any of these. Only "is this done correctly" execution. Agents do them.
Three: filter "does this actually need my judgment" upstream. Every task entering my field goes through one screen — does this have to be my call? 70% of tasks get killed at this gate.
Together, these three moves tripled my judgment bandwidth. Not because I got faster. Because I stopped pulling in places that didn't need pulling.
If you're not sitting on the bottleneck, you don't actually need to be that busy. This is the hardest sentence for normal people to accept. Because being idle feels unsafe. Being idle gets you nagged by your boss. Being idle makes the KPI number look bad.
So people would rather thrash on a non-bottleneck than stop and ask: where is the actual bottleneck of this system.
The boss's bottleneck is judgment. The employee's bottleneck is the edge of their authority. The organization's bottleneck is the gate between those two lines. The gate stays shut, and the faster the bottom runs, the harder the top clogs.
The AI era amplifies this. Because AI made "running fast" almost free. And made "judging right" the rare thing.
I've Been the Prompt-final-v23 Guy Too
I'm telling you now that identity cards save effort, that Dispatch matters more than execution, that judgment is the real bottleneck. You think I knew this from the start?
There's a file on my laptop called Prompt-final-v23.md. It's still there. I can't bring myself to delete it. I keep it to remind myself how dumb I used to be.
Back then I was just getting serious about AI. I wrote an 800-word system prompt. Role definition. Output format. List of counter-examples. A "please don't..." checklist. Dense as a tax form. Every time I called the model, I'd think: this time it'll work. Because I'd added three more constraints.
Then the AI would output something. I'd look at it. Close, but off. Edit the prompt. Try again. Still off. Edit again.
I thought I was optimizing. I was actually doing tower-sweep. From the bottom up.
Every edit, I felt closer to the goal. But that "closer" was fake. The prompt had more words. The model didn't care. Every call, it started fresh. It didn't remember what I'd changed last time. It interpreted those 800 words its own way, every single time.
I wasn't accumulating. I was burning. A year in, I had nothing saved up. Every prompt was disposable. What worked today, I'd throw out tomorrow when the use case shifted. A whole year, v1 to v23. I thought I was building a house. I was stacking sand.
The hard part isn't even that. The hard part is — back then, I really enjoyed judging other people for not knowing how to use AI.
I'd see someone copy-pasting by hand and feel a little surge of "this guy hasn't woken up." I'd see someone saying AI was useless and roll my eyes inside, thinking they hadn't tried hard enough.
That smugness lasted a long time. Until I figured out what an Agent was. What state was. What Dispatch-first meant. I looked back at that year, and I was the guy who hadn't woken up. I'd written v23 of a prompt with no state, no tool calls, no persistent memory.
I thought I was using AI. I was feeding a chat box that lost its memory every turn.
What I sounded like back then mocking other people for not getting AI is exactly what I sound like to people now.
That sentence still stings when I say it out loud. Not because pride got punctured. Because at the time I genuinely had no idea what I didn't know. Not "I knew I was wrong." It was "I had no clue where I was wrong." That's the part that hurts.
I keep that file for that reason. Prompt-final-v23.md is my mirror. Every time I start to feel "I get it now" — I open it up.
I Let Agents Replace Me, So I Can Do What AI Can't
Meta_J is my back office. 200+ Agents. 10,000+ files. Over a year of iteration. It's not a product. It's not for sale. It has no UI. It's my workbench.
Once the back office worked, I started building the other side — the front office.
The front office is 20 Personas. 20 accounts, spread across 18 cities. No shared devices. No shared SIMs. No shared IPs. Each account has gender, age, sleep schedule, personality, voice, platform mix.
These aren't virtual humans. They're 20 real-person scripts — tomorrow you can hand one to a specific intern, who puts it on like a uniform and starts working.
I wrote a few hard rules into this design. Rule one: AI doesn't impersonate humans. AI assists humans.
The whole content industry is heading the wrong way right now. Every company is trying to make AI pass as a real person. The more human-looking, the better. Ideally fool the platform's anti-fraud systems.
I went the other way. The real human is the lead. AI is the copilot. AI drafts, the human edits and posts. AI proposes topics, the human approves. AI reads the data, the human decides what's next.
Because the platforms will eventually figure out which posts are AI-pretending-to-be-human. They'll never figure out which posts are humans-with-AI-copilots.
Rule two: POC runs on a real human first. AI watches from the side.
The first of the 20 to go live wasn't any virtual design doc. It was Persona 1. I made myself wear it.
Not because I was short on people. Because I needed to know — what does it actually feel like, as a real human, to do this work with AI in the copilot seat? Where is AI actually helping? Where is AI just adding noise? Where am I assuming AI is helping when it's actually making me dumber?
You can't see this stuff staring at a screen. You only know by being the human in the seat.
My read after doing it: The first person to be Agent-ified in the AI era isn't anyone else. It's you.
If you don't put yourself in the seat — the human running with AI as copilot — you'll never know whether the Agent system you're designing for other people is actually helping them, or replacing them. Those two things are an era apart.
Back office: Agents do the work for me. Front office: a real human does what AI can't. The line in the middle is judgment.
Judgment is the scarce resource. Execution isn't. Execution can be handed off. Judgment can't. Not because AI isn't smart enough. Because judgment requires you to know what this thing means to you — and only you know that.
When you stop personally writing every word and editing every line of code, you finally have time to think about the thing that's actually worth money. That thing is judgment.
And when you don't personally sit in the seat as the human-with-an-AI-copilot, you'll never know how judgment is supposed to land. Both pieces. Neither one optional.
This AI Wave Will Pull Two Kinds of Companies Out for Real
Type one: companies that genuinely manage Agents like coworkers. Type two: companies that genuinely design organizations like systems.
Doesn't matter if you're a model company, an AI app company, a traditional company doing AI transformation, or three founders in a garage. The winners are these two types.
Why? Because what AI changes isn't "tool efficiency." It changes the unit of collaboration.
A team used to mean N people plus process plus KPIs. A team now means N people plus M Agents plus process plus KPIs plus Agent governance plus permission boundaries plus accountability ownership.
Those last five things — none of them are engineering problems. All of them are organizational problems.
Agent governance: who is allowed to spawn Agents? Who reviews Agent output? When an Agent screws up, who eats it?
Permission boundaries: which data can the Agent read? Which tables can it write? Which external APIs can it call? What happens when it crosses a line?
Accountability ownership: an Agent miswrites a contract amount on a customer record. Whose fault is it? The operator on duty? The person who designed the Agent? The exec who approved it for production?
Not one of these three is in an engineer's training. Every one of them decides whether your AI system survives in real business.
Here's a take that's going to upset some people. What this AI wave is most short of isn't engineers. It's people who understand both organizations and Agents.
People who can write code: a million in China. People who've actually run organizations: under ten thousand. People who've done both: under a hundred.
Those hundred people decide which companies, over the next decade, go from "AI application" to "AI native." Which ones go from "AI transformation" to "AI rebirth." And which ones just drew an Agent on a slide deck and raised a round.
Manus had its moment. Coze had its moment. Dify had its moment. Their demo videos all looked great.
Why does nobody talk about them six months later? Because none of them solved the organizational layer. They solved "can I get AI to do this thing?" They didn't solve "after I let AI do this thing, who owns the responsibility, the permissions, the audit trail, the rollback?"
The first is a technical problem. The second is an organizational problem. Technical problems make demos look good. Organizational problems decide whether you can actually ship to production.
I did HR for 15 years. I know when to hire someone and when not to. I know how much five people can get done, and why ten people get less done. I know the boss's decision bandwidth is the biggest hidden cost outside the KPI sheet. I know if a job description is fuzzy, the person in that seat will quit within three months.
Those used to be called "management common sense." Now they're called "scarce skills for the AI era."
Because Agents aren't tools. They're coworkers. Coworkers who only listen to code, not to ethics. Coworkers who never clock out but have to be designed. Coworkers who won't protest but will silently produce garbage. Coworkers with no KPI who still need constraints.
Whoever learns to manage that kind of coworker first wins the next decade. The winners aren't the ones who can write code. The winners are the ones who know what permissions a "coworker" should be granted, what KPIs they should be assigned, what accountability boundaries they should be designed with.
Closing
Prompt is performance. Agent is commitment. Grinding harder is greedy. Building systems is dynamic programming.
The blade is the same blade. The prompts are the same prompts. The models are the same models. The Agent frameworks are the same frameworks. The only thing that changed is where you point them.
The way I judge whether something is worth doing has changed too. Not "can this make money." It's "after I do this, what state will I be in? And does that state make my next step, my next ten steps, my next hundred steps more open?"
The Bellman equation went from a math formula to a way of life.
When did the shift happen? It was sitting at my screen, watching meta-warden hit its 23rd rework. Scrolling through the commit log from start to finish. Realizing every collapse happened in the same place — role boundaries weren't written clearly enough, and meta-warden had stepped onto the field itself. That moment.
Not when I read the Bellman equation. After I'd hit enough walls. Then I went back to the equation, and only then did I really understand it.
I now spend 90% of my time orchestrating Agents and 10% on one question — what does an AI-era organization actually look like.
I'm thinking about it alone. It's slow.
If you're a founder redesigning your team, a CHRO running an AI transformation, an engineer leading a swarm of Agents, or someone like me building a workbench around "doing things the Agent way" — come talk.
Not selling consulting. Not running a bootcamp. Between fellow travelers, it's a coffee.
Your next move — greedy, or dynamic programming?