A question on Hacker News is pushing at a nerve in the AI agent community: are the orchestration layers that sit between language models and the tools they call actually making things worse, not better?
What an agent orchestrator does
In most AI agent architectures, an orchestrator sits in the middle. The language model produces a plan or a set of intentions, the orchestrator translates those into tool calls, manages state across multiple steps, handles retries when things fail, and coordinates the flow between different models or services. On paper, it looks like necessary infrastructure. In practice, critics argue it adds complexity, burns tokens, and introduces failure modes that would not exist if the model interacted directly with the tools it needs.
The core complaint is that orchestrators consume resources without proportional benefit. Every intermediate step between the model's reasoning and the actual tool call costs tokens. Every retry, every state management check, every routing decision adds latency and expense. When the underlying model is capable of making tool calls directly, the orchestrator becomes an extra layer that mostly adds overhead.
Why the anti-pattern persists
If orchestrators are truly wasteful, the obvious question is why they remain widespread. Part of the answer is historical. Early language models could not reliably make structured tool calls, so an orchestrator that translated natural language into API requests was a practical necessity. As models have improved at function calling and structured output, that necessity has diminished, but the architectural patterns remain.
Another factor is that orchestrators give developers a familiar abstraction. Managing state, handling errors, and routing between services is what traditional software engineering does well. Building an orchestrator feels like building normal software. Letting the model call tools directly feels like giving up control, even when the model handles the task reliably.
There is also a business incentive. Orchestrator frameworks are products. Companies sell orchestration platforms, provide managed services around them, and build consulting practices on top of them. The vendor ecosystem depends on the assumption that orchestration is necessary, which makes it harder for the industry to converge on the insight that it might not be.
When orchestration actually matters
The anti-pattern argument has limits. Orchestrators make sense when the agent needs to coordinate across multiple independent systems that require different authentication, rate limiting, or data formats. They make sense when the workflow involves human approval gates or when the agent's actions have side effects that need to be logged, rolled back, or audited.
The problem is not that orchestration is always wrong. It is that the industry applies it as a default without asking whether a simpler approach would work. For many use cases, a single model with direct tool access, a clear system prompt, and basic error handling produces better results with less cost and latency than a multi-layer orchestrator architecture.
What developers should actually consider
The question is not whether to use an orchestrator but whether the complexity it adds is justified by the problem being solved. Start with the simplest possible architecture. If the model can call the tools it needs directly and handle the response, do that. Add orchestration only when you have a concrete reason, like multi-system coordination, compliance requirements, or audit trails that cannot be handled any other way.
The token cost of unnecessary orchestration is real and recurring. Every call to the model through an extra layer consumes compute that could be spent on the actual task. For teams running agents at scale, the difference between a direct tool-call architecture and a fully orchestrated one can be orders of magnitude in both cost and latency. The industry's reluctance to confront that tradeoff head-on is worth questioning.