Give AI systems context worth remembering

A maintainable AI system separates behavior from the information and capabilities it uses. Memory has a specific place: it keeps selected context available to the Chatbot when that context remains useful over time.

Each Memory resource has a title and content, plus a status, an attachment count, and created and updated metadata in the views where those details are shown.

Keeping Memory separate from Agent instructions makes both easier to review. Instructions can stay focused on behavior while reusable context can be inspected, edited, attached, or removed through its own lifecycle.

Good Memory represents context likely to matter again: a stable preference, an agreed working convention, a recurring constraint, or concise background needed for future interactions. It should not become a copy of everything the system has seen.

Conversations contain temporary details, exploratory questions, corrections, and information that may matter only in the moment. Promoting all of it into reusable context would make future interactions noisier, not more useful.

Managed Memory remains separate from raw conversation history. Create it for context that deserves to persist, and leave transient details in the conversation where they belong.

Documents and Memory can coexist because they serve different retrieval needs. A document remains the better home for substantial source material; Memory is for concise context that should be reusable around a Chatbot composition.

Orders, inventory, timestamps, prices, customer records, and other queryable records should remain in Structured Data. Those systems provide current values and remain the source of truth.

Memory can carry reusable interpretation or context around the work, but it should not duplicate changing records. Keeping the boundary clear avoids stale copies and conflicting answers.

Memory attaches at the Chatbot level—not directly to an Agent. An Agent remains a focused capability, while a Chatbot composes one or more Agents with the reusable context needed for its broader conversational role.

Chatbot Studio reflects this architecture with separate Agent and Memory palette items. Both become visible parts of the Chatbot composition.

A Memory resource exists independently from any one Chatbot. Its attachment count records how many Chatbots currently reference it.

Reuse shared context when it is genuinely shared. When two Chatbots require different context or independent maintenance, create separate Memory resources instead of forcing them to share one copy.

The Memory resource and its Chatbot attachment have separate lifecycles. Control availability for one Chatbot without deleting the reusable resource itself.

The customer Memory workspace provides a dedicated place to maintain reusable context instead of burying it inside Agent configuration.

The current Memory model exposes two states: active and pending. Both can be viewed through the Memory workspace filters.

Chatbot Studio currently loads active Memory for its attach palette. Pending is a resource state; this page does not assume a particular approval workflow beyond what the current product exposes.

Memory works best when each resource has one clear purpose and contains stable, reusable context. Give it a descriptive title, avoid unnecessary duplication, and update the managed resource when shared context changes rather than maintaining scattered copies.

Memory is reusable context, not a credential store. Do not put passwords, API keys, authentication tokens, private connection strings, or other credentials into Memory content.

Credentials belong in dedicated credential fields for the integration, data source, or MCP connection that needs them. Keep unnecessary sensitive personal information out of reusable context as well.

Memory supplies reusable context. Agents provide focused capabilities. A Chatbot can bring both together without turning any one Agent or prompt into the entire system.

Reusable context can become stale as requirements, terminology, preferences, or operating constraints change. Review and edit the Memory resource when its meaning changes.

For a particular Chatbot, disable or detach the attachment when the context no longer belongs there. Delete the resource when it should no longer exist. These are explicit controls; the current product does not promise automatic expiration or version history.