There is a technical question that almost never comes up in enterprise voice AI evaluations, but it determines more of the outcome than any other factor: what type of memory does your system implement?
Not "does it have memory." Not "can it access our CRM." The specific type. Because there are four, they store fundamentally different things, and most enterprise deployments of voice AI in BFSI implement only one of them.
The four-type framework
The taxonomy comes from cognitive science and was formalized for AI agent systems in a 2023 paper out of Princeton, Stanford, and Google (Sumers et al., "Cognitive Architectures for Language Agents," https://arxiv.org/abs/2309.02427). It maps cleanly onto what BFSI voice AI actually needs to do.
Type 1 is in-context memory. This is working memory for the current conversation. Everything said in the call lives in the model's context window. When the call ends, it is gone. No record, no learning, no carry-forward.
Type 2 is episodic memory. This stores past events: what happened, when, and in what order. In BFSI, this is the interaction timeline. The promise to pay made on June 4th. The dispute raised on June 18th. The escalation on July 2nd.
Type 3 is semantic memory. This stores what is currently true about an entity. Not what happened, but what is true right now. Current delinquency state. Active product holdings. NPA classification. Credit score band. The real-time state of the customer.
Type 4 is procedural memory. This stores how an entity typically behaves. Their preferred contact time. The language they switch to when they feel pressured. Whether they respond better to a settlement offer or a payment plan. What channel they actually complete payments through.
Why BFSI needs all four and most vendors deliver one
Consider a realistic collections call- The agent needs to know the current state of the account (semantic). It needs to know what was discussed and promised in the last three months (episodic). It needs to know that this specific customer always answers on the third attempt at 6pm and never completes a payment during a call but does within two hours of a WhatsApp link (procedural). And it needs to track what has been said in the current conversation (in-context).
Strip any one of these and the call quality degrades in a predictable way.
Strip semantic: the agent knows history but misses that the account has been restructured since the last interaction. It offers a resolution that is no longer applicable.
Strip episodic: the agent sees the current state but starts every call as if the customer is a stranger. It makes the same ask that was already refused twice, or misses that a dispute was opened that changes the compliance picture.
Strip procedural: the agent defaults to script. It calls at the wrong time, offers IVR payment to a customer who never uses it, and gets the escalation trigger wrong because it does not know this customer's pattern.
Why most vendors only implement one
In-context memory is essentially free. It comes with any language model. You put the conversation history in the prompt and the model processes it.
Episodic, semantic, and procedural memory all require architecture. External storage, retrieval layers, per-entity indexing, query mechanisms that fire at call time. They require decisions about what to store, how to store it, when to retrieve it, and how to inject it into the model's context without degrading performance.
They also require per-entity isolation. If you store customer memory in a shared vector database and retrieve by semantic similarity, you will cross-contaminate. Customer A's behavior patterns will influence the retrieval for Customer B. This is not a theoretical risk. It is a data architecture failure mode that affects the majority of enterprise AI deployments using naive vector retrieval.
Per-entity context profiles are the architectural response. They store, index, and retrieve all four memory types at the entity level, so the agent serving Customer A is drawing exclusively on Customer A's history, state, and behavioral patterns.
The four procurement questions
Before any voice AI vendor evaluation in BFSI, ask these questions in this order.
One: When a customer calls for the second time this month, what context does your system automatically retrieve about previous interactions? If the answer involves agent-assisted notes or manual CRM lookup, there is no episodic memory.
Two: Where does current customer state data live and how does your voice agent access it at call time? If the answer involves real-time calls to a shared data warehouse with no per-entity indexing, there is no structured semantic layer.
Three: Can your system track and apply individual customer behavioral patterns across calls without manual configuration? If the answer references model capabilities or system prompts, there is no procedural memory.
Four: Is customer data isolated per entity in storage and retrieval, or pooled? Pooled retrieval makes per-customer procedural memory structurally impossible.
The right answer to all four is an architectural description with specific storage and retrieval mechanisms. A vendor who can give you that answer has built the thing. A vendor who responds with feature claims has not.
The question is not "does your AI remember." It is: what does it remember, where does it live, and how does it get to the call?