Most AI agents do not need a team of agents

Many agent-based applications become more expensive and slower not because the task is complex, but because unnecessary agents are added to them. The practical question isn’t “how many roles to create,” but “what will a new agent contribute to the system: information, permissions, or independent verification.” If the answer is nothing—it’s just another call to the model.

An Agent Is Not Just a Role in a Prompt

A model doesn’t become an agent simply because it’s labeled “Researcher” or “Critic.” It requires a combination of elements: the model, a workflow, tools, state, and constraints. An agent must be able to choose an action, obtain a result, adjust its plan, and know when to stop.

Therefore, multi-agent systems are not about the number of models, nor are they an imitation of an office setup consisting of an “analyst,” “editor,” and “controller.” Roles only make sense when there is a real division of context, tools, authority, or responsibility. Two different agents can be more useful than sixteen identical ones, but this isn’t a universal formula—it’s the result of a specific experiment.

Freedom Is Needed Only Where There Is Uncertainty

If the next step depends on the outcome of a tool, the ReAct cycle is appropriate: the model acts, observes the consequences, and chooses how to proceed. If the steps are known in advance, a standard workflow is more reliable, where the code controls the process and the LLM solves only ambiguous tasks.

This is precisely where an important engineering distinction comes into play. The code must validate required fields, save results, retry operations after network errors, request confirmation, and prevent duplicate payments. The model can be used to select a search strategy, break down a task, or evaluate a draft.

A graph is more useful than an endless conversation

A conversation among multiple agents is useful for prototyping and tasks with an uncertain path: research, hypothesis testing, and independent verification. But in production, it’s more important to see not only who said what to whom, but also where the process stands, what has already been done, and which next step is permitted.

A graph with states, branches, cycles, and pauses makes this structure explicit: task received → plan created → sources gathered → completeness verified → draft prepared → review completed → human approval received. The model retains flexibility but operates within a permitted framework.

An agent is a stack, not a single library

A full-fledged system consists of several layers: Agent SDK, workflow or graph runtime, runtime environment, memory, observability, evals, and security. SDKs like the OpenAI Agents SDK or Google ADK help assemble the workflow and integrate tools. LangGraph, Mastra Workflows, or XState add a managed process structure. Off-the-shelf solutions like the Claude Agent SDK and Codex SDK cover a narrower use case—coding agents.

This also means that “adopting a framework” does not automatically equate to “getting a reliable agent.” The runtime environment, commands, repository structure, tests, and feedback influence the outcome just as much as the model itself.

Where the Beautiful Scheme Falls Apart

Agent-based approaches come at a cost. ReAct consumes more time and tokens, and multiple agents introduce latency and coordination overhead. Self-Refine and Reflexion may not correct an erroneous conclusion but instead reinforce it. Searching across multiple options is useful only when those options can be reliably evaluated.

Conversational architecture easily turns into an “agent theater”: identical roles receive identical data and repeat the same mistakes. A graph defines possible transitions but does not, by itself, guarantee durable execution—recovery after a failure or a long wait. And no single framework covers the entire stack, so security, auditing, evaluations, and observability remain separate engineering challenges regardless.

A good starting point is usually more modest than what demos promise: a single agent, a limited set of tools, and an explicit workflow. Which part of your task would you still leave to the model, and which part would you implement with regular code without hesitation? Source: All Articles in a Row / Artificial Intelligence / Habr