A customer changes the delivery location halfway through a long service conversation. Later, the agent produces a clear, confident summary using the old address. The problem may be the information selected for that step, rather than the model's ability to understand the latest message. A larger context window alone does not decide which version is authoritative.
For a business agent, context is the information available for the current decision. Memory is information retained for future use. Neither should replace the system that owns the order, approval or customer record. The design task is to keep the right facts available, with their origin and scope, while allowing obsolete assumptions to expire.
Start with a case that changes over time
Consider an illustrative installation request. The customer first asks for a weekday visit at the head office, then moves the work to a branch and requests a weekend slot. A technician has already assessed the original location. The agent must preserve the assessment as history, identify what the change invalidates, and ask for a new availability check. Combining the old assessment and new location into one confident recommendation would be a substantive error.
Write down what the next decision needs: the current location, requested slot, unresolved constraints, latest customer confirmation and the applicable service policy. A transcript of every message may contain these facts, but it also contains superseded options. The application should expose a current case record and retrieve supporting messages when needed.
Separate four things: the user's active request, confirmed business facts, tentative interpretations and background material. A sentence inferred by the model belongs in the third group until it is verified. Repeating that sentence in several summaries must not promote it into a confirmed fact.
Give each kind of memory a clear boundary
LangGraph distinguishes thread-scoped state from information stored across conversations, and its production examples use database-backed persistence. This is a useful implementation distinction, but the application must still decide which business identities each record belongs to. LangGraph memory documentation
| Information | Suggested home | Condition for reuse |
|---|---|---|
| Current request and unresolved questions | Case state | Same case and current input version |
| Confirmed delivery location | Authoritative order or customer record | Re-read before a consequential action |
| A preferred writing style | Scoped preference store | Relevant user, allowed purpose and still current |
| A supplier's claim | Source record with provenance | Treat as a claim until checked |
| An approval to perform a specific action | Approval record | Exact approved payload and valid authority |
The distinction prevents an easy mistake: remembering that someone approved an action last week and applying it to a different order today. Memory can help find the old approval, but cannot extend its scope. Similarly, a remembered preference for email should not authorize sending confidential material to an address found in a document.
LangChain's long-term memory documentation describes stores organized through namespaces and keys. Use such organization to reflect tenant, user and project boundaries, while enforcing access in the application itself. A namespace string supplied by the model is not proof of permission. LangChain long-term memory
Build a compact working brief, not a compressed archive
A working brief should make the next step understandable. For the installation case, it could hold the goal, confirmed current facts, rejected options, open questions, completed actions and source references. Preserve identifiers and versions exactly. If the customer changed a location, retain the fact that the earlier assessment no longer applies; a shorter summary that loses this relationship is worse.
Anthropic discusses compaction and persistent notes as ways to manage long-running context. These techniques reduce what must remain in the active window, but their usefulness depends on what survives the reduction. Anthropic on context management
Choose a bounded schema for the brief instead of asking for a free-form summary alone. Store each important fact with its source, confirmation status and last update. Keep links to the full evidence outside the model input. This lets a reviewer resolve an ambiguous summary without restoring an entire transcript.
After a major change, rebuild the affected portion from the authoritative record. Do not repeatedly summarize the previous summary indefinitely. That process can accumulate omissions and turn tentative wording into certainty. For important actions, compare the prepared payload with the current record immediately before execution.
Decide what the agent should forget
Persistent memory creates maintenance work. Define who can correct a stored preference, how long an unresolved assumption remains useful and what happens when a user leaves a project. Retention should match the business purpose. Keeping every conversation forever is not a prerequisite for continuity.
A practical correction flow shows the remembered item, its source and where it is used. A staff member can replace or remove it, and dependent summaries or retrieval indexes should be refreshed. Otherwise the interface may say a fact was deleted while a stale copy continues to influence answers.
Also decide what should never become reusable memory. Credentials, temporary access links and unrelated confidential details generally do not belong in a general preference store. Keep necessary sensitive business records in controlled systems, and retrieve only the permitted fields for the current task.
For a shared assistant, test tenant separation explicitly. Two customers can use the same product name, and two employees can have similar names. Identity must come from authenticated application context and verified records, rather than a language-model guess about which previous conversation sounds relevant.
Test continuity through changes, not only recollection
A useful memory test does more than ask whether the agent remembers a name. Continue the same case after a restart, revise a key requirement, revoke access, introduce a conflicting old document and ask the agent to explain what is still unresolved. The correct answer may be that a new check is necessary.
Measure whether the agent applies the latest confirmed information, preserves critical constraints and avoids importing another case's details. Inspect the actual action payload as well as the chat response. A polite acknowledgement of a changed address does not help if the order update still contains the old one.
Keep the conversation, selected context, memory reads and writes, and resulting case state available in a controlled review trace. This makes failures diagnosable: the source may be wrong, retrieval may have selected an old record, or the model may have ignored a correct brief. Each cause requires a different fix.
If the agent also searches internal documents, connect this design with company knowledge retrieval. If multiple teams update the same facts, first settle which system owns each business record.
Talvyn Labs can turn a conversation prototype into an AI product that maintains case context, retrieves permitted evidence and keeps business actions tied to current records. Bring a conversation where the assistant lost track and the systems involved. We can use that failure to define the memory boundaries, acceptance cases and product workflow your team needs.
Build an agent that keeps the current case in view
Let Talvyn Labs design working context, memory boundaries and connections to authoritative records, then test continuity against changes your team encounters.
Build an agent for ongoing business work