← Back to articlesTRACK 05 · Building a conversational assistant: LangGraph, DSPy and Redis · PART 3 OF 10
GovernanceArchitecture & agentsEngineering

Memory in Agents: Episodic, Semantic, and Procedural

When you build a conversational assistant for e-commerce or a product catalog, the persistence question is technical: latency, cost, TTL.

When you do the same for a bank or investment manager, the nature of the question changes. It becomes technical, architectural, and regulatory at the same time, and the wrong answer shows up not in a benchmark but in an audit.

At first, I treated everything as a single thing, but it is not. Through practical experience, I learned that a financial assistant in production needs at least five distinct layers, each with a different purpose, technology, and lifecycle. And before discussing layers, we need to understand the taxonomy.


The taxonomy#

Cognitive psychology distinguishes three types of human memory. When I began mapping what the assistant needed to "remember," I realized that the same classification applies—and that confusing the three types is where banking projects with LLMs go structurally wrong.

Enlarge ↗

Mapped to real infrastructure, each type has its own layer, lifecycle, and, in banking, regulatory impact:

Enlarge ↗

Episodic Memory: the diary of each conversation#

This is the memory of sequential events: what happened, in what order, with what result. For the assistant, it consists of message history, executed tool calls, and graph-state checkpoints.

I use LangGraph's Redis Checkpointer as a short-term backend:

Enlarge ↗

The choice of Redis here is not random. For short-term episodic memory, read and write speed matters because the graph queries the state at every node. In-memory Redis delivers sub-millisecond latency without PostgreSQL's disk-I/O overhead.

What this memory stores in practice:

Enlarge ↗

Lifecycle: purged after 30–60 days. Only active sessions need to be here. What has ended migrates to the other layers through a Kafka event.

The analogy is what you remember about what you did today. Detailed and sequential, but it does not stay in your head forever.


Semantic Memory: what the agent knows about the client#

This is the memory of facts and relationships: who this client is, what they have already shown a preference for, their previous versus current risk profile, and which products they have consulted. It is not the event itself but the knowledge distilled from events.

Enlarge ↗

The critical difference in the investment domain: semantic memory carries suitability. The agent does not start a session about funds from scratch: it already knows that the client has a Moderate profile (a real-time query is also made to check whether that profile has changed), has consulted FIDC before, and showed interest the last time they saw a return above 15% per year but did not invest.

This is not just UX. It is compliance: CVM Resolution 30 requires suitability to be verified before any product presentation (and if the client does not want a profile assessment, they may also be treated as having a "Conservative" profile). If semantic memory is populated correctly, the agent does not need to ask for the risk profile in every session; the product-shelf tool filters on that basis before generating any response.

The analogy is what you know about a longtime friend—not what you said yesterday, but who they are.


Procedural Memory: how the agent acts#

This is the memory of skills and rules: not what happened or what the agent knows, but how it should behave. For an investment assistant, this includes DSPy-optimized prompts, regulatory validation patterns, and compiled routing criteria.

Enlarge ↗

Procedural memory is the only one of the three that does not change during execution. It is loaded at initialization and remains stable throughout the process lifecycle. When DSPy is recompiled with new examples, or when a CVM resolution changes a validation pattern, you update procedural memory through deployment, not at runtime.

The analogy is riding a bicycle. You do not think; your body already knows. The agent does not deliberate over every compliance rule; critique_node simply executes.


How the three types connect in practice#

Enlarge ↗

Without semantic memory, the agent starts from scratch in every session.

Without updated procedural memory, critique_node uses outdated rules.

Without episodic memory, the agent cannot resolve anaphora. Questions such as "this product" have no reference.


The two layers that serve the regulator, not the agent#

The three types of memory above serve the agent at runtime. The following two layers exist for a different purpose and are equally mandatory.

Analytics answers questions that no operational memory handles well: "Which clients made more than 3 redemptions above R$50,000 in the last 45 days?", "All cases in which the guardrail blocked a response for a CVM 30 Violation in the last quarter."

The legal archive is the vault. Once something is written, nobody modifies it. Not even the senior DBA. Not even the AWS account's root user—if you configure S3 Object Lock in Compliance Mode, not Governance Mode. The distinction matters: in Governance Mode, an administrator can overwrite with special permission. In Compliance Mode, the retention period is inviolable. It is the only configuration that satisfies a Central Bank audit.

Enlarge ↗

The execucao_ferramentas_subagentes table in analytics is especially critical: the parametros_payload field stores the exact arguments the LLM injected into the tool call. When a client complains that "the assistant invested R$10,000, but I said R$1,000," that field is irrefutable proof that the model did not hallucinate—or that it did, and you need to know before the regulator does.


Always consider the worst-case scenario#

Storing things properly is necessary. But it is not enough.

Even with all five layers in the right place, the system still has an unresolved problem: the LLM can generate a response that violates CVM rules or the ANBIMA Code before anything is recorded. The legal archive stores evidence of what was delivered to the client, but if what was delivered was already a violation, storing it does not help.

That is why critique_node exists: the graph's compliance officer. And that is what I will discuss next week: the four regulatory violations LLMs naturally commit, how the Circuit Breaker protects the system when the semantic guardrail fails, and the paradox between the LGPD's right to be forgotten and the Central Bank's retention obligation.

Originally published on LinkedIn. View publication ↗