1. From Monolith to Multi-Agent — Why One AI Is Not Enough for Regulated Finance

---

🩤 The Single-Agent Trap

The most common starting point for AI-powered banking applications is also the most dangerous one: a single large language model that receives a customer request and produces a decision. It seems elegant. The customer asks: “Am I eligible for a home finance product?” The model checks their income, verifies compliance with religious finance principles, assesses risk, and returns an answer. One model. One prompt. One response.

The problem emerges the moment a regulator asks: “How did you arrive at that decision?”

With a monolithic agent, the honest answer is: “The model reasoned about it.” That answer does not satisfy an auditor. It does not satisfy a compliance officer. And it does not satisfy a Sharia board. In regulated finance, every decision must be decomposable — traceable to a specific rule, a specific policy, and a specific named actor responsible for that rule.

The accountability gap is not the only problem. There is also a fairness gap. When a single model simultaneously handles credit scoring, Sharia compliance, and risk assessment, it is impossible to verify that each of those three concerns is being evaluated by the appropriate standard, with the appropriate oversight, against the appropriate data. A credit decision that is unfair to a specific customer segment might be correct from a Sharia perspective and vice versa. Entangling multiple governance concerns in a single model output makes it impossible to audit any of them cleanly.

There is a third problem beyond accountability and fairness: conflicting objectives that require independent governance paths. A credit decision involves at least three genuinely independent concerns — financial risk (will the customer repay?), religious compliance (does the product structure meet Sharia principles?), and regulatory risk (does the transaction flag any sanctions or concentration limits?). These concerns require different expertise, different data sources, and different governing bodies. Forcing a single model to balance all three simultaneously is not just architecturally messy — it produces decisions that cannot be appealed, corrected, or reviewed in parts.

Back to top . Next: Why Regulated Finance Forces Separation

---

🏛️ Why Regulated Finance Forces Separation

Banking is one of the most heavily regulated industries on earth. Every major financial jurisdiction has model risk management guidelines — the US Federal Reserve’s SR 11-7, the UAE Central Bank’s CBUAE Model Risk Guidelines, the Saudi Arabian Monetary Authority’s SAMA AI and ML Governance 2024 framework. They all share a common thread: model risk management (MRM) requires knowing exactly what each component of a decision system does, who is responsible for it, and what happens when it fails.

This has profound architectural implications. It means the architecture must be designed to answer these regulatory questions from its structure, not from its logs:

• Separation of duties: The component that checks Sharia compliance must not be the component that decides credit eligibility. In traditional banking, these are different teams with different sign-off authority. In AI banking, they must be different agents with different governance oversight bodies.
• Independent auditability: A regulator must be able to examine the Sharia decision in isolation from the credit decision. If they are entangled in one model output, this is not just difficult — it is structurally impossible.
• Targeted retraining: If the credit scoring model drifts, you retrain the credit agent — not the entire system. With a monolith, every model change touches every governance domain simultaneously, making impact assessment impossible.
• Governance by component: The Sharia Board reviews the Sharia agent. The Risk Committee reviews the Risk agent. Regulators review the Orchestrator. Each governing body has a clear, bounded scope. Accountability is not shared ambiguously across the whole system.
• Fairness by domain: Bias monitoring can only be meaningful when applied to a specific decision with specific inputs and a specific outcome. A component that mixes credit, Sharia, and risk decisions cannot be subjected to a meaningful disparate impact analysis.

There is also an Islamic finance-specific dimension. Sharia compliance in finance is not a checkbox — it is a continuous jurisprudential assessment. Novel product structures may have no existing fatwa (religious ruling). A human Sharia scholar may need to be consulted. This kind of domain-specific escalation path — where a novel structure is flagged as requiring Board review before proceeding — cannot be expressed inside a general-purpose credit decision model. It requires its own agent, with its own knowledge base, its own escalation path, and its own governing body oversight.

Back to top . Next: The Five-Agent Architecture

---

🏗️ The Five-Agent Architecture

The platform uses five specialised agents, each owning a single bounded governance domain. No agent does the work of another. Each can be governed, audited, updated, and if necessary, suspended independently. The number five is not arbitrary — it maps directly to the five governance domains that a regulated bank must report on separately.

Agent	Domain	Key responsibility	Governing body
Orchestrator Agent	Workflow coordination	Receives customer request, dispatches to specialist agents, assembles final decision, handles Human-in-the-Loop escalation when any specialist flags uncertainty or a high-risk threshold	Operations / Platform team
Credit Agent	Financial eligibility	Computes debt-burden ratio (DBR), retrieves credit score from the Gold data layer, determines Murabaha eligibility by deterministic gate — never by LLM reasoning alone	Credit Risk Committee
Sharia Agent	Religious compliance	Validates product structure against AAOIFI Sharia principles, retrieves relevant fatwas via vector search, flags novel structures for Board escalation before any automated approval	Sharia Supervisory Board
Risk Agent	Multi-dimensional risk	Assesses seven risk dimensions: DBR, concentration, market exposure, liquidity, operational, country, and FX risk — each domain maps to a regulatory reporting requirement	Risk Management Committee
Simulation Agent	Scenario modelling	Models what-if scenarios: rate changes, tenure variations, stress scenarios for portfolio exposure — produces projections, never decisions	Treasury / Modelling team

Each agent is a completely independent service — its own Docker container, its own Python process, its own API endpoint, its own configuration, its own prompt templates. They share no in-process state. They communicate only through well-defined interfaces. The independence is not just technical. It is the structural expression of the principle that each governance domain has a clear owner who cannot be bypassed by another domain’s logic.

Back to top . Next: The MCP Server

---

🔧 The MCP Server: Shared Tools, Not Shared Logic

The five agents need access to common capabilities: credit score lookups from the data pipeline, vector search across the Sharia knowledge base, OPA policy enforcement, PII masking before any LLM call. The naive approach puts these capabilities inside each agent. The correct approach puts them in a single shared service — the Model Context Protocol (MCP) server — where they can be governed once and enforced everywhere.

The MCP server is not an agent. It has no reasoning capability. It is a tool execution layer — a catalogue of named functions that agents can invoke. Think of it as the banking platform’s internal API, purpose-built for AI agent consumption. The governance significance is in what centralisation enables:

• Observation: Without a shared tool layer, each agent would implement its own credit score lookup, its own vector search client, its own OPA policy check. When the credit scoring logic changes, you update five places instead of one. When one of those five implementations diverges, you have five different definitions of “what the credit score means” operating simultaneously.
• Reasoning: Centralising tool execution means centralising tool governance. Rate limits, access controls, audit logging, PII masking — apply once in the MCP server and they apply to every agent that calls it. Controls enforced at a shared boundary are structurally mandatory. Controls inside individual business logic are structurally optional. This distinction is the difference between security by design and security by hope.
• Action: Every shared capability lives in the MCP server. Agents call tools; they do not reimplement them. Every tool call is logged with the calling agent’s identity, the arguments passed, and the result returned. This is the tool-level audit trail that regulators need but that function-call-based architectures cannot provide.

The MCP server exposes tools including: credit_score (retrieves real scores from the Gold data layer, not heuristics), vector_search (semantic search across Sharia fatwas, product catalogue, and customer profiles), sharia_validate (OPA policy enforcement for Sharia structural rules), and pii_mask (Presidio-based data masking before any content reaches an LLM). The pii_mask tool is particularly important: it is available to agents, but it is also enforced as middleware — meaning no tool result that contains PII can be returned to an agent without first passing through the masking layer. Privacy protection is not something an agent opts into. It is something the shared boundary enforces before the agent ever sees the data.

Back to top . Next: The A2A Protocol

---

🤝 The A2A Protocol: Agents Talking to Agents

When the Orchestrator needs a Sharia compliance verdict, it does not call an internal function. It sends an HTTP request to the Sharia Agent’s API endpoint. This is the Agent-to-Agent (A2A) protocol — and the distinction from a simple function call matters enormously for accountability, security, and the independent deployability of each governance domain.

Each agent exposes a standardised discovery endpoint at /.well-known/agent.json. This endpoint returns an Agent Card — a machine-readable description of who the agent is, what skills it offers, what protocol version it speaks, and what its autonomy tier is. Any agent, monitoring system, or human operator can discover another agent’s capabilities at runtime without hardcoded knowledge.

This produces three concrete benefits in a regulated environment:

• Accountability of inter-agent calls: Every A2A call is a network request — it has a timestamp, a request ID, authentication headers, and a response code. The audit trail is structural. With in-process function calls, you have to instrument manually and trust that nobody removes the instrumentation. With A2A, the network boundary is the audit instrument.
• Independent deployment: The Sharia Agent can be updated, restarted, or suspended without touching the Orchestrator. The Orchestrator discovers the current Sharia Agent from the registry and calls its current API. A governance-driven update to Sharia logic does not require an Orchestrator deployment, which means the Sharia Board’s changes stay within the Sharia domain.
• Security boundaries that enforce governance: Inter-agent communication is secured at the network boundary — OpenBao authentication tokens per agent, replay protection via HMAC-signed timestamps, and a lateral movement guard that rejects calls from agents that are not in the permitted caller list. A simulation agent cannot call a credit tool. A credit agent cannot call the Sharia agent directly. The governance boundaries are enforced by the network layer, not by developer discipline.

The A2A protocol also enables autonomy tier enforcement. An agent registered as SUPERVISED is one whose decisions must have human review before they are acted upon. An agent registered as FULL can act autonomously within its governance boundaries. These tiers are not labels in a database — they are gates enforced by the OPA policy layer that physically block unsupervised action when the tier requires review. The autonomy tier is a transparency instrument: it makes the system’s level of human oversight visible and auditable at any moment.

Back to top . Next: Bounded Context in Practice

---

📦 Bounded Context in Practice

Domain-driven design’s concept of a bounded context — a clear boundary around a subdomain with its own language, data model, and rules — maps directly onto this agent architecture. Each agent owns its bounded context completely. Nothing outside that boundary can alter how the domain’s rules are applied.

What does this look like concretely? The Credit Agent owns the concept of “eligibility.” Inside the Credit Agent, eligibility means: debt-burden ratio below 45%, credit score above the defined threshold, no active delinquency flag. Outside the Credit Agent, eligibility is just a boolean in the Orchestrator’s state. The Orchestrator does not know how eligibility is computed — and that ignorance is the architecture working correctly.

The Sharia Agent owns the concept of “compliance.” It has its own fatwa knowledge base, its own compliance rules, its own escalation path to the Sharia Board. The Credit Agent does not know what makes a product Sharia-compliant — and it cannot be made to behave as if it does, because the Sharia domain is physically isolated in a separate process.

This separation produces a counterintuitive result: the system as a whole becomes more transparent and more explainable as complexity increases, not less. Adding a new risk domain to the Risk Agent does not affect the explainability of the Credit Agent. Adding a new fatwa to the Sharia knowledge base does not affect the credit scoring logic. Each bounded context can be explained, governed, and audited in isolation. The complexity is bounded by the context, not accumulated across the whole system.

Technology — Orchestration and Communication

Back to top . Next: What We Learned

---

💡 What We Learned Building This

The architecture described above sounds clean on paper. The reality of building it was messier — and the gaps between the architecture diagram and working behaviour were where the real governance lessons lived. These are not abstract lessons. They are incidents that required rework.

Declaration is not implementation. An agent can be declared in a docker-compose file, have its API endpoint defined, and appear in the service registry — and still not work end-to-end. The Sharia Agent existed for weeks before we verified that its OPA policy check was actually enforced on incoming requests, not just wired into one internal node. The agent existed. The governance did not. Every integration point — especially every security and compliance integration — needs explicit end-to-end verification, not just code existence.

The vendor-neutral LLM caller is a transparency requirement, not just a convenience. Early versions used a popular LangChain provider package for LLM calls. This created a hidden dependency: the provider’s interface, its error handling, its retry behaviour, its logging — all controlled by a third party we could not audit. We replaced it with a single call_llm() function — a plain HTTP POST using the standard OpenAI-compatible API format. Every token that goes into the LLM and every token that comes out is visible in the Langfuse trace. That observability is only possible because the call is a direct, unmediated HTTP request, not a black-box library invocation.

Prompts belong in versioned files, not in Python code. The first version had prompt strings scattered across Python files. Changing a prompt required finding it in code, testing the change, and deploying a new container. A prompt is the system’s voice in a regulated financial decision. It deserves the same governance treatment as any other code change: version control, peer review, audit trail. Moving every prompt to YAML files made prompt changes reviewable, comparable across versions, and rollback-able independently of the code that uses them.

The license audit is a compliance gate, not a legal nicety. Before writing a line of application code, we audited every dependency for commercial licensing acceptability and data sovereignty implications. Redis: Business Source License 1.1 after March 2024 — vendor-controlled terms, replaced with Valkey. HashiCorp Vault: BSL 1.1 after August 2023 — same concern, replaced with OpenBao. ChromaDB: operational maturity gaps for production banking, replaced with Qdrant. Groq API: customer financial data would leave the bank’s infrastructure in LLM prompts — replaced with Ollama for sensitive inference. A dependency whose terms are controlled by a vendor’s quarterly business decision is a dependency whose compliance posture can change without your knowledge or consent. This is covered in depth in S1-A4.

Back to top . Next: Key Takeaways

---

---