Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
[This article is prerelease documentation and is subject to change.]
Memory lets an agent powered by the Customer Conversation harness carry approved context from earlier conversations into the next one, so a returning customer is met with continuity instead of a cold start. The agent can recognize open intents, recall what was discussed, and pick up where the last conversation ended.
Memory for agents powered by the Customer Conversation harness is a distinct capability from Memory (preview), which applies to agents powered by the GitHub Copilot harness. Rather than free-form recall, Customer Conversation harness memory captures structured context through a defined schema of built-in and custom parameters, and covers short-term conversation context only, with a retention period of 30 days.
Memory is configured once at the agent level and applies to the root agent and every child agent beneath it. It works in both Speech and Chat conversations, and when a shared contact identifier is configured, context recorded in one channel is available in the other.
What your agent remembers
Built-in context types
Two built-in context types are active whenever Memory is turned on. Each has a defined schema, so you can reference its values in instructions with no additional setup.
| Context type | Variables | What it captures |
|---|---|---|
| Customer profile | /customerName |
Customer details captured during conversations, used to personalize future interactions. |
| Conversation history | /pastOpenIntentList, /pastConversationSummary |
Key details from past conversations, such as open intents and a summary, carried into future interactions. |
Custom parameters
Beyond the built-in types, you can define parameters for the details your business depends on, such as a membership tier, a requested service action, or a flag that drives routing. Each custom parameter is defined by:
- A unique name.
- A data type of string, number, or boolean.
- A plain-language description that tells the agent what to look for. The description does most of the work, so write it as an explicit instruction rather than a label.
- The set of values the parameter is allowed to hold.
The following limits apply when you create or edit a custom parameter:
| Setting | Requirement |
|---|---|
| Name | Unique within the agent. Spaces are accepted and removed automatically when the name is used as a variable. |
| Data type | String, number, or boolean. |
| Description | Required. Between 30 and 300 characters. |
| Allowed values | Required. Up to 10 values, each up to 30 characters. |
| Number of parameters | Up to 5 custom parameters. |
Choosing how a value is updated
Every custom parameter uses one of two consolidation modes, which determine how a newly extracted value merges with what memory already holds for that parameter across conversations. You choose the mode when you create the parameter.
- Replace: Suits values with a single current truth, such as a membership tier or a fraud flag. Each newly extracted value overwrites the stored one, and only the most recent value is kept. If a conversation produces no new value, the previously stored value stays in place rather than being cleared.
- Append: Suits values that accumulate, such as the service actions a customer has requested. Each extraction is added to a running list as its own timestamped entry, and repeated values are kept separately so the sequence stays accurate. The agent reads the most recent entry for a given value as the current state. If a conversation produces no new value, the list is unchanged, and entries are pruned as they age past the retention window so lists don't grow without bound.
Turn Memory on or off
A single control at the agent level turns Memory on or off. It governs everything: generating context, storing it, retrieving it, resolving memory variables in instructions, and surfacing context to human agents. The setting covers the root agent and all of its child agents, and changing it is confirmed before it takes effect.
While Memory is off, no context is generated, stored, retrieved, or referenced anywhere in the agent. Turning it back on resumes normal behavior for new conversations; previously stored context becomes available again only if it's still within the retention window.
Author instructions with memory variables
Reference built-in and custom parameters directly in agent instructions. References for system parameters look like pastOpenIntentList and pastConversationSummary.
Cross-channel continuity
Context is associated with a channel-specific identifier, such as the caller's phone number for voice and an authenticated session identifier for web chat. On its own, that keeps each channel's memory separate.
Configuring a shared contact identifier links those channel identities to one customer, so context written during a phone call is available in the customer's next chat, and the reverse. Context is only released once the customer has been identified: Chat channels authenticate the user first, and Speech relies on the caller's phone number.
This means a customer who interacts with your agent on one channel can continue the same conversation on a different channel, and the agent retains the relevant context, including preferences or details shared earlier, such as a preferred contact method or an account identifier.
As with all Memory context, each agent maintains a separate memory store per user, so one customer's context and preferences are never shared with another.