Ask five people building with agents right now what agent orchestration means and you'll get five different answers. To one person it's LangGraph or CrewAI routing a task between models. To another it's a 'manager' agent handing work to specialists. To someone else it's a governance layer that barely involves agents at all.
A r/AI_Agents thread put a name to the frustration:
Am I the only one annoyed that 'orchestration' now means literally everything in AI?
Its argument: vendors use the word for at least three different layers, agent coordination, workflow routing, and governance, and 27 comments in, nobody had agreed on where one ends and the next begins.
The confusion isn't really about semantics, though. 'Orchestration' is being asked to describe two genuinely different jobs, and most of what gets marketed under that name only does one of them.
Job one is routing. Job two is being accountable.
Job one is technical: given a task, decide which model or tool handles which step, pass context along, retry on failure. This is what most orchestration frameworks, LangGraph, CrewAI, custom pipelines, actually do, and it's a reasonably solved problem.
Job two is a management problem, not a routing problem: who owns whether a goal actually moves, which agents exist and why, and what happens when one of them isn't earning its keep. Almost nothing marketed as 'orchestration' does this job. A popular thread on the same subreddit put the gap bluntly, arguing that a lot of multi-agent stacks add manager and reviewer roles that never get checked against anything real, an org chart with no accountability trail behind it. Whatever you make of that critique, it's pointing at the same hole: a router isn't a management layer, and calling it one doesn't make it one.
Even the more rigorous industry framing stops short of it. One enterprise workload-automation vendor's inner-loop/outer-loop model splits agent work into an execution layer (reasoning, tool calls) and a governance layer (state, retries, approvals), and that's as far as it goes: an execution layer and a process-governance layer, never one that asks who owns the goal.
The actual bottleneck isn't routing, it's supervision
That gap shows up as a very concrete, practical problem once teams scale past one agent. A r/AI_Agents thread on exactly this found that running a single coding agent is manageable, but supervising several running at once quickly becomes the real bottleneck, not the routing between them, the sheer load of catching what any one of them is doing wrong. One person put it more plainly while asking around for 'orchestration / chief of staff' tools to keep their agents and projects organised: what they were actually looking for wasn't a router, it was something to hold the coordination job a person was stuck doing by hand.
That's job two's problem to solve. A layer that only routes messages between models doesn't touch it. What actually helps is something that takes the supervision load off a person, not just the handoff logic off a model.
What agent orchestration means at Tability
This is what Tability's Agent Manager is built to do. There's no fixed roster of agents waiting to be assigned. You start with one goal, a metric, a baseline, a deadline, the same shape as a key result in an OKR framework, not a to-do item. An Agent Manager takes ownership of that goal, breaks it into a plan, and only then works out which specialists the plan actually needs. Tability calls the resulting unit an Agency: one manager plus whatever team its own plan called for, currently capped at six total while the system learns where coordination starts to break down with a bigger crew.
'Tability acts as the business context and orchestration layer,' as the team put it describing their own self-hiring agent teams setup, and that's the distinction that matters here. It's not deciding which model handles which step. It's the layer that holds the goal, the plan, and the record of whether anything actually moved, which is exactly the job the routing frameworks were never built to do.
It's also the same operating discipline StratOps already applies to human teams, an owner, a cadence, a visible record of progress against a real number, just extended to cover agents recruited for a goal instead of hired for a role.
People are already building job two by hand
This isn't a hypothetical need. A r/AI_Agents thread asking if anyone had tried a 'manager agent assigning work to specialist agents' pattern got dozens of replies from people already doing exactly that, with mixed results. One practitioner described feeding an agent a spec, having it break the work into modules, then generating and running separate coding, testing, and review agents for each one, cutting a project that had taken six 40-hour weeks down to about ten hours of supervised work. Others cautioned that the same pattern can just as easily produce an 'absurd architecture' full of agents doing what one well-tooled agent, or a plain deterministic script, could have done faster and cheaper.
Both things are true, which is the point. The manager-plus-specialists pattern is real and it works, but whether a given instance of it is worth the overhead depends entirely on whether it's grounded in an actual goal or assembled because it seemed like the kind of setup a 'real' system should have. That's the judgment call Agent Manager makes structurally, by deriving the team from the plan, rather than leaving it to whoever's hand-assembling threads that week.
| Dimension | Ad hoc multi-agent setup | Tability Agent Manager |
|---|---|---|
| How the team gets decided | Assembled by hand, thread by thread, before the work starts | Derived from the plan once the goal is set |
| Who's accountable for the goal | Usually nobody specific | The Agent Manager, for that goal |
| What happens if an agent adds nothing | Keeps running, unless someone happens to notice | It isn't recruited again next cycle |
| Where the supervision load sits | On a person, and it grows with every agent added | Held by the layer itself, check-ins and reports |
| How you'd know it's working | You wouldn't, without reading the logs | The goal's own metric |
The team size isn't the interesting variable. Who's accountable for it is.
How this looks in practice
In one recent build, a single goal, increase traffic value from $15k to $20k, got handed to an Agent Manager. Notice what didn't happen: nobody pre-decided the team needed an SEO person, a repair specialist, and a PR specialist. The manager broke the goal into a plan first, and the plan is what produced those three roles, in that combination, for that goal specifically. A different goal would have recruited a different team. Setup to a working team took about two minutes, not counting the thinking time in between, and Tability published the whole thing as a speedrun of the setup.
Zoom out and the numbers get more interesting, and more restrained than you'd expect from a system built to scale agents. An earlier build of Tability's self-hiring agent system grew to 20 agents from just four managers, with a stated plan to keep scaling past 100. But the team size per Agency currently sits at six (one manager plus five specialists), a deliberate ceiling while the team learns where coordination starts to break down with a bigger crew. Even inside a system purpose-built for this, unlimited fan-out isn't the goal. A team that only grows when the plan actually calls for more hands is.
The bottleneck, by the team's own account, was never getting agents to do the work. It was keeping up with what came back: reports, proposals, questions, updates. That's the same supervision load the multi-agent thread above described, and it's a good sign in a strange way: it means the agents were doing enough real work to generate real things to review, not just producing status updates about each other.
Setting up the team before the goal is the usual mistake
The instinct when agents first start working is to sketch the team first. An orchestrator here, a reviewer there, a specialist for every function you can think of, decided in advance, before a single real task exists to justify any of them.
The fix isn't a better prompt library for those roles. It's not designing the team at all, up front. You assign the goal, let the plan reveal exactly what it needs, and treat every agent's continued existence as something that gets re-earned each cycle, not granted once at setup.
This is also where most DIY orchestration setups quietly fail: not on the technical routing, but on accountability. No goal a given agent is actually tied to, no fixed cadence for checking whether it moved anything, no single place a teammate can look to see what's real versus what's just running. You end up with plenty of output and a growing supervision job nobody signed up for.
Where to start
Before you add the next agent to your setup, three questions are more useful than any framework comparison:
- Is there one place you could check to see whether this agent's work moved the goal, without reading a chat log?
- If you removed it, would a person have to pick up the supervision slack, or would nothing really change?
- Was it recruited because the plan called for it, or because it seemed like the kind of role a team like this is supposed to have?
If you're already running agents through Claude or Codex, none of that infrastructure goes away. Tability doesn't replace your models or your tools. It sits above them as the layer that holds the goal, the plan, and the record of whether anything actually happened, so you can answer those three questions without digging through a chat log.
Try Tability free, or book 30 minutes with us and we'll look at your actual setup, agent by agent, and help you work out who's actually accountable for what. Tability or not, it's worth knowing the answer.
.png)
.png)
.jpg)
