Designing LangGraph Long-Term Memory Retention Controls Under Broker-Dealer Recordkeeping Obligations

How agent long-term memory persists, and why that matters for retention

In a LangGraph deployment, long-term memory lets an agent carry information across threads. That information can include client details, recommendations, or content derived from client communications. Three layers are worth keeping distinct in a design review: state persisted within a single thread, a store that holds items across threads and is organized into namespaces, and any expiry or deletion behavior the store offers.

The architectural point is the purpose. These mechanisms exist so the agent can function, for example by remembering a preference or a prior conversation. They are not designed around regulatory retention periods, accessibility requirements, or an examiner's request to see what was stored and when it changed. Retention periods, hold logic and deletion evidence therefore fall to the implementer.

An expiry setting is a good example of the gap. Automatic expiry is a sensible way to limit stale memory. If an item is a required record, however, silent expiry is a deletion that the firm's recordkeeping system has to capture and justify.

What the recordkeeping rules ask of a record

The rules treat retention as a property of a record and the system that holds it. Under Rule 17a-4(a), broker-dealers subject to Rule 17a-3 must preserve certain records for not less than six years, the first two in an easily accessible place. Rule 17a-4(b) sets a three-year minimum for listed categories, including communications under paragraph (b)(4). Rule 17a-4(c) requires six years after the closing of a customer's account for account cards and records on the terms and conditions of opening and maintaining the account. FINRA Rule 4511 sets a six-year default for FINRA books and records with no specified period, running from account closing for account-related records and otherwise from when the record was made.

The electronic recordkeeping amendments added an audit-trail alternative to WORM. As of November 2026, a firm using an electronic recordkeeping system must meet one or the other. The audit trail must be complete and time-stamped and must include all modifications to and deletions of a record or any part of it. The Federal Register release also states that a firm must retain these records in a manner that lets it produce copies of the originals during their retention periods.

FINRA's guidance on business-related communications lists channels such as email, instant message, text message and chat. Whether a given agent memory item is a record or a communication is a firm-level legal judgment. This guide does not decide it. It shows how to structure the design so the decision, once made, can be enforced.

Classify memory content and assign retention rules

Start with a classification table for everything the agent can write to long-term memory. The classes below are a design suggestion, not a regulatory list. The retention references show which rule a class could be tested against once legal and compliance have made their determination.

• Communications-derived content: Summaries or excerpts of client or representative communications. If treated as a communication under 17a-4(b)(4), the three-year minimum is the reference point. Trigger: date the record was made.
• Customer account information: Account terms, identifiers and profile data. If it falls under 17a-4(c), retention runs six years after account closing, so items must link to an account identifier and account status.
• Recommendation-related content: Agent-generated recommendations or the inputs behind them. If counted among 17a-3 records, 17a-4(a) means a six-year minimum. Otherwise the FINRA 4511 default may apply.
• Ephemeral working state: Scratch notes, intermediate reasoning and cached lookups that legal and compliance determine are not records. These are candidates for expiry and minimization.
• Policy and procedure artifacts: Versions of the rules governing agent memory. Compliance and supervisory manuals are retained under 17a-4(b)(7) until three years after the manual's use is terminated, so these versions should be kept.

Where retention meets deletion and privacy

Retention and minimization pull in different directions. A required record must be kept for its period and be producible in original form. Content that is not a required record, and that carries customer information, is better minimized or expired. FINRA states that firms benefit from considering customer privacy rules when developing and using AI applications, for both the data used in models and the information made available by their outputs. Regulation S-P governs nonpublic personal information held by covered financial institutions, so a memory store holding such information belongs in privacy and incident-response review.

Two design decisions follow. First, if an item is a required record, the system of record may need to be a compliant recordkeeping system rather than the agent store, with the agent holding a working copy or a reference. Verify that approach against the firm's own analysis. Second, deletion logic needs a hold concept. Expiry should apply only to items classified as non-record, and a deletion request should be checked against the retention schedule before it executes. Both outcomes, the deletion and the refusal, should be recorded.

Privacy and recordkeeping owners should decide the class boundaries together. If they decide separately, the result is usually either over-retention of customer data or premature deletion of required records.

Where runtime enforcement and evidence fit

An examiner will want to follow an item through its life: what was written, what was retrieved, what was redacted or blocked, what was retained, what was deleted, and under which policy. FINRA also expects recordkeeping written supervisory procedures to be reviewed and updated, with supervisory controls that test and verify them. Memory rules for agents belong in those procedures, and the controls should be testable, including whether original records can be produced within their retention periods.

This points to two design requirements. Write the evidence outside the agent's memory store, with timestamps, so that a store-level expiry or overwrite cannot erase its own history. And place policy checks on memory reads and writes in the execution path, so the decision (allow, redact, block, or escalate to a human) is made before the interaction completes and is recorded with the policy version applied. Reviewing after the fact cannot prevent a write that should have been blocked.

Trussed enforces policy in the execution path on individual interactions and tool calls, with allow, redact, block, rate limit and human-approval escalation, and generates audit-ready evidence from that enforcement. It supports self-managed deployment in the customer cloud with configurable retention and data residency. It does not provide transaction-level governance or end-to-end tracing of agentic workflows, and it is not a recordkeeping system of record. Memory interactions that run through tool calls are the relevant scope.