Memory for a customer support agent

Begin with one repeatable moment, such as preparing a concise handoff for the next conversation or recalling the customer’s preferred response format. Avoid a broad goal like remembering everything about every customer. A narrow outcome makes it possible to decide what should be retained, how long it remains useful, and whether retrieval actually improves the conversation.

Keep live account status outside memory. Subscription state, order status, entitlements, refunds, and policy eligibility should be read from their authoritative services when the agent needs them. Memory can help locate the relevant customer context or earlier explanation, but it should not turn a past observation into a current operational fact.

Create a Memory handle from a stable identifier that your trusted server maps to the authenticated customer or account. Do not let an untrusted client choose an arbitrary entity ID. If one Aether tenant serves several customer environments, use the partition model deliberately and keep the mapping in server-side application code.

Decide whether a support case, a person, or an account is the durable owner. A case scope is useful for an isolated incident; a person scope can preserve preferences across cases; an account scope can help with shared organizational context. If the workflow needs more than one, store explicit links rather than silently collapsing those identities.

Useful records include an explicitly stated preference, a compact resolution summary, or a pointer to the source article that solved an issue. Label whether the customer stated the information, an agent inferred it, or a system supplied it. That distinction helps a later response avoid presenting an inference as a confirmed fact.

Set a correction path. When a preference changes or a resolution summary is wrong, the support workflow should update or supersede it rather than adding a competing sentence and hoping retrieval chooses correctly. Sensitive values should follow the same data-handling policy as the support system; appearing in a chat does not automatically make them appropriate to remember.

At the start of a conversation, recall a small set of items relevant to the new request and combine them with fresh records from the support platform. Keep retrieved memory visibly separated from current system data in the prompt or orchestration layer. If no useful memory returns, the agent should continue without inventing a history.

After resolution, let application rules choose what to retain. A reviewed summary is often more useful than an entire transcript. Log the memory identifiers used for a response so a reviewer can reproduce the context, while keeping any ticket update or customer-facing action behind the permissions and confirmation rules already used by the support product.

Create tests for expected recall, stale or conflicting preferences, an empty history, and a customer identifier that must not cross into another account. Measure whether the retrieved item was relevant before judging the final model response. This separates a retrieval miss from a prompt or generation problem and makes the memory policy easier to improve safely.