Customer Data Platform with a Context Layer: From Golden Record to Golden Context

Series Agentic Experience Platform for Banks · Part 2 of 5. The lead article describes the five layers; Part 1 sets out the operating model. This part covers the bottom layer: the customer data platform with a context layer.

A golden record is a promise from the age of reporting: one customer, one record, every field filled and free of contradictions. For an agent that is supposed to act at the moment of a decision, that is not enough. It needs not only the record but its meaning, its permission and its history. In October 2026 Scott Brinker proposed the more accurate term: golden context, the intersection of customer context, company context and systems context (chiefmartec). This part shows what that intersection means technically in a bank, and why it must not grow larger than purpose limitation allows.

Three contexts, one small intersection

Brinker's distinction is simple and consequential. Customer context is everything that makes up a customer's situation: goals, intentions, preferences, life events, history. Company context is everything the bank knows about itself: product rules, risk appetite, contact policy, responsibilities, governance. Both exist in the real world, independent of any software. Systems context is the part of them that is represented in systems in such a way that an agent can query it and act on it. And that part is usually a small slice (chiefmartec).

Two lines of work follow, which Brinker calls context engineering and value engineering. Context engineering expands systems context: more of the customer's situation and more of the company's rules become machine-readable. Value engineering makes sure the two come together correctly, so that the right rule meets the right situation. Industry figures show how far away both still are. In the Adobe-commissioned survey of 150 customer data platform users, only 39 percent named harmonised profiles as their platform's strongest capability today, and only 27 percent trusted their data warehouse to deliver profiles, segments and the next best experience in real time. Among buying criteria, real-time performance ranked first at 69 percent (Adobe, CDP Study 2026).

For banks a third line of work is added that the marketing literature lacks: context limitation. Systems context may not contain everything that is technically available, only what was collected for and is permitted for the purpose at hand. The European Data Protection Board has made clear in its opinion on AI models that processing personal data for the development and deployment of such models requires a legal basis and a case-by-case assessment of legitimate interest (EDPB, Opinion 28/2024). Golden context in a bank is therefore not the largest possible intersection but the permissible one.

What the context layer has to deliver

We assign five functions to the context layer of the Acceleraid platform. The naming is ours; the functions are the same in every bank, whatever the vendor.

Data management brings together signals from core banking, card, app, service and consent management, with provenance and timestamp. That is the classic job of a customer data platform and remains the most laborious. Identity resolution connects these signals to one person across accounts, channels and roles, including the cases that are common in banks: joint accounts, authorised representatives, customers with both private and business relationships. Consent and purpose stores not just whether consent exists but for what, since when and with which objections; this information has to be queryable at the moment of decision, not only when the data protection officer reviews. Semantics and relationships give the data meaning: what a salary credit is, what a deviation from the pattern means, which products relate to one another. Memory, finally, distinguishes four kinds, which we introduced in our customer brain series: the short-term working state of an ongoing interaction, episodes such as a closed service case, facts such as the preferred contact time, and rules such as the bank's contact policy.

That memory is a scarce resource does not apply only to people. In its guide to context engineering for agents, Anthropic describes context as a critical but finite resource and states the goal as finding the smallest set of high-signal information that makes the desired outcome likely (Anthropic). For a bank's context layer that means: it hands the agent not the whole golden record, but the slice that is relevant and permitted for this decision.

Four kinds of memory, four different obligations

The four kinds of memory deserve a closer look because they have to be handled differently. Working memory holds the state of an ongoing interaction: what the customer just asked in the chat, which options the adviser has already mentioned. It is transient and may be; once the interaction closes, only the outcome remains. Episodic memory stores completed events: the service case, the complaint, the advisory appointment, with date and outcome. It is the memory that prevents the same customer from having to explain the same thing three times, and it is subject to retention limits. Semantic memory holds stable facts: preferred channel, role in the household, product holdings. It changes rarely and has to be versioned on every change, because decisions rest on it. Procedural memory, finally, contains the bank's rules: contact policy, suitability rules, thresholds for approvals. It belongs to the business, not to the agent, and every change is a governance decision.

An agent that does not keep these four kinds apart makes two typical mistakes: it treats transient states as facts and carries them forward, or it treats rules as observations and starts optimising them. Neither is tolerable in a bank.

What the agent should not see

Context limitation has a practical side. There are data fields that technically sit in the golden record but do not belong in the context of an agent preparing notices and offers: special categories of personal data, free-text notes from advisory conversations, transaction details beyond the pattern needed for the purpose. The context layer therefore does not provide access to tables, but answers to defined questions: does the income pattern deviate, yes or no. Is there a marketing objection, yes or no. Was there a service case in the last 30 days, yes and of what kind. Each of these questions is documented, each retrieval logged. That keeps systems context actionable and at the same time smaller than the data base.

From record to context object

How a field becomes context is shown by a hypothetical example in five stages. The starting point is a single raw data point from core banking transaction data: salary credit in October, zero.

Identity resolution assigns the data point to a customer and establishes that no second account is known to which the credit might have moved. Semantics recognises that the previous 14 months showed a stable pattern and that October deviates from it. Consent management reports that customer care is permitted but marketing has been objected to. Episodic memory adds that a service case for a lost card was closed three weeks ago, which may have annoyed the customer. Only the context object that emerges from these five stages goes to the decision layer, with the instruction: check a notice, no credit offer.

If one of the stages is missing, the field remains a data point. Without identity, nobody knows whose salary is missing. Without meaning, zero is just a number. Without permission, every reaction is a risk. Without memory, a well-intentioned notice feels like a second annoyance in three weeks. That is the practical difference between golden record and golden context: the record is complete, the context is actionable.

Why this is not a question of architectural fashion

The debate about customer data platforms is often conducted as an architecture dispute: central or federated, platform or warehouse, with or without its own storage. In our piece on the so-called headless CDP we argued that this question is secondary. What matters is whether the five functions are available at the moment of decision, at the latency the customer moment demands, and with the purpose limitation that data protection law demands. Whether the data is copied or queried for that is an operational decision, not a matter of principle.

A vendor that renames itself from Treasure Data to Treasure AI draws from the same observation the conclusion to put agents directly on the data layer (Treasure AI). In a bank, the context layer has to sit in between, contributing meaning, permission and memory while at the same time limiting what the agent sees. That is not a detour. It is the only form in which speed and purpose limitation are possible at the same time.

Three questions for your own stocktake

Anyone who wants to assess their own context layer does not need a maturity study. Three questions suffice. First: can a system query, at the moment of a decision, for which purposes this customer has consented and which she has objected to, in under a second? Second: does the same system know what has happened with this customer in recent weeks, across channels, including closed service cases? Third: is it documented which data fields may enter an agent's context for which purpose? Whoever answers all three with yes has a golden context. Whoever answers one with no has a golden record, and should keep the agent waiting.

What follows in the next part

A context object is an input, not a decision. What becomes of it is decided by the layer above: predictions, rules, goals and limits, combined into a decision record. Part 3 covers AI and the decision engine with predictions in the middle of the loop.

Five takeaways

1. Golden context is the intersection of customer context, company context and systems context; in banks it is not the largest possible intersection but the permissible one.

2. The context layer has five functions: data management, identity resolution, consent and purpose, semantics and relationships, memory in four kinds.

3. A field only becomes a context object an agent may react to through identity, meaning, permission and memory; if one stage is missing, it remains a data point.

4. Context is a finite resource: the layer hands the agent the relevant and permitted slice, not the whole record.

5. Whether data is copied or queried is an operational decision; what matters is availability in the customer moment and purpose limitation.

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.