Three Humans. Twenty Agents. Eight Hours Each Per Day. The Management Wall Is Real.

On August 5, Jason Lemkin published the numbers from running SaaStr on AI agents, and they are worth sitting with.

SaaStr is an eight-figure B2B business with real customers and real invoices. It runs on three humans and 21+ AI agents. A year ago, running three agents took Lemkin and his colleague Amelia about 30 minutes a day between them. This week, managing 20+ agents took eight hours a day each. His word for it: they hit a wall.

The Konur Consulting take: A lot of SaaS operators are assuming that agents scale output without scaling the work of managing them. Lemkin's numbers say otherwise. The management cost curve does not stay flat; it bends sharply somewhere between five and twenty agents. You can plan for that bend or you can find it the way SaaStr did.

What the 30-minutes-to-8-hours curve tells you

It is tempting to file this as an edge case. SaaStr is an unusual company, a media and events business running itself as a live AI experiment, so the lessons might not travel.

I think they do.

The overhead Lemkin ran into comes from what agents are, not from how SaaStr configured them. Agents are not static tools. They make unexpected decisions, they run into situations nobody scoped, and their output needs human review before an error turns into a downstream consequence. They also interact with each other, which produces behavior nobody designed.

Three agents is fine. The interactions are few, the error surface is small, and the oversight is mostly intuitive.

At 20+, it compounds. Agent A's output feeds Agent B's input, and Agent B's error propagates into Agent C's action. Now the human in the loop has to hold not just what each agent does but how the whole network behaves together. That is a different kind of oversight, and it costs more time as the network grows, not less.

Which is why I read the curve as a general result rather than a quirk of one company's setup. Unstructured agent scaling looks like this everywhere.

Why most SaaS operators are building toward this wall

The usual story about agents is additive. Start with one, prove the value, add more. Underneath it sits an assumption that each new agent adds capability without adding a proportional amount of management, that the curve is sublinear.

Lemkin's data says it is superlinear. Every agent you add brings its own management requirement plus more complexity to the network.

Most teams adding agents are optimizing for the addition. What does this one do, how much headcount does it save, how much output does it add. Very few are designing the governance that keeps the resulting overhead from pooling in founder or executive time.

Some signs you are building toward the wall:

Agent responsibilities live in conversation rather than in written policy that both the agents and the people managing them can point to. When something breaks, nobody can say what the agent was supposed to do.

Human review of agent output falls to whoever happens to be free, with no defined role and no cadence. Oversight happens after problems, not before them.

Agents were added one at a time to solve whatever was urgent, with no explicit interfaces between them. The architecture evolved instead of getting designed.

If that describes your deployment, you have a complexity problem that simply has not surfaced yet.

What the governance infrastructure looks like

The teams that scale agents without hitting the wall put three things in place before agent number ten.

A written agent policy for each agent role. Not a prompt, a policy. Write down what the agent is authorized to do, which decisions it makes on its own, what forces a human review before it acts, and where it escalates when it hits something outside its scope. That document is your baseline when something goes wrong, and it is how a new team member learns what the agent does without someone explaining it verbally.

A structured oversight cadence. Reviewing output only when something breaks is reactive. Teams that scale well schedule the review, daily or weekly depending on how often the agent decides things, and sample outputs proactively. That is how you catch drift before it compounds through the network.

A network design that limits interdependency. Overhead grows fastest when agents are tightly coupled, when A's output feeds B's action with no human checkpoint in between. Put checkpoints at the boundaries, at least until each agent has proven itself, and both the error propagation and the oversight stay contained.

None of this needs new technology. It needs decisions made before the complexity arrives.

What to do Monday

Map your agent deployment as a network diagram rather than a list. For each agent, write down what it is authorized to do, what triggers human review, and which other agents consume its output. If you cannot finish the diagram because the answers are not written anywhere, that gap is the work to do before you add the next agent.

Then set a management overhead budget. Decide explicitly how many hours a week your team can spend on agent oversight without the rest of the job suffering. That number is your ceiling. Past it, adding agents means either adding oversight capacity or improving the governance so each agent costs less to watch.

FAQ

Is the 30-minutes-to-8-hours ratio specific to SaaStr's setup?

The absolute numbers are. The shape of the curve is not. Overhead grows superlinearly with agent count in any organization scaling agents without governance, though where the bend falls depends on how complex the agents are, how tightly coupled they are, and how reliable each one is on its own.

What is the right number of agents to have before building governance infrastructure?

Before the third one. Governance is far easier to build while the network is small, and every agent you add before the policy, the cadence, and the network design exist raises the retrofit cost. Lemkin hit the wall at 20. Teams that build governance at 3 do not.

Does this mean AI agents are not worth deploying at scale?

They are worth it. They just need organizational infrastructure, the same way a distributed engineering team does. The management overhead is real, and designing for it is what separates the companies that compound on AI from the ones that stall.

Thirty minutes became eight hours with all 20 agents working exactly as intended, generating output that needed human judgment to govern. That is a good problem. It is also a predictable one, which means you can design for it before it arrives.

Konur Consulting helps SaaS operators build the agent governance infrastructure that prevents the management wall, from written agent policies to oversight cadence design to network architecture. Reach out at info@konurconsulting.com.

---

Source - SaaStr agent management data: Jason Lemkin, "The Agents, Episode 12," SaaStr, August 5, 2026. Three humans, 21+ AI agents; 30 minutes/day (3 agents, one year ago) to 8 hours/day each (20+ agents, current). saastr.com