A pile of agents is not a team

There is a stage many owners reach a few months into using AI agents. The first one worked, so they built a second, then a third, then a few more, each handling some useful job. And somewhere around the fifth, the whole thing stopped feeling like progress and started feeling like a mess. Agents overlapping, doing slightly contradictory things, with no clear sense of which one owns what or who to blame when something breaks. The capability went up. The order went down.

This is a familiar problem in an unfamiliar costume. Anyone who has managed people knows that a group of capable individuals is not a team until it has roles, ownership and a way of handling exceptions. Rohit Krishnan, who writes thoughtfully about how AI agents behave, makes exactly this point about agents: "a pile of agents is not a company for the same reason a pile of smart people is not a company." A firm of agents, in his words, needs "roles, ownership, shared state, ledgers, escalation paths, standards, prices, and approvals." Capability was never the missing piece. Structure is.

The sprawl problem

Sprawl creeps up on you because each individual step is sensible. Every agent you add solves a real problem, so adding it feels like a clear win. What you do not see until later is the cost of the collection: agents that do not know about each other, that act on the same information in different ways, that leave you unable to say with confidence what your own setup actually does.

The symptoms are recognisable. Two agents produce slightly different versions of the same thing. A job falls through a gap because each agent assumed the other had it. Something goes wrong and you cannot tell which agent caused it, so you cannot fix it cleanly. None of this is a failure of the individual agents. It is the absence of the organising layer that turns a collection into a team, and it arrives exactly when the collection gets big enough to be worth having.

Why roles and ownership matter

The fix is the same one that turns a group of people into a functioning team, and it starts with roles. Each agent needs a clearly defined lane: what it is responsible for, and just as importantly, what it is not. When every agent's job is sharply bounded, the overlaps and gaps that cause the chaos disappear, because there is no ambiguity about who does what.

Ownership matters for a reason specific to how agents behave. Krishnan observes that agents are "role-absorbed," following their instructions literally and completely, without the human instinct to notice when something has clearly gone off the rails. A person given a slightly wrong instruction usually senses it and asks. An agent just does it, confidently, to the letter. That is precisely why each agent needs a human owner: someone accountable for what it does, who checks it is still doing the right thing and steps in when the literal-minded machine follows a bad instruction off a cliff.

An agent does exactly what you told it, which is wonderful until what you told it was slightly wrong.

Giving each agent a lane and an owner

In practice, organising your agents is less work than it sounds, and you can do it on a single page. For each agent, write three things: what it is responsible for, what it is explicitly not responsible for, and who owns it. That is the whole structure. The discipline is in being specific, because vague lanes are how the overlaps creep back in.

The not-responsible-for line does more work than people expect. It is the boundary that stops two agents colliding, and it forces you to decide, deliberately, where one agent's job ends and another's begins. The owner line ensures every agent has a named human who is answerable for it. A firm with five agents and a one-page map of lanes and owners has a team. A firm with five agents and no map has a pile.

Escalation and approval rules

The last piece is what happens at the edges, when an agent meets something outside its lane or above its pay grade. People handle this instinctively: they escalate, they ask, they flag the unusual case to someone senior. Agents do not, unless you build the path. So decide, for each agent, what it must not do without a human saying yes, and where it should stop and ask rather than press on.

These are your approvals and escalation paths, and they are where you keep control of the consequential moments. Anything that touches money, customers or records should sit behind an approval. Anything genuinely unusual should trigger a stop-and-ask rather than a confident guess. With those rules in place, your agents can run freely on the routine and reliably hand the exceptional back to a human, which is exactly the balance a small firm needs.

The honest limits

Keep the whole thing small enough to supervise. The point of organising your agents is to stay in control of them, and that control has a ceiling set by what one owner can actually hold in their head. A neatly structured team of agents you cannot oversee is still a risk, just a tidier-looking one. If you find yourself adding agents faster than you can map and own them, the answer is fewer agents, not a bigger diagram.

There is also a temptation to over-engineer the structure itself, to build an elaborate org chart for what is, in a small firm, a handful of routines. Resist it. The structure should be the lightest thing that removes the overlaps, gaps and unowned actions. A page is usually enough. The goal is order, not bureaucracy, and a small firm gains nothing by recreating a corporate hierarchy for five pieces of software.

The deeper point is that managing agents draws on skills you already have. If you have ever run a small team, you know that the work is mostly clear roles, clear ownership, and a sensible way of handling the unusual case. None of that changes because the workers are software. What changes is that agents will not improvise the missing structure the way people quietly do, so you have to supply it on purpose. Owners who treat agent management as a brand-new discipline tend to overcomplicate it. Owners who treat it as ordinary management, applied to unusually literal staff, tend to get it about right.

What to do next

List the agents and automations you currently run. Beside each, write what it owns, what it does not, and who is accountable for it. Then add, for each, the one or two actions it must never take without a human yes. If that exercise reveals overlaps, gaps or agents nobody owns, you have found your mess before it found you. Fix those, keep the map current, and add new agents only when you can give them a clear lane and an owner.

Organising AI work so it stays under control as it grows, with clear lanes, owners and escalation, is exactly the kind of structure the AI Advisory for Teams work puts in place. If your agents have started to sprawl, book a business call and we will turn the pile into a team.

Sources and further reading

• Rohit Krishnan, "Homo Agenticus," Strange Loop Canon, 2025. The argument the title borrows: a pile of agents is not a company without roles, ownership and escalation.
• Rohit Krishnan, "Seeing like an agent," Strange Loop Canon, 2025. Why agents follow instructions so literally, and what that means for supervising them.