The AI Orchestration Layer in Banking: Router, Planner, Domain Agents, Reviewer, and Who Is Responsible for What

When a customer writes in his bank's chat, "I'm flying to Lisbon on Saturday, my card limit isn't enough, and the fee from 3 October was charged twice", that is three cases in one sentence: a limit change, a complaint and a trip affecting both. No single AI agent should decide that alone. That is what the AI orchestration layer is for: the layer that breaks a request down, distributes it to the right domain agents, has every answer reviewed, hands over to people where necessary and can prove afterwards what happened. This article describes the roles that layer needs, its responsibilities towards core banking, CRM and CDP, and how to tell whether it works. How domain agents with a bounded mandate interact is covered in part 5 of our Agentic Experience Platform series; here the subject is the orchestration itself.

What the AI orchestration layer in banking is

The term has taken hold in 2026 among consultancies and vendors, with remarkably similar definitions. EY describes orchestration as the layer that "sits above fragmented systems": when a customer asks an agent to take an action, it captures intent, pulls the right data, applies policy and risk limits, routes work across products and partners, and records what happened for audit and compliance (EY, June 2026). A second EY publication says the layer coordinates "handoffs, permissions, tool access, policy rules, escalation points, human approvals, monitoring and evidence capture", and that the credible model is a "governed network" of small, seasoned agents for defined process steps rather than one mega agent for the whole process (EY, October 2026).

Process platforms speak of "agentic orchestration" and mean the combination of deterministic flows with dynamic agents. Camunda surveyed 125 senior leaders in banking and financial services: 75 percent already use AI agents, but only 12 percent of use cases reached production in the past year (Camunda, State of Agentic Orchestration and Automation 2026). Microsoft made multi-agent orchestration in Copilot Studio generally available in April 2026 and illustrates it with a bank: one agent for mortgages, one for account enquiries, and a customer who wants both answered in a single conversation (Microsoft, Copilot Studio blog). The vocabulary differs; the architecture behind it hardly does.

Four roles: router, planner, domain agents, reviewer

An orchestration layer built to last in a bank separates four roles, even if they run on the same platform.

• The router receives the request, recognises which cases it contains and assigns them to domains. It decides nothing on the merits. Its quality is how often it assigns correctly and how quickly it passes anything unclear to a person.

• The planner breaks the case into steps and fixes the order: check the complaint first, then the limit, because an open dispute affects the limit decision. It knows the policies but not the systems.

• The domain agents each execute one step, with a bounded mandate and their own tools: the card agent reads limits and transactions, the service agent the complaint history, the risk agent affordability. None sees more than it needs for its step.

• The reviewer is independent of the other three. It checks the result against policy, mandate and customer context before anything is executed or sent, and decides whether a person is brought in. Why this instance must be separate is argued in When AI Reviews AI.

Responsibilities towards core banking, CRM and CDP

The most common design error is giving the orchestration data it does not own. The layer owns no customer data, no accounts and no campaigns. It owns the case: who requested what and when, which steps were planned, which agents ran under which mandate, what the reviewer decided and which handovers took place. Everything else stays where it is. The core banking system remains the system of record for limits, balances and postings; the orchestration layer calls it through defined interfaces and never writes directly. The CRM remains the system for advisers and contacts; it receives tasks and outcomes from the orchestration, not the other way round. The CDP supplies customer context, state, consents and history, and receives outcomes back as events so the profile learns.

Barclays has implemented this separation in its client due diligence process: predefined processes enforce approvals, risk rules, deadlines and evidence; specialist agents handle variable work such as data collection, comparison and gap identification; the orchestration layer makes the sequence explicit, invokes agents within defined boundaries, routes exceptions to people and records evidence (Camunda blog on Barclays, July 2026). The bank can change the process without replacing every underlying system.

One customer, three cases, one handover

The following story is hypothetical. Kemal Aydın, 41, sends the message above from a café on Thursday evening. The router recognises three cases and assigns them to cards, service and travel. The planner puts the complaint first: the duplicate fee is unambiguous, two identical postings within four seconds, the service agent refunds within its 50-euro mandate, the reviewer confirms, the message goes out immediately. The limit is the harder part. The card agent proposes a temporary doubling; the risk agent reports an instalment loan taken out eight months ago. The reviewer stops: a limit increase with a running consumer loan lies outside the agent mandate and, under internal policy, requires an adviser decision. It hands over to Lea Vogt, a customer service adviser, with everything it has: the request, the travel date, the card agent's proposal, the risk agent's objection, twelve months of payment history without arrears.

Ms Vogt needs four minutes. She decides on a temporary increase of 60 percent until the return flight and has the customer sent a message that contains both: the refund and the new limit with its end date. Mr Aydın never spoke to four systems. The bank has an entry for every step, including why a person decided.

Observability: how to tell that the layer works

An orchestration layer you cannot observe is a black box with more parts. A technical vocabulary for this has emerged in 2026: OpenTelemetry's GenAI conventions define dedicated spans for invoke_agent, plan, execute_tool and invoke_workflow, so that a case becomes readable as one tree, from the router through every agent invocation down to the individual tool call (OpenTelemetry GenAI semantic conventions, explained by Dash0). The conventions still carry "Development" status; anyone adopting them today should record the version used.

More important than the format are the questions the trace must answer, for audit and business lines as well as developers: Which cases were in the request? Which policy did the reviewer apply? Why was it handed over, to whom, with what information, and how long did the person take? From these traces come the metrics for judging the layer: the share of correctly routed requests, the share of cases with a human handover, median time to decision with and without a person, and the share of agent proposals stopped by the reviewer along with the reasons. If the stop rate rises, the mandate is usually cut wrongly, not the agent poor.

Five takeaways

1. The AI orchestration layer owns the case, not the data: core banking, CRM and CDP remain systems of record, while the orchestration calls, distributes and records.

2. Four roles belong apart: router (assign), planner (sequence), domain agents (one step, one mandate) and an independent reviewer that decides before every execution.

3. Handovers to people are not a failure but part of the design; what matters is that the person takes over with all findings and that their decision is recorded.

4. EY, Camunda and Microsoft describe the same architecture in different words; Camunda's survey shows 75 percent of firms using agents but only 12 percent of cases in production.

5. Observability means every case is readable as a tree, and the traces yield metrics on routing, handovers, decision time and reviewer stops.

To check your own position, take a typical customer request with two concerns and follow it through the existing systems. Wherever the path breaks between two teams or tools, orchestration is missing today.

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.