Reference Architecture
Section 2 of Agentic Banking Architecture: A Practitioner's Guide
The Architecture at a Glance
The reference architecture has five horizontal layers — infrastructure, common services, data, business applications, and customer-facing agents — flanked by two vertical concerns: development agents on the left and observability and operations agents on the right. Across the top, a lifecycle runs from define through develop, deploy, and monitor.
This isn't a deployment diagram or a technology stack. It's a logical architecture — it describes what components need to exist and how they relate, not which products to buy or where to host them.
The Five Layers
Infrastructure
The foundation: compute, storage, networking, security, identity and access management, and LLM-as-a-Service. In an agentic architecture, the infrastructure layer needs to support model serving at scale, tool execution environments, and the observability pipelines that capture every agent decision. The infrastructure layer can be cloud-native or hybrid — the architecture is deliberately neutral on this point.
Common Services
This is a critical layer for the new agentic architecture. It contains the agent control plane (orchestration, lifecycle management, resource quotas), safety guardrails (hard limits that agents cannot override), and the shared capabilities that every agent needs: authentication, authorisation, logging, prompt management, and model routing.
The agent control plane is the single most important component in the architecture. It's where policies become executable, where agent behaviour is bounded, and where the organisation maintains control over what agents can and cannot do. Everything in Section 3: Governance depends on this layer.
Data
Shared data services replace siloed application databases. Ledgers (golden source, immutable, auditable), vector stores for retrieval-augmented generation, and the operational data layer that agents read from and write to. Agents naturally access these data sources through services, not through direct database connections. This enables access control, audit trails, and data governance at the service boundary.
Business Applications and Agents
This layer is where the difference with today's architecture is most visible. Today's layer is populated by vertical applications — lending, payments, treasury, CRM etc. In the target state, business logic lives in agents that orchestrate across shared data and common services. The applications that remain are thin data access layers, gradually dissolving (see Section 4).
Customer Agents
The top layer: agents that interact directly with customers - or customers' own agents. This is where open banking, embedded finance, and agent-to-agent protocols converge. A customer's financial agent negotiates with the bank's lending agent — no human interfaces required for routine interactions.
The Vertical Concerns
Development Agents (Left)
Agents that build the system: code generation, test automation, deployment, infrastructure provisioning. These operate across all five horizontal layers. In a mature agentic architecture, development agents generate the code and configuration that production agents execute — creating a recursive loop where agents build and improve agents.
Observability and Operations Agents (Right)
Agents that monitor and maintain the system: incident triage, performance tuning, security monitoring, drift detection, SRE automation. These agents watch the production agents and the infrastructure they run on, feeding findings back to development agents and human operators.
The Lifecycle: Define → Develop → Deploy → Monitor
Across the top of the architecture, a horizontal lifecycle governs how everything moves from concept to production. Standards and policies are defined (including agent policies codified as prompts). Development agents build and test. Deployment is automated and governed. Monitoring is continuous and feeds back into the definition layer.
This lifecycle is not new — it maps to existing SDLC and DevOps practices. What's new is that the artefacts flowing through it include agent definitions, prompt versions, and policy configurations alongside traditional code and infrastructure.
What's Deliberately Missing
The reference architecture does not prescribe: specific vendors or products, cloud providers, programming languages, LLM providers, or orchestration frameworks. These are implementation choices that depend on each bank's context, existing investments, and regulatory constraints. The architecture is the set of capabilities you need; the implementation is how you build them.
One dimension that was raised in early discussions and deserves future treatment: the external ecosystem. Partner agents, marketplace integration, cross-bank agent protocols, and regulatory reporting agents. These sit at the boundary of the architecture and will become increasingly important as adoption matures.
This section expands on ideas first published in Part 1 of the LinkedIn series on agentic banking architecture, which generated significant discussion on governance, adversarial assurance, agent identity, and inter-agent communication — themes addressed in subsequent sections of this guide.