AI & Banking

The Orchestration Layer: Domain Agents with a Bounded Mandate, Humans with Direction

Part 5/5: Three domain agents, an autonomy matrix, six jobs of orchestration and two runtimes. Why the bounded mandate is the basic unit.

•

acceleraid Editorial Team

•

8 min read

Two-storey bank building in cross-section: downstairs three friendly robot helpers at their own desks in roped-off lanes, between them a conductor on a podium with a baton and a large lever; upstairs two people at the window with a compass on the table

Series Agentic Experience Platform for Banks · Part 5 of 5. The lead article describes the five layers, Part 4 the activation. This part closes the series with the layer that coordinates and limits agents.

The idea of the one agent that can do everything is not just unrealistic in banks, it is impermissible. An agent that builds segments, sends offers, answers service cases and adjusts models has no auditable mandate, and what has no auditable mandate can be neither approved nor supervised. The orchestration layer of the Acceleraid platform takes the opposite route: several domain agents, each with a bounded mandate, permitted tools, stop criteria and a defined handover to people. This layer coordinates, logs and stops. Humans set the direction.

Why the bounded mandate is the basic unit

Treasure AI describes its agent layer as domain agents that run analyses and campaigns, and reports that a segmentation task which used to take three days is now completed in about 60 seconds (Treasure AI). These are vendor figures, but they show what matters: speed comes from specialisation. An agent that does one task well is faster and more auditable than one that does ten tasks indifferently.

Security research reaches the same conclusion from the opposite direction. The OWASP list of the ten most important risks for agentic applications in 2026 opens with goal hijack, in which an agent is diverted from its mandate by manipulated inputs, and tool misuse, in which it uses legitimate tools for unintended purposes. Microsoft sums up the consequence in one sentence: agents should be treated as managed, auditable applications, not as unmanaged automation (Microsoft Security). Both risks shrink the narrower the mandate and the shorter the tool list of an agent. The bounded mandate is therefore not a precaution but the basic unit of the architecture.

Three domain agents, one mandate each

We describe the orchestration layer through three domain agents. Their scope is provisional and will be aligned with the current state of our work on this layer; the structure of each agent is not.


Three domain agents marketing, service and analytics, each with mandate, tools, stop criteria and handover, above them the line Humans set the direction, below them the orchestration layer

The marketing agent prepares segments and offers but never sends anything itself. Its tools are read context, create proposal, trigger check. It stops when suitability is missing, the contact budget is exhausted or the prediction's uncertainty is too high. The handover reads: the business releases the campaign. The service agent classifies cases, suggests notices and hands over cases. Its tools are read service case, retrieve context, draft notice. It stops on a complaint, suspected fraud or a recognisably emotional situation. The handover reads: an employee takes over the dialogue. The analytics agent answers questions from the business, flags anomalies and changes nothing. Its tools are read access, visualisation and report. It stops as soon as it would need personal raw data outside the purpose. The handover reads: the business decides on the measure.

Each of these agents thus has four components that exist in writing before its first deployment: mandate, tools, stop criteria, handover. What is not in these four points, the agent may not do. This inversion, permitted is what is listed, distinguishes a domain agent from an assistant with general access.

Autonomy per task, not per agent

The most common misconception about agents is that autonomy is a property of the agent. In a bank it is a property of the task. The same marketing agent may build a segment entirely on its own, trigger a notice within the contact budget on its own, but deliver an offer only with approval and make no credit decision at all. We distinguish four levels: prepare, suggest, execute within limit, execute with approval.


Table task by autonomy level with seven tasks from build segment to adjust model and four levels prepare, suggest, execute within limit, execute with approval; filled dots mark permitted levels

The classification is a proposal for discussion with business and compliance, not a standard. Three properties are the same in every variant, though. First, every level produces the same log entry; the difference lies in the approval, not in traceability. Second, every level can be withdrawn at any time, for a task, for an agent or for all. Third, there are tasks for which the highest level is not intended, such as the credit decision, where the person decides and the agent prepares. For such high-risk applications the AI Act requires human oversight and retention of logs in any case (EU AI Act, Article 26); the autonomy matrix makes visible where that obligation bites in practice.

Gartner justified its forecast that more than 40 percent of agentic AI projects will be cancelled by the end of 2027 partly with inadequate risk controls (Gartner). The autonomy matrix is the risk control missing from those projects: not a ban, but a setting per task that can change as experience accumulates.

What the orchestration layer itself does

Between the agents sits the layer that gives them their name. It has six jobs. It sets the sequence in which agents work on a case, for instance that the service agent classifies a case before the marketing agent is asked at all. It clarifies responsibility, so that two agents do not approach the same customer. It sets rules between agents, for example that a notice from the service agent blocks any offer from the marketing agent for seven days. It monitors time and resource limits, so that an agent does not retrieve context or call tools endlessly. It keeps the agent log, which records every mandate, every tool call, every stop and every handover. And it keeps the safe stop ready: for one agent, for one task, for everything.

Take the example that has accompanied the series, hypothetical as before: a customer's salary credit does not arrive, three weeks after a service case. The orchestration layer gives the case first to the service agent, which classifies it as a possible emergency and suggests a notice via the adviser. With that classification, the layer sets a seven-day block for the marketing agent, which had the customer on a proposal list anyway because of her credit affinity. The analytics agent sees the case only as an anonymised count in its weekly overview of missing salary credits. All three steps are in the agent log, including the block that never leads to a visible action. Whoever later asks why the customer received no offer that week finds the answer there.

This stop is more than a switch, as we set out in our piece on the kill switch. A stopped agent has to leave its case in a defined state, open handovers have to reach people, and running activations have to be retractable. That presupposes that the orchestration layer knows at every moment which agent is working on which case at which stage. That is exactly what the agent log is for.

Two runtimes, six connections

A particular feature of the Acceleraid architecture is that the platform and the Acceleraid AI Assistant remain separate runtimes. The assistant conducts the customer dialogue in app, web and phone, has its own agents with a bounded mandate and its own logging. The platform holds context, decision, activation and orchestration. The two are connected not through a shared database but through six defined connections.


Two columns Acceleraid platform and Acceleraid AI Assistant, between them six connections brain contracts, APIs, events, identity, policy and audit with double arrows

Brain contracts define what the assistant may ask and what it gets back. APIs allow reading context and handing over decision records. Events bring signals from the dialogue back into the collect step. Identity ensures that both sides mean the same person in the same role with the same purpose. Policy means one policy with two enforcement points, not two policies. Audit keeps one log across both runtimes. Every connection is versioned and auditable, and each runtime can be operated, audited and replaced on its own.

That this separation is no end in itself is shown by the supervisory view. In October 2025 the Financial Stability Board published a report on monitoring AI adoption in the financial sector that builds on its work on third-party dependencies and gives authorities guidance on closing data gaps in their monitoring (FSB). A bank that runs dialogue system and decision platform separately and connects them through defined interfaces can account for, audit and replace each component individually. A bank with a monolithic agent cannot.

Organisational readiness before technical readiness

In June 2026 the Euro Banking Association, in a report by its Open Finance working group, collected more than 40 use cases for agentic AI in embedded finance and shortlisted five with high potential; the working group's chair stresses that organisational readiness will strongly determine the pace and success of adoption (Financial IT). For the orchestration layer that means in concrete terms: before the first domain agent runs, mandate, tools, stop criteria and handover have to exist in writing for every agent, the autonomy matrix has to be agreed with business and compliance, and the safe stop has to be tested. None of these prerequisites is software. All three are decisions made by people, and that is why the line above the architecture reads: humans set the direction.

The series in review

Five layers, one governance track, one loop with six steps. The context has to exist first, then the decision with its record, then the activation with its way back, then the orchestration with its limits. The operating model of customer lifecycle management and customer value management provides the frame. An agentic experience platform is the operating form in which all of this runs faster than before, within the limits a bank has to observe anyway.


Overview of the series: lead article and five parts from CLM and CVM to the orchestration layer

Five takeaways

  1. The basic unit of orchestration is the bounded mandate: mandate, tools, stop criteria and handover exist in writing before the first deployment; permitted is what is listed.

  2. Autonomy is a property of the task, not of the agent; the matrix of task and level is the risk control that failed projects lack.

  3. The orchestration layer sets sequence, responsibility, rules between agents and limits, keeps the agent log and holds the safe stop ready.

  4. Platform and Acceleraid AI Assistant remain separate runtimes with six defined connections; each component can be audited and replaced individually.

  5. Organisational readiness precedes technical readiness; the decisions made before the first agent are made by people.

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.