The Five-Agent Model — Why One AI Doesn't Run a Bank | CoreFi

When boards ask vendors "what is your AI strategy?" the polite answer is usually: a single model behind a chat interface, with prompt engineering and a few tools attached.

That model can write a serviceable customer email. It cannot run a bank.

This article explains why the architectural unit of agentic banking is not an agent but a system of agents — and how CoreFi has converged on a five-agent model that mirrors how banks actually divide work today.

The "one big agent" trap

The intuitive design — one large, capable model that does everything — fails in regulated finance for three reasons.

1. Conflicting incentives inside one model.

A single agent asked to "be helpful to the customer" and "protect the bank against fraud" and "stay within regulatory limits" will trade those off implicitly, in ways no one can audit. In a bank, those tensions are deliberately separated: the front office wants to lend, the risk function wants to not lose money, compliance wants to not lose the license. Collapsing them into one agent doesn't resolve the tension — it hides it.

2. Audit boundaries become impossible.

When a single model both advised the customer to take a loan, underwrote it and monitored it for fraud, the regulator's first question is "show me the segregation of duties." There isn't any. With a single agent, you cannot demonstrate that the lending decision was independent of the customer-facing recommendation.

3. Failure modes are unbounded.

A failure in one prompt or one tool call propagates across every workflow the agent touches. There is no blast-radius containment. When a single agent is responsible for everything, a regression in one capability degrades all of them simultaneously.

This is why agentic banking, done seriously, looks more like a microservice architecture than a chat interface — with specialized agents, narrow scopes, and explicit handoffs between them.

The five-agent model

After working through these patterns with banks, EMIs and licensed lenders, we converged on a five-agent reference model. It is not the only valid decomposition, but it maps closely to how the org chart already works.

1. The Customer Agent

Scope. Inbound customer interaction across all channels: chat, voice, app, partner-embedded surfaces. Onboarding, account questions, product discovery, complaint intake.

What it cannot do. Approve a loan. Override a fraud hold. Disburse funds. Change a customer's risk classification. These actions require a handoff to another agent — and a human, where the policy says so.

Why it's separate. The Customer Agent is optimized for tone, latency and recovery from misunderstanding. Those optimizations actively conflict with the precision and conservatism a Risk Agent needs.

2. The Operations Agent

Scope. Everything that happens to the ledger from inside the bank — reconciliation, batch processing, exception handling, payment routing, settlement, document processing.

What it cannot do. Make a credit decision. Authorize the release of a hold. Issue a regulatory report. Authorization for those actions sits with Risk, Compliance and (often) a human.

Why it's separate. Operations agents work against well-defined process flows with clear inputs and outputs. They benefit from being deterministic, audited and replayable. That posture is the opposite of a customer-facing agent's posture.

3. The Risk Agent

Scope. Credit decisioning, fraud detection, scoring, portfolio monitoring, model risk management. Anything where the question is "should we take this exposure?"

What it cannot do. Talk directly to customers. Approve compliance-binding actions like sanctions screening conclusions. Modify the ledger directly — it can only recommend.

Why it's separate. Risk decisions need a controlled feature set, model cards, explainability artefacts, and a clear audit trail of which model version made which decision under which inputs. Embedding risk inside a customer agent destroys all of that.

The Risk Agent is also the most heavily regulated agent in the five — under the EU AI Act, automated credit decisioning typically falls into the high-risk classification. We cover that in AI Governance in Lending — What Regulators Actually Expect.

4. The Compliance Agent

Scope. AML transaction monitoring, sanctions screening, KYC refresh, suspicious-activity workflow, regulatory reporting (CRS, FATCA, MiCA disclosures, DORA incident reporting).

What it cannot do. Make commercial decisions. Override a customer-facing flow without a documented compliance reason. Approve its own decisions — high-impact actions go to a human reviewer.

Why it's separate. Compliance is the agent whose worst failure mode is the most expensive: a missed sanctions hit is regulatory exposure that no amount of revenue offsets. The Compliance Agent runs on stricter rules, narrower tools, and a more conservative escalation policy than any other agent in the stack.

5. The Treasury Agent

Scope. Liquidity management, intraday positioning, FX, settlement risk, internal funding. Where the bank's own balance sheet lives.

What it cannot do. Touch customer-facing flows. Take credit or compliance decisions. It operates entirely on internal positions.

Why it's separate. Treasury runs on data the rest of the agents shouldn't see (full balance-sheet positions, intraday liquidity), and its tolerance for latency and risk is completely different from any other agent. Mixing it into a generalist agent leaks privileged information into customer-facing surfaces.

How they coordinate

The five agents are not five chatbots in a row. They are coordinated by an orchestration layer that does three things:

• Routes intent. A customer message asking about loan eligibility is not handled by the Customer Agent alone — it is enriched by the Risk Agent's pre-screening, and the Compliance Agent's KYC freshness check, before the Customer Agent responds.
• Enforces handoffs. When the Customer Agent reaches the boundary of its authority — for example, the customer asks to release a fraud hold — orchestration creates a structured request to the Risk Agent (and, where required, a human). The Customer Agent cannot bypass this.
• Captures the audit trail. Every handoff is logged with the inputs, outputs, model versions, and time-stamps. That ledger is what makes the system explainable to a regulator.

Architecturally, this looks much more like a well-designed event-driven system than a single LLM with tools.

Why five — and not three, or fifteen

We tested simpler decompositions (a single "front office" agent and a single "back office" agent) and richer ones (an agent per product line). Five turned out to be the smallest number that:

• Maps cleanly to existing org-chart accountability (each agent has a clear human owner: COO, CRO, CCO, Treasurer, Chief Customer Officer)
• Aligns with regulatory expectations for segregation of duties under DORA and the EU AI Act
• Leaves enough boundary for the orchestration layer to enforce, rather than dissolving into a soup

Banks with very specialized businesses sometimes add a sixth — a Markets Agent, or a Wealth Agent. The principle is the same: specialization is what makes the system auditable.

What this means for the buyer

If you're evaluating an agentic banking platform, the questions to ask are not "how smart is your AI?" but:

1. What is the agent topology? A single agent answer is a yellow flag.
2. How are handoffs enforced? If the answer is "the LLM decides," that's not enforcement.
3. What is the human-in-the-loop policy per agent? Not "we have human review" — which actions, in which agent, require which human role.
4. How does the audit trail capture cross-agent decisions? Per-agent logging is necessary but not sufficient. You need the orchestration log.
5. Which agents are EU AI Act high-risk classified, and what evidence supports that?

If a vendor cannot answer those five, they are selling you a chatbot in production clothing.

The CoreFi position

CoreFi is built around the five-agent model. The platform is architected around Customer, Operations, Risk, Compliance and Treasury agents, each scoped to its domain — plus the orchestration layer that coordinates them, and an audit pipeline designed to evidence the system to a regulator. Each agent is independently configurable, model-agnostic by design, and bounded by an explicit tool and authority manifest.

We didn't arrive at five agents from a whiteboard. We arrived at them by being the bank, and then realizing the architecture had to match.

Want the full architecture diagram? See the CoreFi architecture.