A founder I talk with — someone running a company where most of the execution is done by agents — told me the question he gets asked first, almost every time, is some version of this:
“How many agents should I have, and what should each one do?”
It’s a reasonable question. It’s also, underneath, a question about boundaries: where one ends, where the next begins, what belongs to each.
And it’s the same question companies have always asked about people. Which is the first clue that something is off, because the answer we developed for people is the one thing you shouldn’t copy.
You can’t draw a boundary around a unit nobody has defined
Start with what’s actually running. Inside a single account you might have several different agent types — one model writing code, another doing research, another handling operations — each running many sessions at once. Some finish in a minute. Some own a piece of work for weeks.
Is that one agent? Four? Forty?
Nobody has settled this, and it matters more than it sounds. Because the moment you decide an agent is a discrete worker, you start doing what we have always done with discrete workers.
The boundary most people draw: function
So the roster gets written. A marketing agent. A sales agent. A support agent. Each gets its own scoped memory — marketing data for the marketing one, tickets for support — and they pass work across the lines between them.
It feels organized. It looks like a company.
It is also the org chart, rebuilt in software. And here’s the part worth sitting with: you haven’t removed the cost of all that process and coordination. You’ve transferred it from people to agents. The same gates, the same hand-offs, the same waiting — now paid in tokens, orchestration code and latency instead of meetings and status updates. Cheaper per unit, certainly. Same shape.
Part 1 landed on two things as the real bottleneck: the cost of coordination, and knowledge trapped inside individuals where nothing else could reach it. Neither is an accident of any particular company. They are what a structure built out of fixed functions produces. Functions require hand-offs, and hand-offs are coordination. Functions scope knowledge to a role, and scoped knowledge is fragmented knowledge.
Why we organized by function in the first place
Which raises the question worth asking before you copy it: why did we ever organize this way? The answer isn’t tradition. It’s economics — human economics specifically.
A person takes years to become genuinely good at a domain. Learning is slow, it happens at one speed, and it doesn’t transfer cheaply. Moving someone between domains is expensive: they pay a ramp, they carry a reload cost every time they switch, and for months they aren’t much use. So you park a person in a domain and let that investment amortize over a career. Function is a rational answer to how humans learn. Given the constraints, it was the right design.
Now check those constraints against an agent.
An agent doesn’t spend three years becoming competent at billing; it reads what’s there. Moving it from billing to onboarding costs approximately nothing — no ramp, no reload, no career to manage. Its learning is fast and its context switching is close to free. The two costs that made specialization worth paying for aren’t there.
Agents do have a real limit, and it’s worth being precise: the context window. But notice it’s a different kind of limit. It bounds how much can be held at once for a single task. It doesn’t bound what can be learned over a lifetime, because there is no lifetime — every session starts fresh. You solve a context-window limit with retrieval and good information architecture. You do not solve it by permanently assigning an agent to a department.
So when you scope an agent by function, you’re importing a constraint it doesn’t have in order to solve a problem it doesn’t have. An agent org chart doesn’t fragment context in some abstract way — it manufactures, in software, the exact two things Part 1 named as the bottleneck. Every boundary is a hand-off. Every scoped memory is knowledge trapped where nothing else can reach it.
You’d be rebuilding the bottleneck at machine speed, and paying to maintain it.
The pod, not the department
There’s a better image, and it comes from how modern infrastructure already schedules work.
In a Kubernetes cluster the unit isn’t the container. It’s the pod — a small group of containers brought up together because they need to work on the same thing. They’re deliberately heterogeneous: they do different jobs and complement each other. They share context by design, because that’s the point of being in the same pod rather than scattered across the cluster. And the pod is temporary. It exists for the workload, then goes away, and the next workload gets a pod composed differently.
Nothing about that is organized by function. There is no marketing node.
That’s the shape worth borrowing: start with the problem, assemble the capability around it, finish, disband, recombine differently next time. First the problem, then the team. I see it in the teams I work with well before anyone writes it down as policy — the project that got done by one person and a few agents instead of a staffed cross-functional group, the team that formed around a customer problem and quietly dissolved afterward without a reorganization.
And the interesting part is that humans and agents belong in the same pod. A question comes up; the people and the agents it needs come together around it, working from the whole context rather than a slice scoped to their function. They solve it. Then the composition changes, because the next question needs something different. One pool of capability containing both kinds — not a human org over here and an agent roster over there.
What the person in the pod is actually for
Which raises the obvious objection: an agent absorbs the whole context in seconds and a person cannot, so “the pod works from the whole context” is true for one half of it and impossible for the other.
Part of that is a misreading — the pod holds the context, not each member. In a cluster, containers share a volume; that doesn’t mean each one reads every file. Nobody expects the person to out-read the agent.
But the better answer is that reading was never the job. Two things are, and both scale.
Authorization. When an agent acts on something real — signs into an account, touches a system, spends money — somebody has to be accountable for that action. This is where the tooling has actually landed: credentials get delivered just-in-time, the agent never sees the secret, and a person approves the moment of access. Notice what that is and isn’t. The human isn’t checking the agent’s work. They’re answering a narrower question — may this act happen here — and that question takes seconds, not a review cycle. It’s the highest-value human-in-the-loop moment precisely because it’s the one that can’t be delegated: accountability doesn’t transfer to something that can’t be held responsible.
Outside context, and the standard. The agent’s world is everything written down. The human’s world is the part that isn’t — what the client said and then didn’t say, the hesitation in the room, the thing that only surfaces on the third call. The person brings that in; the agent turns it into something the organization keeps.
And then the piece that decides whether any of this scales: the human defines and improves the criteria by which work gets judged — not the judgment of each output. What counts as done. What we’d never ship. Which failure matters. Set that well and the evaluation runs without you, and gets sharper each time you correct it. Try to personally assess every result and you’ve made yourself the review gate — the exact bottleneck Part 1 was about, wearing a new costume.
That’s the line I’d hold. The human is not in the pod to out-work the agents, and not to approve their homework. They’re there to be accountable for what the pod is allowed to do, to supply the context no system has, and to keep sharpening the definition of good.
Two honest limits. This holds where failure is felt; where it’s silent or delayed — security, compliance — “the client seems happy” is not evidence, and you need real expertise in the loop. And writing good criteria is its own competence, not the same skill as reviewing work, and not what most organizations have spent the last decade promoting people for.
When the pod is the unit
That’s the shift worth naming, and it’s larger than anything about agents. The unit of organization stops being the team and becomes the pod.
For most of the last century the unit was the standing team — a group defined by function that persisted whether or not there was a problem in front of it. Almost everything we call coordination exists to serve that arrangement: status meetings, alignment sessions, reporting lines, the quarterly ritual of demonstrating the group should continue to exist. A permanent structure needs constant maintenance just to stay pointed at something.
Make the pod the unit and most of that machinery has nothing left to hold onto. A pod exists because a problem exists. It has no headcount to justify, no lane to defend, no reason to persist past the thing it was assembled for. Which leaves exactly one thing worth coordinating on: whether the problem got solved.
When the unit is temporary, results are the only durable measure of it. You don’t have to install that, or launch a program to encourage it. It falls out of the structure.
So the question was never how many agents you need, or which function each one belongs to. It’s what the problem is, who — human or otherwise — should be in the room for it, and whether the thing actually got solved.