Why Risk Agents Need Shared Customer Memory

Last updated: September 2026

Shared memory for AI risk agents is one resolved, permissioned, auditable customer record that every agent reads from and writes back to at decision time. It is not a larger context window, and it is not the customer 360 a data team assembles for reporting. Without it, a fraud agent and an AML agent can look at the same person, read their own data correctly, and still reach conclusions that contradict each other.

TL;DR

• Two risk agents disagreeing about one customer is usually a record problem, not a model problem. Each agent reads a different slice and reasons correctly from it.

• Three different things get called memory: an agent's context window, a warehouse customer 360, and a governed risk record. Only the third one is what a risk function needs.

• A shared record has three prerequisites the vocabulary hides. Identities have to resolve, field definitions have to be agreed, and the record has to have a named owner.

• That owner is usually not the agent platform. In most institutions the shared layer is a synchronised copy of a record that lives somewhere else, which makes write-back, staleness and reconciliation design decisions.

• Nothing in supervisory guidance tells you what an agent's record of a customer must contain. The revised model risk guidance issued on 17 April 2026 puts agentic AI outside its own scope, so the institution decides and then has to defend the decision.

Shared memory for AI risk agents: the short answer

Shared memory for AI risk agents means every agent working a customer reads from and writes to the same record, and that record resolves to one identity, carries agreed definitions for each field, and logs what every agent and every human did to it. The test is not how much an agent can hold in a single prompt. It is whether the fraud agent, the AML agent and the credit agent are reasoning about the same customer, and whether anyone can reconstruct afterwards what each of them saw.

Two agents, one customer, two answers

A fraud agent flags an account as low risk while an AML agent treats the same person as worth escalating. Neither is wrong from where it is sitting. The fraud agent has device and transaction history for one product; the AML agent has counterparty and geography data for another.

The disagreement is not a model problem. Both agents read their inputs correctly and reasoned sensibly. They read different records, and nothing in either system knows the other exists.

Every agent added to a risk function makes this more likely rather than less, which is the opposite of what buying the second agent was supposed to do. Oscilar's own product position is orchestrated agents that "carry context across alerts, connect the dots between fraud, credit, and compliance data, and escalate intelligently." Carrying context across alerts only means something if there is one place for the context to live.

Three things called memory, and only one of them is this

Three distinct things share the word memory in conversations about AI risk agents, and conflating them is how a data-platform project gets sold as an agent project.

The table describes three layers that answer three different questions, and only the third answers "what does this institution know about this customer right now."

Vector stores, retrieval strategies and the episodic-versus-semantic memory taxonomy sit outside this. Those questions belong to a team building an agent. A risk function deploying several agents has a different problem, which is that its customer record is spread across systems that were never designed to agree.

Requirement one: the identities have to resolve

A shared record is worthless if fraud, AML and credit each hold a different key for the same person. Entity resolution is the prerequisite, and it has to happen before anything downstream means anything. A single customer view assembled from three unmatched identifiers is three customer views in one table.

Resolution is a judgement, and it fails in two directions. A missed match hides a relationship that exists, so the agent reasons about a fragment. A false merge invents a relationship that does not exist, so the agent reasons about a person who is not there. In a risk context the false merge is worse, because the decision it produces is confident and wrong about a real customer.

This page makes no claim about any particular product's match rate, including Oscilar's, because no such figure is verified. Ask any vendor how theirs was measured, on what population, and what the false-merge rate was on the same run. It belongs on the same list as the other questions worth asking before you deploy a risk agent.

Requirement two: the definitions have to be agreed, not just the data

Consolidating values does not settle what they mean. Someone responsible for operations at a digital financial-services firm described the problem directly: "different teams will define a specific metric in a slightly different way, which is why having one centralized tool is going to be so important for us. That way the calculations are happening consistently in the same way across the board across all teams."

Two agents can read the same field and still disagree, because the field means something different to the team that populates it. A customer marked as reviewed by one team may mean the documents were checked; to another it may mean the case was closed. Neither agent can tell which it is reading.

This is the clearest reason a warehouse customer 360 is not sufficient for risk work. It consolidates values without settling meanings, and the meanings are what the agent reasons over.

The same speaker named the cost of leaving them unsettled: without a reliable central source, "a lot of the subsequent work that happens in the background" goes into vetting information gathered from multiple warehouses.

Requirement three: the record has an owner, and it is probably not the agent platform

Shared does not mean owned. An R&D director at a global payments platform, describing a live deployment, was explicit about where the master copy sits: "our lists are not just being used for [the risk platform's] flow. It's kind of being propagated to different teams in some of the cases. So we cannot have in this case [the risk platform] to be the source of truth of list management. It needs to be a copy of our source of truth."

In most institutions of any size, the shared layer is a synchronised copy of a record that lives elsewhere. Lists, customer masters and account hierarchies are consumed by teams that have nothing to do with risk, and those teams will not accept a risk platform as the system of record. This is the same constraint that governs what an agent needs from the risk systems you already run: the agent reads from those systems, it does not replace them.

That turns write-back, staleness and reconciliation into design decisions rather than implementation details. If an agent writes a disposition into the shared copy, something has to decide whether that propagates to the original, how long the copy may lag, and what happens when the two disagree.

Settle one question before adding a second agent: which system is authoritative for each field. The answer will differ field by field, and writing it down is most of the work.

What the record has to carry, and for how long

A record that several agents can reason over holds four things. Identity, including the evidence for how it was resolved. The agreed definitions for each field. The decision history, including which human confirmed what. And what each agent wrote back, attributed to that agent.

Permissioning belongs inside the record rather than in a layer above it. Not every agent should read every field, and a record that cannot express that will either leak or be scoped down until it is no longer shared.

History is not optional. An agent reasoning about a customer relationship needs the relationship's past, and loading it is a larger job than it looks. The same R&D director listed his deployment's open items and placed "the historical data load" among them, calling it "more of a strategic thing, not specifically a tactical thing for now."

On the write side, Oscilar's published position is narrow and worth stating plainly: agents never autonomously close or escalate alerts, and every recommendation is reviewed and confirmed by a human analyst before any action is taken. What lands in the record is a recommendation plus a human decision, not an agent acting alone.

Why this is a governance question, not a data-engineering one

Nothing in current supervisory guidance tells an institution what an agent's record of a customer has to contain. On 17 April 2026 the Federal Reserve, FDIC and OCC jointly issued revised model risk management guidance, SR 26-2 at the Federal Reserve, Bulletin 2026-13 at the OCC and FIL-15-2026 at the FDIC, replacing SR 11-7 and the 2021 interagency BSA/AML model risk statement. That guidance places agentic AI outside its own scope: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." The agencies say they plan to issue a request for information covering banks' use of AI, and as of today it has not been issued.

So the institution decides what the record contains, writes the decision down, and defends it. None of that removes the underlying BSA/AML obligations on the decision itself, which are untouched.

There is a usable test already in the guidance. SR 26-2 keeps "effective challenge" and defines who can perform it: individuals with the expertise to conduct a critical and objective challenge, sufficient independence to stay objective, and "the organizational standing and influence to effect any change." Apply the same three conditions to the record. Can an independent reviewer with the standing to change something reconstruct what each agent saw at the moment it made its recommendation? If the answer depends on which system they happen to open, the record is not shared.

This is also what an audit trail is for. Oscilar's platform captures the reasoning behind each recommendation, which makes it straightforward to show regulators where humans make decisions. That only holds if there is one record for the reasoning to attach to, which is where the shared record and the governance trail an AI risk agent has to leave turn out to be the same problem.

What it looks like when the record is missing

The failure shows up as ordinary operational friction long before anyone calls it a governance problem. Different people handle the same case, notes are not captured in one place, and the person working it is not looking at the right system.

The consequence is not inefficiency. Someone responsible for operations at a digital financial-services firm framed it in terms of where the records eventually have to hold up: "I want to make sure that our documentation and all of our records are clear, because for obvious reasons, we can't show up to court with missing information." An agent working faster than a human makes that gap larger, because more decisions accumulate against a record that cannot account for them.

There is a measurable version of the other direction. A bank in deployment shows 92% agent agreement with its analyst team on alert disposition and 75% less time per review. Agreement is only measurable because the agent and the analyst were looking at the same thing, which is what the shared record buys before it buys anything else. That is one deployment, not a benchmark to plan against.

Where this breaks

A shared record does not resolve disagreement. It makes disagreement meaningful. Two agents may still reach different conclusions about the same customer, and the value is that you can now tell why, rather than discovering the contradiction in a regulatory exam.

Consolidating the record is a longer job than consolidating the agents, and it can outlast the agent programme that prompted it. A director of fraud management at a global payments and prepaid company described the in-house version of exactly this work: a central system that distributes data to vendors and orchestrates what comes back, built so that "sometime before I'm dead, everyone will be plugged into" it. His company has "probably 30 different platforms on the backlog of trying to get them into the consolidated fraud system." That is a working system, described by the person who built it, with a queue measured in platforms.

Two honest gaps are worth naming. There is no published measure of how often risk agents contradict each other, at Oscilar or anywhere else. And this page makes no claim about how any product, including Oscilar's, resolves identities or synchronises records, because nothing verified supports one.

Where to start

Pick one customer who is currently open in two queues, and try to assemble the single record by hand. How long that takes, and how many systems it touches, is the measurement. It is more informative than any vendor's architecture diagram.

Then name the authoritative system for each field before adding a second agent rather than after. The fields where no system is obviously authoritative are where the contradictions will come from.

What agents have to share beyond the customer record, including task state and escalation rules, is a separate question and a separate piece.

One practical constraint makes this easier than it sounds. Agents can run as a standalone layer on top of infrastructure you already have, or as part of the unified platform. The record question is answered by the layer, not by replacing the systems that own the data.

If you want to test the argument rather than the software, run a one-week agent proof of concept scoped around the record: one customer segment, one resolved identity, and a written answer to which system is authoritative for each field.

Frequently asked questions

What is shared customer memory for AI risk agents?

Shared customer memory is one resolved, permissioned, auditable customer record that every risk agent reads from and writes back to at decision time. It carries the customer's identity and the evidence for how it was resolved, agreed definitions for each field, the decision history including human confirmations, and what each agent wrote. It is a governed record rather than a cache or a reporting table.

Why do risk agents need shared customer memory?

Because an agent cannot reason about a customer it can only see a slice of. When a fraud agent and an AML agent hold different versions of the same person, both can read their inputs correctly and still reach contradictory conclusions. Each additional agent adds another partial view rather than another pair of hands.

What is the difference between an agent's context window and a shared customer record?

A context window is working memory for one agent on one task, and it disappears when the task ends. A shared customer record persists, is read and written by every agent, and is governed by rules about who may read which field. Enlarging the context window gives one agent more room; it gives the other agents nothing.

Is a customer 360 the same as shared memory for risk agents?

No. A warehouse customer 360 or single customer view is built for reporting and analysis, usually assembled after the fact and not available at decision latency. It also consolidates values without settling what they mean, which is the failure mode that matters most for agents. A risk record has to be readable and writable at decision time and has to carry agreed definitions.

How do you persist memory across several AI agents?

By giving the agents a shared record outside themselves rather than trying to synchronise their individual memories. Resolve the customer to one identity, agree the definition of each field, name the authoritative system per field, and require every agent to write its output back with attribution. Persistence then belongs to the record, not to any agent.

How do you govern and audit what an agent remembers about a customer?

Treat the record as the audit object. Log what each agent read, what it recommended, which human confirmed or overrode it, and what was written back, so an independent reviewer can reconstruct the state at the moment of the decision. Apply the effective challenge test from SR 26-2: the reviewer needs expertise, independence, and the standing to change the outcome.

Can shared memory AI risk agents work with an institution's existing risk systems?

Yes, and in most institutions that is the only workable arrangement. Agents can run as a standalone layer on top of infrastructure you already have, or as part of the unified platform, so the shared record sits above the systems that own the underlying data rather than replacing them. The design work is deciding which system is authoritative for each field and how write-back and reconciliation are handled.

How are human review, auditability and agent performance governed when agents share a record?

Human review stays in the decision path: agents never autonomously close or escalate alerts, and every recommendation is reviewed and confirmed by a human analyst before any action is taken. Auditability comes from capturing the reasoning behind each recommendation against a single record, which makes it straightforward to show regulators where humans make decisions. Performance is measured against that same record, which is what makes agreement rates between agents and analysts meaningful at all.

One record before the next agent

An agent cannot reason about a customer it can only see a slice of. Shared memory for AI risk agents is not a bigger context window and not a reporting customer 360. It is one resolved, permissioned, auditable record with agreed definitions and a named owner, and until that exists, each new agent adds another partial view of the same person.

The order matters. Resolve the identity, agree the definitions, name the owner of each field, and then add the second agent. If you want to see what that looks like against your own data, Oscilar's AI agents are the place to start reading, and a one-week agent proof of concept scoped around a single customer record will tell you more than a demo will.