The Enterprise Guide to Multi-Agent Orchestration in Financial Services

Most AI agent deployments today are a single agent wrapped around a chatbot. Gartner expects over 40 percent of agentic AI projects to be cancelled by 2027, largely because of weak governance rather than weak models. Multi-agent orchestration is a different architecture. Specialised agents with defined roles, checked by other agents or people, inside an auditable system. This guide covers what that means for financial services and how Broccoli™'s Multi-Agent Orchestration capability applies it.

Introduction

Enterprise interest in multi-agent systems has been building rapidly. Gartner recorded a sharp rise in enterprise inquiries about multi-agent systems between 2024 and 2025 and expects 40 percent of enterprise applications to carry task-specific AI agents by the end of 2026, up from under 5 percent the year before [1].

Financial services are moving with that curve, but the technology underneath most of these deployments is still a single agent wrapped around a chatbot, handling one task end to end with no separation of duties. That works for a FAQ bot. It does not work for a workflow where a wrong decision could lead to a regulatory finding.

Multi-agent orchestration represents a distinct architectural approach instead of using a bigger model. This process divides up a workflow among specialised agents, each with a defined role, co-ordinates them via a governing layer, and includes the kinds of checks that a regulator would expect from a human team carrying out the same job. This guide explains what this means, the reasons why single-agent systems fail in regulated financial services, and how Broccoli™'s Multi-Agent Orchestration feature puts this into practice. 

What Is Multi-Agent Orchestration?

Multi-agent orchestration is the coordination layer which divides a complex workflow amongst multiple specialised AI agents. Each agent has a defined role. Multi-agent orchestration is in charge of managing the way they pass work to one another, how they escalate exceptions, and ensure that they remain within their allowed scope. For example, one agent can extract data from a document, another checks this data against the source systems, and a third one prepares a recommendation, with a person or another agent reviewing the output before any action is taken.

This is a different pattern from a single large model handling a task end to end. An agent that both makes a decision and approves it has no separation of duties. A bank would neither allow such blending of responsibilities in a human process nor in an AI-driven process.

Core Components of Multi-Agent Orchestration

A functioning multi-agent system for financial services is built from a consistent set of architectural components, regardless of vendor. Recent academic work on agentic AI governance describes orchestration as the point where governance requirements actually get enforced while a system is running, not just documented after the fact [9]. That enforcement happens through a specific set of building blocks.

Routing determines which agent handles a given task, based on the type of work, the data available and the current state of the workflow.

Scoped identities give each agent its own credentials and permissions, rather than one shared identity across the whole system, so an intake agent cannot silently act with a checker agent's authority.

The permissions relating to tools and data determine which systems and data sources an individual agent is allowed to call, this being in accordance with the role-specific policies that are described later in this guide. Approval gates are the points in the structure at which a maker's output comes to a halt and has to be waited on by a checker, this checker being either a human or an agent.

State management keeps track of the position of a particular task within the workflow, of what has already taken place and of what still needs to be done, in order that if a failure occurs part way through it does not lose the record of what had gone before.

Observability refers to the ability to see what each agent is doing while the system is running, and not merely after an incident has occurred.

Rollback is the capability to cleanly reverse an agent's action if a downstream check detects a problem.

In a regulated environment none of these components is optional. If a system does not have scoped identities it will be impossible for that system to ensure maker-checker separation. A system that lacks state management and observability is unable to generate the type of audit trail required by Article 12. Those components are not features that are added on top of orchestration; they are what orchestration means in practice.

The Protocols Behind Multi-Agent Orchestration?

Multi-agent orchestration needs a way for agents to reach tools and a way for agents to talk to each other, and two open protocols have become the default plumbing for both. The Model Context Protocol (MCP), introduced by Anthropic in November 2024, standardises how an individual agent connects to external tools, data sources, and enterprise systems. MCP offers one consistent interface rather than a custom integration for every tool an agent touches [6]. The Agent2Agent Protocol (A2A), introduced by Google in April 2025 and later transferred to Linux Foundation governance, standardises how independently built agents discover each other, delegate work and exchange results across vendor boundaries [7].

This distinction is important when it comes to the construction of an orchestration layer. MCP governs how a single agent extends itself to access its tools, while A2A deals with how multiple agents, possibly running on different platforms, co-ordinate with one another. For example, a financial institution's document-intake agent could use MCP to retrieve records from its core banking system and then use A2A to pass a structured summary on to a separate risk-assessment agent for it to review.

Neither protocol can enforce governance by itself; its function is to pass on data and requests between various agents and systems. The role-based, product-specific and context-specific policies, the maker-checker separation and the audit logging described below are situated atop this underlying infrastructure, not within it.

Why Financial Services Needs Multi-Agent Orchestration

Financial services workflows almost never exist within one system; a commercial loan application for example involves core banking, document management, the credit bureaus, KYC and AML screening tools, and usually also a separate case management system, each having its own data format and its own rules. If a single agent is responsible for dealing with the entire process he either has to limit himself to just one aspect and get that done well, or attempts to carry out all the tasks and in time becomes hard to test, debug and govern as the requirements develop.

Deloitte's 2026 Tech Trends research on multiagent systems found that while 30 percent of organisations are exploring agentic options and 38 percent are experimenting, only 14 percent have a deployable solution and just 11 percent are actually in production [10]. That gap between experimentation and production is largely a complexity problem. Workflows that span multiple systems and require different types of judgment at each step are exactly where single-agent approaches stop scaling.

Cross-functional dependency compounds this. Underwriting depends on document verification. Fraud monitoring depends on transaction data combined with customer history. Compliance depends on input from both. A change in one part of the workflow ripples into the others, which single, monolithic agents handle poorly.

Exception handling is the other driver. In many financial workflows, straightforward rule-based cases are a minority. The rest require context, judgment or escalation. A single agent tends to treat every case the same way, either overly cautious and escalating too much, or overly confident and missing genuine risk. Specialised agents, each built around a narrower part of the workflow, apply more consistent judgment within their own scope, and the orchestration layer handles the coordination between them.

Why Single-Agent Systems Break Down in Regulated Financial Services

A single agent prepares a credit recommendation and approves it themselves. It then masks a failure of control by using a friendlier interface. Separation of duties is already built into the procedures of the financial services sector, since the person who prepares the work does not sign off on it themselves. An underwriter will not approve their own recommendation without it having first been reviewed. Merely combining these functions into a single model does not eliminate the need for separation of duties; it only conceals the fact that this duty of separation is missing.

Google Cloud's 2025 survey of 556 financial services leaders found institutions are moving agentic AI into live production for multi-step operational work [5], which is where a single, undifferentiated agent runs into trouble. The critical element is the undifferentiated part. An example is one model with too much scope, doing preparation, judgment and approval in a single pass, with no natural point for a human or another system to check its work. This is a problem.

The Three Controls That Make Orchestration Trustworthy

True multi-agent orchestration involves more than just multiple models communicating with one another. In the financial services, three controls distinguish a governed system from a group of bots that share a prompt.

Role, Product and Context-Specific Agent Policies

Each agent within the system functions according to a policy that is tailored to its specific role, product line, and context rather than receiving a general instruction to be helpful. For example, an agent handling the intake of documents for a mortgage application has different permissions and access to data than an agent responsible for fraud monitoring on a corporate account, even though both agents are operating within the same platform. This point is clearly made in Arthur AI's 2026 analysis of regulators' expectations regarding agentic AI. Companies must restrict the systems and data that an agent is allowed to call, impose transaction limits, and prevent one agent from broadening its own scope [3].

Maker-Checker Transparency

The maker-checker approach is well known in the banking industry. For years, procedures relating to credit approvals, the release of payments and trade confirmations have followed this method, with one person preparing a proposal and a different person reviewing and giving approval. Multi-agent orchestration uses the same principle with respect to agents: one agent, or a human, puts forward a recommendation and then a separate agent, or a human, checks it before any action is taken. In its framework for agentic AI in regulated settings, Arthur AI treats human-in-the-loop approval for significant actions, payments, lending decisions, trading, and account changes as a basic control measure and defines the boundaries of autonomy in cases where an agent must stop and ask a person for approval [3].

Immutable Audit Trails

It is necessary for every action taken by an agent to be recorded in such a way that the record cannot be quietly edited afterwards, specifying who acted, what data it dealt with, what decision it reached, and the reason for that decision. According to Praesidia's 2026 governance analysis, the minimum requirement in financial services is a structured, tamper-evident log entry for each action by an agent, usually achieved through cryptographic signing or chaining, so that any deletion or alteration of a single record can be detected [4]. Without this control, an organisation will not be able to reconstruct what took place when a regulator or auditor makes a request, turning what should be a simple review into a far more serious issue.

Step	Agent role	Checkpoint
1. Document intake	Intake Agent	Reads and structures uploaded documents
2. Verification	Verification Agent	Cross-checks data against source systems, flags mismatches
3. Risk assessment	Assessment Agent (maker)	Prepares a risk recommendation
4. Review	Checker Agent or human reviewer	Approves, rejects or escalates the recommendation
5. Record	Audit Agent	Writes an immutable, timestamped log of every step above

What EU AI Act Article 12 Actually Requires for Agent Logs

Immutable audit trails are not just good practice, they are close to a legal requirement for high-risk AI use in the EU. Article 12 of the EU AI Act requires high-risk AI systems to technically allow automatic recording of events across the system's lifetime, with logging capable of identifying situations that could present a risk, supporting post-market monitoring, and enabling ongoing oversight of the system's operation [8].

Deployers must retain those logs for at least six months, longer if other applicable law requires it.

The Act does not specify a particular format for multi-agent logs, i but the standard it sets is whether the logs let an authority reconstruct what happened and identify risk after the fact. A single chat transcript from one agent is not sufficient to meet that criterion in the case of a workflow which went through five agents and two approval stages. Each agent's actions as well as the transfers between them must be included in the record.

Similar practical expectations apply to institutions outside the EU. Examiners and auditors need to be able to work out what a system did, not just see that it produced a plausible-looking output. If the audit trail is built from the beginning around the actions of individual agents, there is no need to add that structure afterwards when the workflow is already in production.

Single-Agent AI vs Multi-Agent Orchestration vs Broccoli™: A Comparison

Dimension	Single-agent AI	Generic multi-agent orchestration	Broccoli™'s Multi-Agent Orchestration
Separation of duties	None, one model does everything	Possible, depends on implementation	Built in, maker and checker roles are structurally separate
Agent permissions	Broad, one shared scope	Configurable	Role, product and context-specific by design
Audit trail	Often a chat log, editable	Varies by vendor	Immutable, tamper-evident by default
Human escalation	Ad hoc	Configurable	Defined autonomy boundaries with mandatory escalation points
Fit for regulated FS workflows	Weak	Depends on governance maturity	Built specifically for regulated financial services

“An agent which both makes recommendations and approves its own work has no genuine control boundary, merely having a chat interface spanning the gap. Multi-agent orchestration only earns trust when the maker and the checker are structurally separate, not just prompted to behave differently.”

Jeet Parekh, Chief AI Architect, Dailoqa

Multi-Agent Orchestration Across the Five Financial Services Verticals

The controls described above apply the same way in every vertical, but the agent roles and where the maker-checker split sits look different depending on the workflow.

Vertical	Example multi-agent workflow	Where the maker-checker split sits
Retail & Commercial Banking	Credit memo preparation across document intake, verification and drafting agents	Drafting agent prepares the memo, a separate agent or credit officer approves before underwriting
Wealth Management	Portfolio review assembled from multiple data sources, flagged for rebalancing	Assessment agent proposes a rebalancing action, a relationship manager approves any client-facing recommendation
Risk & Compliance	Transaction investigation spanning alert triage, evidence gathering and case-building	Investigation agent compiles the case, a compliance officer or checker agent decides whether to escalate
Capital Markets	Trade reconciliation across venues with mismatched formats	Reconciliation agent flags breaks, a separate agent or operations analyst confirms genuine exceptions
Insurance	First notice of loss processed from varied document formats	Claims agent prepares the assessment, a checker agent or adjuster approves payout decisions

In every case, the pattern repeats. Agents do the preparation and coordination across systems. A separate agent or a person makes the call on anything that carries risk, and the record of who did what stays intact regardless of how many agents touched the workflow.

Why Most Multi-Agent Projects Get Cancelled

Enthusiasm for multi-agent systems has outpaced governance maturity. Gartner expects over 40 percent of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls, and not model performance [2]. Gartner's own analysis points to a specific pattern behind this. Many vendors are “agent washing,” rebranding existing chatbots and RPA tools as agentic without the underlying architecture to back it up [2].

Gartner puts a number on how much of the vendor landscape this affects. Of the thousands of vendors now marketing agentic AI capabilities, Gartner estimates only around 130 offer genuine agentic functionality, the rest are existing chatbots, assistants or RPA tools relabeled without the underlying autonomy or orchestration the term implies [2]. For a financial institution evaluating a multi-agent platform, that ratio is a reasonable starting assumption. Most vendor claims will not hold up to a governance review.,

For financial services, inadequate risk controls matter. A multi-agent system without role-specific policies, maker-checker separation and immutable logging falsely mimics a governed system on the surface. It is likely to get shut down the first time a regulator or internal audit asks it to prove what happened.

Multi-Agent Orchestration in Practice

Under Broccoli™'s Multi-Agent Orchestration capability,. agents are scoped to a specific role, product and context rather than given broad, general permissions. Every action that carries risk, a payment, a credit decision, an account change, has a defined checkpoint, with another agent acting as a checker or a person. Every step, across every agent, writes an immutable log that can be reconstructed on demand.

None of this depends on a single vendor’s claim. It depends on an institution asking, for every agent in its own environment, who checks this agent's work, and whether that answer would satisfy an examiner.

Frequently Asked Questions on Multi-Agent Orchestration

What is the difference between a single AI agent and multi-agent orchestration?

A single agent handles a task end to end with one model doing everything, preparation, judgment, and often approval. Multi-agent orchestration splits that same workflow across specialised agents with defined roles, coordinated by a governing layer that manages handoffs, permissions and escalation.

Why do financial institutions need maker-checker controls for AI agents?

Financial services already require separation of duties for high-risk decisions, where one party prepares, and a separate party approves. Maker-checker controls apply that same principle to AI agents, so no single agent makes and approves a consequential decision without independent review.

What makes an audit trail immutable?

An immutable audit trail cannot be silently edited or deleted after it is created, typically enforced through cryptographic signing or chaining so that any alteration or deletion of a record is detectable.

Why do most agentic AI projects fail or get cancelled?

Analysts point to escalating costs, unclear business value and inadequate risk controls, not model capability, as leading causes, along with vendors rebranding existing tools as agentic without real orchestration underneath.

Is multi-agent orchestration the same as running multiple chatbots?

No. Multiple chatbots without a coordinating layer, defined roles or checkpoints are not orchestrated. They are just multiple single agents running in parallel with the same governance gaps as one.

What is agent washing?

Agent washing is the rebranding of existing products, such as chatbots and robotic process automation tools, as agentic AI without the underlying architecture, autonomy or governance that the term implies.

How does Broccoli™'s Multi-Agent Orchestration differ from a general-purpose orchestration framework?

It applies role, product and context-specific policies, maker-checker separation and immutable audit logging by default, built specifically for regulated financial services rather than configured after the fact.

Do all AI agent actions need human review?

No. Low-risk, reversible actions can run with agent-to-agent checking. High-impact actions, payments, lending decisions, trading, account changes, need defined escalation points to a human reviewer.

What financial services workflows suit multi-agent orchestration best?

Workflows with multiple distinct steps and risk levels, such as KYC review, credit assessment, claims processing and transaction investigation, where different parts of the process call for different expertise and different levels of oversight.

What is the difference between MCP and A2A?

MCP (Model Context Protocol) standardises how a single agent connects to external tools and data sources. A2A (Agent2Agent Protocol) standardises how independently built agents communicate and delegate work to each other across vendor boundaries. They solve different layers of the same coordination problem.

What does the EU AI Act require for AI agent logging?

Article 12 requires high-risk AI systems to automatically record events across their lifetime, in enough detail to identify risk and support post-market monitoring, with logs retained for at least six months.

Conclusion

There is genuine enthusiasm within the industry for multi-agent systems, just as there is a high failure rate associated with them. The reason for the difference lies not in the model but whether the system had been constructed with role-specific permissions, maker-checker separation, and an audit trail capable of withstanding examination.

Broccoli™'s Multi-Agent Orchestration capability is built around those three controls, not added to them later. If your institution is evaluating a multi-agent deployment, the question worth asking before the architecture diagram is who checks each agent's work, and whether that answer would survive an examiner's questions.

Glossary

Maker-checker. It is a type of control in which one party prepares or suggests an action and another party then examines it and gives its approval before the action is put into effect.

Immutable audit trail. A record of an action that cannot be silently edited or deleted after it is created, typically enforced through cryptographic signing or chaining.

Agent scope. The specific role, product line, data access and permitted actions an individual agent is allowed to operate within.

Agent washing. Rebranding an existing chatbot or robotic process automation tool as agentic AI without the underlying autonomy, orchestration or governance the term implies.

References

[1] Gartner. "Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026, Up from Less Than 5% in 2025." 2025. https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025

[2] Gartner. "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027." 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

[3] Arthur AI. "Regulator Controls for Agentic AI in Financial Services." 2026. https://www.arthur.ai/column/agentic-ai-security-controls-financial-services-regulators

[4] Praesidia. "AI Agent Governance for Financial Services." 2026. https://praesidia.ai/blog/ai-agent-governance-financial-services

[5] Google Cloud. "New Research Shows How AI Agents Are Driving Value for Financial Services." 2025. https://cloud.google.com/transform/new-research-shows-how-ai-agents-are-driving-value-for-financial-services

[6] Anthropic. "Introducing the Model Context Protocol." 2024. https://www.anthropic.com/news/model-context-protocol

[7] Google Developers Blog. "Announcing the Agent2Agent Protocol (A2A)." 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

[8] European Union. Artificial Intelligence Act, Article 12: Record-Keeping. Regulation (EU) 2024/1689. https://artificialintelligenceact.eu/article/12/

[9] "Beyond Task Success: An Evidence-Synthesis Framework for Evaluating, Governing, and Orchestrating Agentic AI." 2026. https://arxiv.org/pdf/2604.19818

[10] Deloitte. "Tech Trends 2026: Multiagent Systems in Enterprise." 2026. Cited via https://www.deployedlabs.com/blog/deloitte-tech-trends-2026, a secondary source referencing Deloitte's original report. Recommend swapping for Deloitte's primary hosted URL before publishing.