An AI agent that researches a problem, recommends an action and updates a business system is already a significant step beyond a chatbot. Put several specialised agents together, however, and the proposition becomes more ambitious: software that can coordinate decisions.
For enterprises, the attraction is clear. Processes that currently stall between departments and approval queues could progress faster. One agent gathers evidence, another evaluates options, and a third prepares the next action. People spend less time transferring information and more time exercising judgement.
But connecting agents also connects their weaknesses. A mistaken assumption can become another agent’s instruction and then an operational decision. The challenge is to build an AI team whose performance improves through collaboration while its authority and actions remain understandable.
Give Every Agent a Business Purpose
The strongest starting point is a specific business process with a measurable problem. Customer onboarding and campaign analysis offer opportunities to divide work into distinct responsibilities. Introducing agents simply because a platform supports them creates a different outcome: more software to supervise.
“The advantage of ‘teams’ of agents is that each can handle different parts of a workflow and only be provided with the tools and information relevant to their role,” says Paul Holt, VP of EMEA at .
Holt describes an IT incident response involving separate agents monitoring alerts, identifying affected systems and recommending actions. Specialisation allows work to happen in parallel while limiting the access and context each agent requires. The distinction matters. A useful AI team does more than send the same question to several models. Each agent contributes a defined capability and produces something another participant can use.
internal evaluation illustrates the potential: a lead agent working with specialised subagents outperformed a single agent by 90.2% on research tasks. The advantage was greatest for questions that could be investigated in several independent directions, reinforcing the importance of choosing work that benefits from parallel exploration.
Andrew McCarthy, general manager, EMEA at , points to media agency Brainlabs as an example. He describes a system that converts meeting notes into tasks and routes them to specialised agents, with some work completed before the meeting finishes. Client onboarding can begin when an agent reads a new client page and creates a checklist. “They’re closing the gap between deciding what needs to happen and actually getting it done,” McCarthy told Silicon UK.
That is an attractive enterprise proposition, particularly where fragmented systems leave employees repeatedly copying information or chasing progress. However, the business case must account for the whole process.
That business case must also accommodate greater resource consumption. Anthropic reports that its multi-agent systems used around 15 times as many tokens as chat interactions, compared with roughly four times for individual agents. Better coverage and faster completion therefore need to justify the additional consumption.
Faster drafting provides little benefit if reviewing the output consumes the time saved. “Adding more agents stops being useful when managing them takes more time and effort than they save,” McCarthy commented.
Enterprises should, therefore, compare a proposed team against both the existing process and a simpler alternative. Measure completion time, output quality, correction effort and operating cost. Where ordinary automation can execute predictable steps reliably, use it. Reserve agents for work requiring interpretation or decisions about what happens next.
A specialist team depends on reliable handovers. An agent cannot make a sound decision from a polished summary if the summary strips away the qualifications that made the original finding meaningful.
Research from examining five multi-agent frameworks across more than 150 tasks identified 14 distinct failure modes. These fell into three groups: system design, misalignment between agents, and task verification or termination. The findings underline why defining responsibilities, preserving context and establishing when work is complete are central engineering requirements.
Consider marketing investment. An analytical agent identifies a fall in campaign performance; a strategy agent recommends reducing spending; an execution agent prepares the change. That sequence appears coherent until somebody discovers that one advertising platform supplied its data late.
Alexander Igelsböck, CEO and co-founder of , describes precisely this risk: incomplete data becomes an incorrect conclusion, which becomes a budget decision. “Reliable handovers depend just as much on data definitions, metadata and governance as they do on the sophistication of the models themselves,” Igelsböck told Silicon UK.
A dependable handover should identify the task, the result, its supporting evidence and any unresolved uncertainty. For campaign analysis, that includes the metrics used, the reporting period, data completeness and possible explanations for the change. The receiving agent should check that these requirements have been met before proceeding.
This also creates a practical boundary between planning and execution. An agent may propose several options without possessing authority to implement any of them. Its recommendation should carry enough evidence for the next participant, whether software or a person, to assess the proposal independently. Denis Romanovsky, chief AI officer at , emphasises structure: “A handover is more reliable when it is clear and structured: a defined goal, a defined output format, and a check by the receiving agent.”
An orchestrator can allocate tasks and identify inconsistencies. But that coordinating agent also needs limits. It should not be able to override permissions simply because completing the task would otherwise be inconvenient.
Negotiation between agents requires similarly explicit rules. A procurement agent prioritising price and an operations agent prioritising delivery speed need an agreed business objective, including acceptable trade-offs. Without one, they can each perform their assigned role while collectively producing an undesirable outcome.
Your business must decide which priorities take precedence and which require a named decision-maker.
Stop Agreement Becoming a Shared Mistake
Collaboration can make an answer more persuasive without making it more accurate. Several agents may interpret the same incomplete information and reinforce one another’s conclusions. Their agreement can conceal the absence of independent verification.
“Two agents can talk themselves into a confident-sounding wrong answer just as easily as two people can; the conversation gets more fluent without getting more correct,” says John Newton, chief innovation strategist at Hyland. “The way to tell the difference is to check their output against something neither agent generated.”
For an enterprise, that means connecting decisions to authoritative evidence: the original contract, approved policy or verified operational data, for example. An agent’s confident explanation should never replace the underlying source.
Newton illustrates the danger with an insurance claim. One agent misreads a policy exclusion, another approves a payout and a third schedules payment. Each step advances the process while moving further from the original mistake.
The answer is verification at relevant boundaries. Before accepting a recommendation, the next stage checks the evidence, applicable rules and permission to act. Higher-impact decisions require stronger checks; routine, reversible work can proceed with lighter supervision. “One agent asking another to do something should never be enough to grant permission,” Holt told Silicon UK.
This is especially important when agents can change records or initiate transactions. Systems and tools should enforce permissions. An instruction to remain within budget is weaker than a spending ceiling the agent cannot bypass. Romanovsky also advocates limits on how many actions a chain can take within a given period. These controls help contain circular discussions and rapidly spreading errors.
Human approval must be meaningful. A reviewer needs the evidence, uncertainty and proposed consequences, alongside sufficient time and authority to challenge the action. Otherwise, approval becomes another automatic step. Dhruv Datta, founder, co-CEO and co-CTO at AI, offers a useful test: “The clearest dividing line I’ve found in building AI systems is whether a task is reversible.”
Enterprises should ask how quickly the error becomes visible and whether the resulting action can be undone. Those answers should determine how much autonomy is appropriate.
Build a Team People Can Understand
Understanding an AI team requires more than retaining a transcript of its conversations. Business owners need to reconstruct what happened: which agent acted, which evidence it used, what permissions applied and where a consequential decision was approved.
“The objective should be provenance rather than simply producing an enormous log of everything an agent did,” says Igelsböck.
Useful records connect the original request to each handover and resulting action. They include source data, timestamps, relevant policy versions, model and prompt versions, tool responses and approvals. A shared identifier allows investigators to follow one piece of work across systems.
An agent’s account of why it acted is useful context, but your company should retain the observable evidence too. Tool outputs and actual system changes provide firmer ground for investigation than a plausible explanation generated afterwards.
Before deployment, run the team alongside the existing process without allowing it to make operational changes. Compare its proposed actions with real outcomes and review where it misunderstood instructions, missed evidence or escalated unnecessarily. Then introduce limited authority for a bounded set of tasks.
Testing should include missing data, contradictory recommendations, unavailable tools and attempts to exceed permissions. It should also demonstrate that people can stop the process. Revoking one agent’s access is insufficient if other agents continue acting on its earlier instructions.
Finally, give the whole process an accountable business owner. Technical teams can maintain the infrastructure, but someone must own the outcomes and decisions about expanding authority.
“The test for me is pretty simple: does each agent have a clearly defined job and does it materially improve the outcome? If it doesn’t, remove it,” Wes Maynard, managing director at The MTM Agency, told Silicon UK.
An enterprise’s first AI team should earn greater responsibility through observable results. Start with a process people understand, establish a baseline and expand only when benefits survive the cost of supervision. The goal is useful work delivered faster, with enough evidence and control for the business to stand behind the result.