The Thesis — Why Agentic Changes Everything
Section 1 of Agentic Banking Architecture: A Practitioner's Guide
Sixty Years of Banking Technology
Banking technology has gone through three eras, each defined by what was automated and how.
Era 1: Mechanisation (1960s–1990s). Banks moved paper processes into mainframes. Ledgers became databases. Manual calculations became batch jobs. The operating model didn't change - the same processes ran in the same sequence, just faster and with fewer errors. The architecture was simple: monolithic applications on centralised infrastructure, with humans operating them.
Era 2: Digitisation (2000s–2020s). The internet and mobile changed the channel, not the core. Most banks built digital interfaces on top of the same applications. Internet banking, mobile apps, APIs - all front-ends to the same batch-oriented, silo-based back-end. The architecture grew more complex: the core systems stayed, wrapped in middleware, integration layers, and API gateways. Each new channel added another layer of integration. The dominant cost shifted from building systems to connecting them.
Era 3: Agentic (2020s–). This is where the architecture changes, not just the interface. When AI agents can reason about goals, decompose them into steps, call tools, evaluate outcomes, and adjust - they do not need applications to contain business logic. They need services that provide data access, execution capabilities, and policy guardrails. The logic lives in the agent, not the application.
The Structural Shift
To understand why agentic is structural and not incremental, consider what an "application" actually is in banking today.
A lending system, for example, contains: credit assessment rules, pricing logic, approval workflows, document generation, regulatory reporting logic, customer communication templates, and the data model that holds it all together. It's a vertical silo - everything needed to run lending lives inside one system.
Now consider what an agent needs to perform the same lending process. It needs: access to customer data, access to credit bureau data, a set of credit policies expressed as prompts or rules, the ability to calculate pricing, the ability to generate documents, and the ability to record decisions. None of these need to live inside a single application. They are services that the agent calls.
The difference is where the orchestration lives. In Era 2, the application orchestrates. It decides what happens next, what rules apply, what data to fetch. In Era 3, the agent orchestrates. The application - if it still exists - is reduced to a data access layer.
This has three consequences that ripple through the entire technology stack.
Business logic becomes portable
When credit assessment rules live in an application, changing them means changing the application. When they live in agent policies - expressed as prompts and guardrails - they can be updated, versioned, tested, and deployed independently. The same policy can govern multiple agents across different products. Business logic becomes a first-class, managed asset rather than something embedded in code.
Integration complexity collapses
Banks spend a large part of their technology budget on integration - ETL pipelines, operational data stores, API layers, reconciliation processes, data warehouses. This complexity exists because data is duplicated across silos and needs to be kept in sync. When agents operate on shared data services rather than siloed applications, the need for most of this integration infrastructure disappears.
Applications dissolve
If business logic lives in agents and data lives in shared services, what's left in the application? A user interface and some CRUD operations. The application that was "the lending system" becomes a thin data service. Eventually, even that dissolves into a shared ledger layer. This is explored in detail in Section 4 and Section 5.
What Makes This Different From Previous Waves
Every few years, a new technology is proclaimed as transformational for banking. SOA was going to break the silos. Cloud was going to reduce costs. Microservices were going to enable agility. APIs were going to enable open banking. Each delivered real value, but none changed the fundamental pattern: vertical applications containing business logic, connected by integration.
Agentic AI is different because it attacks the root cause, not the symptoms. Previous waves tried to make integration better (SOA), cheaper (cloud), more granular (microservices), or more accessible (APIs). Agentic architecture makes most integration unnecessary by eliminating the data duplication and logic fragmentation that create the need for integration in the first place.
This doesn't mean it will be easy or fast. The transition will take years and will proceed through distinct phases (see Section 5: Migration Path). Legacy applications won't disappear overnight. But the direction is clear, and banks that understand the architectural endgame will make better decisions about where to invest today.
What This Guide Covers
The rest of this guide works through the architecture in detail. The reference architecture provides the map - a logical architecture for agentic banking. The governance architecture addresses how you govern agents in a regulated environment. The application architecture shows what happens to existing systems, and the migration path lays out how to get from here to there.
Subsequent sections cover the deterministic-to-probabilistic spectrum (which processes to migrate first), governance readiness (what you already have versus what you need to build), the people transformation, and the economics.
This section expands on ideas first published in Part 2 of the LinkedIn series on agentic banking architecture. The comment threads on that post and the broader series significantly shaped the thinking here.