Agent leverage

For most of the history of companies, the question of how much a team could get done had a simple answer. It depended on who you hired, and how many of them. Headcount was capacity. If you wanted to do twice as much, you eventually needed something like twice as many people.

That relationship is coming apart. A small team can now direct far more work than its members could ever do by hand, because a growing share of the work is being done by AI agents. Some teams are using this to do remarkable things with a fraction of the people. Many more have given everyone a chatbot and are waiting for productivity to go up.

Both groups usually have access to the same models. What separates them is the system they build around those models. I’ve found it useful to give that difference a name, and a number.

A simple ratio

Agent leverage is the ratio of useful work produced by AI agents to useful work produced by people. At 1×, agents and people contribute the same amount. At 5×, agents contribute five units of production for every one contributed by a person.

Try it on a ten-person team, where each person contributes ten units of useful work a week.

The word doing the most work in that definition is useful. Useful means accepted, valuable output. It does not mean tokens, runtime, drafts or the number of agents you have running. An agent that writes a hundred proposals nobody reads hasn’t produced a hundred units of anything. Code that takes an engineer an afternoon to untangle may have produced less than nothing. An honest measure of leverage also counts the human time spent reviewing, correcting and maintaining the system.

Measured that way, agent leverage is a property of a team, not of a tool. Two teams can use the same model and end up an order of magnitude apart.

Every company is already a multi-agent system

It helps to look at a company the way an engineer would look at any system that gets work done.

The implication is uncomfortable for anyone who thinks about companies mainly as collections of talented people. A company’s capacity now depends not just on the people it hires, but on the system it builds around them. Two teams of equally talented people can end up with radically different output because one of them designed a better system.

Leadership becomes partly a system-design job

A leader’s job used to be mostly about people: hire good ones, give them clear responsibilities, help them do their best work, manage performance. All of that still matters. It just isn’t the whole job anymore.

Leaders now also have to design how people and agents work together. That means deciding what agents own, what information and tools they need, how work moves between them, how quality gets checked, and when a person steps in.

Don’t just give everyone an AI assistant. Rethink how the work should happen.

Start with the outcome you want rather than assuming your existing jobs and processes are the right structure. Most org charts are a record of how work was once divided among people. There is no particular reason to expect that division to be the right one when a large share of the work is done by something else.

People are bottlenecks, and some of them should be

More agent output does not automatically mean more company output. Suppose an agent can produce fifty code changes a day, and the engineer responsible for them can carefully review five. Making the agent twice as fast doesn’t double what ships. It makes the queue longer.

The tempting lesson is to remove the people. That’s the wrong one. The goal isn’t to eliminate every human checkpoint; it’s to tell valuable judgment apart from unnecessary friction.

A person approving every routine support reply may slow the whole system down without making it much better. A person setting product direction, or signing off on a commitment that’s expensive to reverse, may prevent an enormous amount of wasted work. Put people where their involvement most improves the overall outcome, not everywhere an agent could make a mistake. Everywhere else, use clear boundaries, automated checks, sampling and exception handling.

You can watch the same dynamic play out across an entire process. Here is roughly how the work of building software has been shifting.

The people at the bottlenecks need different skills

If people are going to sit at the bottlenecks, it matters a great deal who they are and what they’re good at. Being excellent at doing the work yourself is not the same as being excellent at directing and evaluating work done by agents.

The skills that matter most are different: defining the problem precisely; recognizing quality quickly; spotting subtle errors that look plausible; making tradeoffs under uncertainty; and translating judgment into instructions and tests the system can reuse, so the same call doesn’t have to be made by hand a thousand times.

An exceptional human decision can make a large amount of agent execution valuable. A poor one can send all of it in the wrong direction.

That changes how we should think about performance. We should evaluate people partly by how much they improve the whole system, not only by their direct output, and certainly not by how many agents they happen to be running.

The system is never finished

The right division of labor between people and agents isn’t fixed. It shifts every time models get better at reasoning, become more reliable, remember more, use more tools, or get faster and cheaper. A human check that is necessary today may be unnecessary in six months. A task that wasn’t worth automating may suddenly be. A workflow that needed several handoffs may become a single agent’s job.

So the second leadership job is continuous redesign. Build a regular process to observe where work waits, test new capabilities, change the workflow and measure the result. Reallocate responsibilities, including replacing human execution where it makes sense, instead of preserving the old arrangement by default. Treat the organization as something you keep improving, not a structure you automate once.

Use agents to make your agents better

Most teams spend all of their agent capacity on today’s work. The teams that pull ahead spend some of it improving how tomorrow’s work gets done. Agents can analyze failures, find the places where people keep stepping in, build evaluations, test alternatives, and improve their own instructions and integrations.

This loop doesn’t run itself. An agent generating proposals for improvement is not the same as the system actually improving. It takes independent checks, measured results, and someone who owns the outcome. An agent should never be the one that gets to redefine the quality bar and then declare that it cleared it.

Why this is a competitive question

Differences in how companies design their human and AI systems can create large differences in output between teams that are otherwise equally talented. Take two teams, each with people producing 100 comparable units of work.

That is already a big difference. The bigger one is how quickly each company gets better. A competitor that uses agents to improve its own workflows can keep pulling ahead while another company is still rolling out basic tools.

Play with the rates and something becomes clear. Even when the company behind improves faster in percentage terms, a head start in agent leverage compounds, and the absolute gap keeps widening for years. Closing it requires a much faster rate of improvement than most companies achieve.

So the urgency has little to do with chasing every model release. What matters is getting good at turning whatever capabilities exist into better execution, and building that learning process before your competitors do.

Where to start

None of this requires a grand reorganization on day one. It requires picking something real and learning from it.

1. Pick one important, recurring workflow. Something your company does every week that matters.
2. Map where it waits for people, and why. Every pause is either judgment worth keeping or friction worth removing.
3. Establish a baseline. Quality, human effort, turnaround time and cost, before you change anything.
4. Change one dependency and test it in a limited scope. Replace a handoff, add an eval, let an agent own a step end to end.
5. Compare the results, then do it again. Keep what improved the outcome. Undo what only looked like progress.

Count accepted, useful work, not tokens, runtime, drafts or agent headcount. And include the human time spent reviewing, correcting and maintaining the system, because that time is part of the cost.