Pilot. Silo. Standard. Repeat.

Every technology enters a bank the same way: through a pilot, in one department.

A team finds a problem. A vendor offers a proof of concept. It works, so the pilot expands, and the next department runs one of its own. Nobody does anything wrong. It is the fastest path from an idea to a result, and it is how CRM, analytics, mobile banking and chatbots arrived before.

Ten years on, the bank owns a large number of systems, and each knows the customer a little differently. Cards hold one record. Loans hold another. Service, the app and the branch each keep their own.

The pendulum swings

Then the cost becomes visible. Two teams contact the same customer in the same week. Nobody can say how many customers the bank really has. A regulator asks one question and receives five answers. So the pendulum swings, and the call goes out for a standard: group-wide, one platform, one source of truth.

Banks have made that call more than once. The enterprise data warehouse promised one view and became a queue, and teams with a deadline went around it. The data lake, named by James Dixon of Pentaho in 2010, promised to hold everything in its original form and to sort it out later. Gartner's 2014 report The Data Lake Fallacy: All Water and Little Substance noted the irony. The lake was meant to cure information silos, yet without governance it risked becoming "information silos all in one place".

The customer data platform arrived next. David Raab named the category in April 2013 and defined it as packaged software that builds a persistent, unified customer database accessible to other systems. It worked because it was built for business teams, not for an IT program that finishes in three years. But it made a copy, so the data now lived in two places that had to agree. A composable camp answered by skipping the copy and building on the warehouse, which removed the second truth and left the bank to assemble the parts itself.

Every swing fixed the last swing's flaw and built its mirror image.

All four swings shared an assumption that nobody examined. Each was designed for a human reader: an analyst building a report, a marketer building an audience, a data scientist exploring a lake. AI agents are a different reader, and the difference changes what the data foundation is for.

A different reader

Gartner's 2014 warning was specific. The lake, it said, assumes that users recognize the contextual bias in how data was captured, that they know how to merge and reconcile different sources without prior knowledge, and that they understand the incomplete nature of datasets. A data scientist can meet that assumption. A business user mostly cannot, and an AI agent cannot unless the layer beneath it supplies those skills.

There is a second difference, and it raises the stakes. A warehouse only reported on the customer. An agent acts on the customer: it sends the message, adjusts the limit, waives the fee. A misread record in a report produces a wrong chart. A misread record in an agent produces a wrong action, taken in the bank's name, at machine speed.

What an agent needs that an analyst did not

An analyst could compensate for a weak data layer with judgment. An agent has only what it is given. Four things must travel with the data before an agent can be trusted to use it.

Identity. The agent must know that the cardholder, the borrower and the app user are one person. A bank that holds three records for one customer will have an agent greet that customer three different ways.

Meaning. The cards team and the loans team may define "active customer" differently. An analyst asks which definition applies. An agent picks one and proceeds. Shared definitions have to be built in, not assumed.

Permission. Consent, contact limits and purpose restrictions must be attached to the data itself, so that an agent cannot read a field without also reading what it is allowed to do with it.

Provenance. Every fact an agent acts on should carry its source and its age. A balance from this morning and a balance from last quarter look identical to a model unless the layer says otherwise.

McKinsey's June 2025 study of the agentic opportunity points the same way. It lists data accessibility and quality gaps, for structured and unstructured data alike, among the barriers that keep function-specific use cases stuck in pilot, and it calls for a move from use-case-specific data pipelines to reusable data products with governance extended to unstructured data.

→ The two kinds of context, one built to persuade and one built to answer for: Context to Persuade. Context to Answer For.

Memory, context and decision

It helps to separate three layers that the earlier waves blurred together. The warehouse and the lake are memory: complete, inexpensive and slow, the system of record for everything the bank has ever captured. Nobody needs to move them, and nobody should.

Above memory sits context. This is the layer that turns records into something an agent can read: identity resolved, definitions shared, consent attached, each fact stamped with its source and age, all served in real time. A packaged customer data platform can provide it, and so can a composable stack. Which one matters less than whether the layer passes the four tests at the moment of decision.

Above context sits the layer that decides what an agent may do with it. That is a separate question about rules and records, and it is the subject of the companion article below.

→ The layer above context, and what it governs: Ten Pilots, No Bank.

What this means for the lake and the CDP

Neither is obsolete, and neither is sufficient. The lake keeps its role as memory. The CDP, or whatever the bank builds in its place, keeps its role as the place where a customer is resolved, and gains a more demanding one: serving context to agents, with consent attached, in the time a decision allows.

The question is no longer where the data lives. It is whether what reads it can be trusted to act.

A practical test follows. Can an agent, using the data layer alone, answer three questions: who is this customer, what may I do for them, and how do I know? If any answer depends on a person or a spreadsheet outside the system, the bank has memory but not yet context.

This is how Appice approaches the problem. In its Action Layer the customer data platform senses and resolves identity first, and every later step reads from it, inside the bank's own environment.

Banks have standardized the data four times. The fifth time, the standard that matters is the one that lets an agent know what it is looking at. Once it does, the next questions are how a decision reaches the customer and how the bank learns from what its agents did.