Academy

One agent or many? When each one fits

Sometimes a single agent is the best answer, and sometimes the work should be split across several. The deciding factor is the complexity of the task, not how advanced the architecture looks.

The Felesh team Updated 7 min

When you build your first agent, it is natural to hand everything to one: a single model, a few tools, a little memory. For many tasks, this is enough. But as the work grows, a question appears — should everything stay inside one agent, or should the work be split across several specialised ones? The answer depends on the complexity of the task, not on which architecture looks “more advanced.”

What a single agent is

At its simplest, an agent is a language model equipped with decision-making logic, a few tools, and sufficient memory to track the work. A single agent holds all of this in one place and does things in sequence: it understands the input, decides, calls a tool, and returns the result.

One agent, one path, one memoryA user asks for a Lisbon trip, 12 to 15 November, under 900. The request enters one agent, which holds a model and a single memory. The agent calls its tools in turn: flights, then hotels, then events, and each result is written into the same memory: flights 210, hotel 480, events Sintra. The one agent then answers.one agent runs the whole jobuser asksLisbon trip12–15 Novunder 900agentmodel: what next?memoryflights: 210hotel: 480events: Sintratoolsflightshotelseventsone path, one memory, one place to debug
A single agent takes the request, calls its tools one after another and keeps the whole job in one memory.

The primary advantage is simplicity. One path, one memory, one place to debug. When a task is simple and needs only a few tools, a single agent is usually the best choice; adding more agents just adds overhead and complexity.

When one agent isn’t enough

As the work gets more complex, a single agent becomes a bottleneck. Consider a user who wants to plan a trip: search for flights, find a hotel, suggest activities. Each of these needs different expertise and different tools, and there’s no reason they should run one after another. A single agent is forced to push them through one at a time, in one crowded context window. This is where splitting the work makes sense.

Three independent jobs forced into a lineA timeline for one agent. It searches flights, then hotel, then events, each starting only when the previous one ends. Every result is added to the same context window, and a meter beside it fills up with the three result lists. The last job waits for the other two, though none of them needs another’s result.one agent, three jobs in a rowflightshoteleventstimeone contextflight resultshotel resultsevent resultsthe last job waits for the other twonone of them needs another’s resultall in one windowfull
Flights, hotel and activities do not need each other, yet one agent runs them in a line and piles all three results into one context.

The coordinator–worker pattern

The most common way to organise several agents is a three-role pattern. A coordinator takes the request, understands it, and sets the strategy. It then hands the work to several specialised workers, each handling one part — and because they’re independent, they can run at the same time. At the end, the results are gathered and turned into one coherent answer.

In the trip example, the coordinator hands three workers their jobs: one for flights, one for the hotel, one for activities. All three search in parallel and return their results. The benefits are clear: each worker is more expert because it knows only one job; independent tasks run in parallel and the whole thing is faster; and adding a new capability means adding a new worker rather than rewriting one large agent.

Coordinator, three parallel workers, one answerThe request is Lisbon, 12 to 15 November, under 900. The coordinator splits it into three jobs. The flights worker looks for 12 Nov to Lisbon, the hotel worker for 3 nights in Alfama, the events worker for tram 28 and Sintra. All three search at once, then return: flight 1032 for 210, Casa Alfama for 480, a Sintra day for 60. The coordinator joins them into one answer: Lisbon, 3 nights, 750 total.request: Lisbon, 12–15 Nov, under 900coordinatorsplits in 3then joinsthe resultsflights worker12 Nov to Lisbonsearching…flight 1032 · 210hotel worker3 nights, Alfamasearching…Casa Alfama · 480events workertram 28, Sintrasearching…Sintra day · 60answerLisbon,3 nights,750 totalthe three searches ran at the same time
A coordinator splits the trip into three jobs, three workers search at the same time, and their results come back as one answer.

Why parallel workers are safe

Running several workers at once sounds risky — couldn’t they trip over each other? They don’t, and the reason is a design rule worth stating plainly: each worker is stateless. It holds nothing of its own between calls; everything it needs is handed to it as input, and when it’s done it returns a result and keeps no memory of having run. Two workers doing the same kind of job share no hidden state, so there is nothing for them to corrupt by running together. Stateless is not the same as deterministic, though: a model-backed worker can return a different answer to the same input, so whatever coordinates the workers still checks what comes back.

This is what lets splitting the work scale. Because a worker carries no state, you can run ten copies of it as safely as one, add more when the load grows, and reproduce any result by replaying its input. The state that does need to persist — what the user wants, how the overall job is going — lives in one shared place the coordinator manages, not scattered inside the workers. Keep the workers stateless and the hardest parts of running them in parallel mostly disappear.

Same input, same output, nothing keptThe same input, a flights search from OPO to LIS on 12 Nov for one adult, is sent to the flights worker on machine A and then on machine B. Both return the identical result, flight 1032 for 210, and each keeps nothing afterwards. The state that must persist, the Lisbon trip with flights done, sits in the coordinator’s store, not in a worker.the flights worker, run twicesame inputOPO to LIS12 Nov1 adultmachine Aflights workerkept: nothingmachine Bflights workerkept: nothingflight 1032210flight 1032210same outputcoordinator’s store:Lisbon trip, flights donethe state that persists lives here, not in a worker
A stateless worker returns the same result for the same input on any machine, so the job's state lives with the coordinator and not in the workers.

Which one to choose

The choice between the two is an engineering decision, not a matter of taste. Pick a single agent when:

  • The task is simple and its path is short.
  • The tools are few and don’t interfere with each other.
  • Parallelism brings no benefit, because the steps depend on one another.

And split the work across several agents when:

  • Several distinct specialties are needed that don’t blend together (searching flights has nothing to do with searching hotels).
  • Parts of the work are independent and running them in parallel saves time.
  • You want the system to grow by adding new roles, without touching the whole architecture each time.
The three tests, one agent or a splitA table of three tests with a worked case for each side. Path: one agent fits when the steps depend on each other, such as look up and then reply; a split fits when flights, hotel and events do not wait on one another. Tools: one agent fits two tools with no clash; a split fits distinct specialties, since flights are not hotels. Growth: one agent fits a fixed job; a split fits when you can add a car-hire worker and leave the rest untouched.the testone agent fitssplit fitspathlook up, then replyeach needs the lastflights, hotel, eventsnone waits for anothertoolstwo tools, no clashlookup, replydistinct specialtiesflights are not hotelsgrowththe job stays fixedone prompt covers itadd a car-hire workerrest untouched
Each of the three tests has a side: short dependent steps and few tools point to one agent, independent specialties and growth point to a split.

The cost of many agents

Splitting the work isn’t free. The moment several agents are involved, you have to manage coordination: who takes which task, how the results come together, and what happens if a worker fails. This new complexity is only justified when the task is large enough. A good rule: start with the simplest thing that works, and only split the work when a single agent has genuinely reached its limit.

The coordination bill of many agentsThree new jobs appear once several agents are involved. Assign: who takes which task, flights, hotel, events. Combine: how three results become one itinerary. Recover: what happens if a worker fails, shown as the hotel worker timing out. The coordinator must then decide: retry it, or answer without a hotel.three new jobs, from the moment you splitassignwho takes which taskflights, hotel, eventscombinehow the results come together3 results into one itineraryrecoverwhat if a worker failswaiting on the hotel workerhotel worker timed outretry it, or answer without a hotel: the coordinator decides
Splitting adds three jobs a single agent never had: assigning the work, combining the results, and deciding what to do when a worker fails.

Splitting too early is just as much a mistake as splitting too late. The skill is in spotting the right moment — and that moment is set by the complexity of the task, not by the appeal of the architecture.