Apr 18 (BNP): Organisations are starting to adopt AI agents to rethink how work gets done. The promise is compelling: redefine workflows and bring new adaptability, scalability, and precision to decision-making. Yet many deployments stall or fail for a simple reason: leaders choose a tool when they should choose an architecture.
If you do not decide how work should flow, agents will simply inherit existing bottlenecks and automate existing confusion.
The real question is not what tool to deploy, but how work should be structured.
Two architectures, two logics
In practice, there are two common ways to organise agent work. They can look similar in early pilots, but in practice, they behave very differently.
A swarm is built for parallel exploration. Multiple agents work at the same time, each approaching the problem from a different angle, such as market dynamics, risk, customer perspective, or operational constraints. A supervisor, either human or agent, then synthesises these outputs into a decision.
Swarms are most useful when the problem is underdefined, and the right answer is uncertain. The logic is straightforward: when you do not know which path will work, you increase your odds by exploring several in parallel. Then you choose. This is also why modern deliberative AI methods increasingly try more than one candidate reasoning path before choosing an answer: broader exploration increases the chance of finding a better option before committing.
An assembly line is built for sequential execution. Work is broken into structured steps: extract, validate, approve, execute, log, each with clear controls.
Assembly lines perform best when tasks are repeatable, and the cost of error is high. Here, too, the logic is simple. Strong operations depend on consistency. You want few surprises, clean handoffs, auditable decisions, and measurable improvement over time. Assembly lines do not need to be clever. They need to be reliable.
The decision rule
Ask two questions: How uncertain is the task? And how expensive is a mistake?
If uncertainty is high, favour a swarm. If the cost of error is high, favour an assembly line. If both are high, use both in sequence: start with a swarm to explore the options and define the rules, then move to an assembly line to apply those rules consistently at scale.
What this looks like in practice
It is Monday morning, and you need a clear recommendation by Wednesday: Should we enter Market X, and if so, how?
That is not a single analysis. It is a bundle of questions involving unit economics, competitor response, regulatory constraints, channel viability, and customer willingness to switch.
A swarm works well here because the task requires exploration and benefits from multiple perspectives. One agent models the economics, another maps the competitive landscape, a third pressure-tests regulatory and reputational risk, and a fourth develops go-to-market options.
The decision still belongs to you. What changes is the speed and quality with which credible options emerge, along with a sharper definition of the question you are actually deciding.
Now consider vendor onboarding, refunds, credit issuance, or any process that touches compliance, money, or trust.
In these settings, “mostly right” is still wrong, because small errors compound. A handful of incorrect payouts becomes real money. A few compliance misses turn into audit exposure.
An assembly-line design builds in the right controls: document intake, validation, approval, execution, and logging. This architecture is naturally auditable because each step leaves a record and has a clear pass/fail criterion.
That is not bureaucracy. It is what makes delegation scalable and safe.
The real question is not what tool to deploy, but how work should be structured.
The cost of choosing the wrong architecture
Using the wrong architecture creates predictable failure modes.
When leaders use a swarm for high-stakes execution, they create coordination overhead: too many outputs, inconsistent recommendations, and time lost resolving conflicts.
When leaders use an assembly line for strategic exploration, they get a tidy answer to the wrong question. The pipeline produces something clean and structured even when the underlying problem has not yet been properly framed.
This choice matters even more because agents increasingly do more than generate text. They create tickets, draft contracts, update records, and trigger workflows. As agents move from advising to acting, organisational design becomes the real challenge.
Companies need to redesign roles and workflows around how agents operate rather than simply dropping agents into existing structures. The challenge is not just technical, it’s organisational too.
From tools to organisational design
The shift to agent-based work requires more than deploying new tools. It demands rethinking roles and workflows, and understanding when and how technology can be effective.
Swarms and assembly lines are not competing ideas. They are different architectures for different kinds of work. Organisations need to design around how agents operate and not just insert them into existing structures.
That is when agents stop being an impressive demo and start delivering real operational value.
Alessandro Lanteri is Full Professor of Strategy at ESCP Business School (Turin campus), where he teaches and directs executive education programmes. An expert educator, he helps organisations seize the opportunities of turbulent environments. His book “CLEVER” became an international bestseller. His latest book, “Innovating with Impact,” is published by The Economist. His next book “Strategy Reloaded” will be published by The Economist in 2027.
