The AI agent, one year later: a 2026 architecture - and where it actually plugs into a banking platform

A year is a geological era in agentic AI. Twelve months ago, a typical “AI agent platform” diagram (we're looking at one from mid-2025 as we write this) put a vector database at the center, treated agents as a sub-box inside an “AI layer,” wired every tool integration by hand, ran monitoring as four dashboards (cost, usage, data, LLM), and handled deployment as classic CI/CD with prompts as an afterthought.

None of that was wrong. All of it has aged. Here is what a production agent looks like in mid-2026, why the changes happened, and — the part most architecture posts skip — how this actually lands inside a realistic digital banking platform, batch core, ESB and all.

What changed in twelve months

Three shifts explain almost everything in the new picture.

Tool access standardized. The Model Context Protocol, introduced by Anthropic in November 2024, became the de-facto way agents connect to tools and data — adopted across OpenAI, Google, Microsoft and AWS, donated to the Linux Foundation's Agentic AI Foundation in December 2025, and running at roughly 97 million monthly SDK downloads. By mid-2026, surveys put 78% of enterprise AI teams with MCP-backed agents in production. The November 2025 spec revision added what enterprises were waiting for: asynchronous long-running tasks, formal server identity, and structured audit trails. The consequence for architecture: integration stopped being the diagram's hero. You no longer draw bespoke pipes; you draw one protocol and a governed registry of tools behind it. For multi-agent coordination, a second protocol — Google's A2A, also now under Linux Foundation governance — handles agent-to-agent work, and the emerging consensus is a layered stack: MCP gives an agent its hands, A2A lets a team of agents coordinate.

Retrieval got demoted — deliberately. The 2025 diagram's center of gravity (landing zone → chunking → vectorize → vector DB → knowledge API) is now one tool among several that the agent may call. Production agents in 2026 answer more questions by calling governed business APIs and querying the data platform directly — under the same access controls a human gets — than by semantic search over embeddings. Retrieval still matters; it just isn't the architecture. The clearest signal is who operates managed MCP surfaces now: the data platforms themselves, exposing governed query tools so agents inherit the platform's ACLs rather than bypassing them via an exported vector copy.

Identity and governance became architecture, not policy documents. This is the biggest cultural change. Agents authenticate, hold credentials, and act — which makes each one a privileged non-human identity, and the numbers around that are uncomfortable: a Cloud Security Alliance survey found 68% of organizations cannot reliably distinguish AI-agent activity from human activity, and the Gravitee 2026 agent-security report found 45.6% of practitioners using shared API keys for agent authentication. Traditional IAM assumed deterministic software with predictable access patterns; agents make runtime decisions about what to touch, so credentials cannot be fully pre-scoped. The pattern the industry converged on — variously called blended identity — gives each agent instance a verifiable identity of its own, tied to but distinct from the human it acts for, with short-lived task-scoped credentials issued at runtime and least-privilege enforced at the point of access. NIST launched an AI Agent Standards Initiative in February 2026 covering exactly this identity-and-authorization ground.

If your agent architecture still shows a service account, it is a 2024 diagram wearing a 2026 title.

The 2026 anatomy

Walk the companion diagram above and the shape is: a durable agent runtime at the center — a reasoning loop (plan → act → observe → reflect) with bounded steps and budget caps, context assembly, session and long-term memory, an explicit task lifecycle for long-running, resumable, idempotent work, and optional sub-agent delegation via A2A. Below it, a model gateway: frontier models, small/local models for classification and PII handling, embeddings — all routable and, crucially, interchangeable. The model is the most replaceable component in the stack; the runtime, tools, policies, and evidence are what you actually own.

To the right, the tool plane: an MCP client with a per-agent allowlist, in front of governed tools — business APIs (with read/propose/execute scopes), retrieval, the data platform, a code sandbox with no production credentials, vetted SaaS servers — all admitted through a private MCP registry with schema review, security scanning, and approval workflow. That registry is not bureaucratic decoration: independent scans found a majority of public MCP servers carry exploitable risk, and only a small fraction use OAuth by default. In an enterprise, “we installed an MCP server from the internet” must be as impossible as “we npm-installed into the core banking system.”

Wrapped around everything, three planes the 2025 diagram lacked: policy and gates (input/output guardrails, a pre-action policy engine, and human approval gates as first-class infrastructure for consequential actions), agent identity (per-instance identity, JIT credentials, on-behalf-of user context — every action attributable to agent and human), and evidence (step-level traces, a tamper-evident log of intent, approval, action, and result, an eval harness wired into CI/CD as a merge gate, and cost/runaway controls with a kill switch). Monitoring grew up into evidence: dashboards tell you what happened; an evidence log lets you prove it to an auditor — which, under FINMA's Guidance 08/2024 expectations of inventory, documentation and explainability, is the difference between a pilot and a production system in a Swiss financial institution.

The realistic banking platform

Reference architectures love to draw the ideal bank. Real platforms look like the diagram above: channels (mobile, e-banking, advisor workplace, call center) over BFFs and an API gateway; a digital services layer of mixed vintage — a 2022 payments microservice next to a 2014 cards module inside a monolith next to a vendor KYC suite; an integration layer where the 2009 SOAP ESB is still load-bearing while Kafka carries only the newer flows; systems of record with a batch-oriented core (Avaloq/Finnova class, nightly GL close), payment rails, CRM, screening engines, a document archive; and a data landscape where the legacy DWH still owns regulatory reporting while the lakehouse runs analytics beside it. This coexistence is not a failure state. It is what “running a bank while modernizing it” looks like — and it is the terrain agents must actually live in.

Agents attach in four places:

• As another client behind the API gateway — south-bound calls, under OAuth and rate limits like everyone else.
• Through a new MCP tool façade in the integration layer — wrapping selected APIs and ESB services as governed, schema'd tools.
• As event consumers on the bus — for trigger-driven work.
• Through IAM federation — the agent identity broker extending, not replacing, the existing identity stack.

What's good enough already

An honest assessment — because “rebuild everything for AI” is vendor talk, not architecture:

• The API gateway and BFF layer. Agents are just another client. OAuth2/OIDC, throttling, WAF — the front door was built for untrusted callers and needs configuration, not reconstruction.
• The event backbone. Where Kafka exists, agent triggers and result events ride it natively.
• Lakehouse governance, if you have it. A governed data platform means agents query under the same ACLs as humans — precisely the pattern the managed-MCP data platforms now productize.
• Observability plumbing. Your tracing and SIEM stack ingests agent traces like any service's; the semantics are new, the pipes are not.
• CI/CD. Prompts, tool schemas, and policies are versioned artifacts; the delivery machinery you have carries them — only the eval gates are new.

What needs adjustment — the six common workstreams

1. Identity and authorization for non-humans. Per-agent identities, short-lived task-scoped credentials from a broker, on-behalf-of context binding, and policy enforced at the tool layer. This is the workstream with the largest gap between industry rhetoric and installed reality — and the one an auditor will find first.
2. API semantics for machine consumers. Human-app APIs tolerate ambiguity; agent-callable APIs cannot. Idempotency keys, dry-run/simulate endpoints for consequential operations, fine-grained scopes that distinguish read, propose, and execute, and error responses a model can act on. Mostly refactoring at the edges — but it is the difference between an agent that proposes a payment correction safely and one you can never let near payments.
3. Governed access paths into the core. The batch core is the constraint, not the villain. Agents get no screen-scraping and no direct DB reads — the modernization move is a thin, governed API/CDC layer over the core's stable functions, which is exactly the strangler-pattern work a modernization program does anyway. Agent readiness and core modernization are the same roadmap wearing two names.
4. Human-approval infrastructure as a shared service. Every serious scenario ends in “…and a human approves.” If each team builds its own approval UI, you get inconsistent gates and unprovable oversight. Build one HITL service — approval queues in the advisor workplace and ops tooling, with decisions recorded into the evidence store.
5. An MCP registry and tool governance. Enterprise practice has converged on private registries with schema review, security scanning, and approval workflows before any server goes live. Treat tool descriptions as security surface: the model reads them to decide what to call.
6. Document and knowledge governance. The DMS holds what agents need — contracts, directives, KYC files — with permissions designed for humans and folders. Retrieval over ungoverned document stores is how confidential data leaks into answers. Per-document ACL enforcement at retrieval time is unglamorous and non-negotiable.

Three possible scenarios

The advisor copilot (read-heavy, ships now). An advisor asks about a client's portfolio in the context of current directives. The agent calls retrieval (directives), CRM, and portfolio tools via MCP, on behalf of the advisor's identity — and nothing reaches the client without advisor approval. It runs almost entirely on good-enough plumbing; the adjustments it needs are identity binding and the output gate. This is why advisory copilots are everywhere in 2026 while payment agents are not.

Payment-exception triage (propose, don't execute). A flagged or failed payment lands on the bus; the agent investigates across rails status, screening results, and account context, then writes a proposed resolution with reasoning into the case system — where operations executes. Write authority is confined to the case tool; autonomy stays at “propose.” What blocks it today is rarely the model: it's workstream 2 (simulate endpoints, scoped writes) and the evidence store that lets you defend the triage in a regulator conversation.

KYC periodic review (long-running, evidence-critical). On schedule, the agent gathers registry data, extracts from documents in the DMS, drafts a risk reassessment, and assembles an evidence pack — then a human analyst reviews and signs. This is the scenario that exercises everything new at once: async task lifecycle (checkpointed over hours), DMS governance (workstream 6), and the tamper-evident evidence chain, because the output is a compliance artifact. It is also where the payoff is largest: periodic review is high-volume, procedural, and chronically backlogged.

The sequencing takeaway

Build the planes before the use cases: identity broker, MCP registry, HITL service, evidence store — every agent after the first inherits them. Pick scenario 1 to prove value on existing plumbing, scenario 2 to force the API-semantics work, scenario 3 once the evidence chain is real. And notice what the whole exercise reveals: most of what “agent readiness” requires — governed APIs over the core, event access, data governance, machine-consumable interfaces — is modernization work with a new sponsor. The banks that treat it that way get both outcomes for one program.