Does Cognigy Remember Between Sessions? The Contact Profile Is the Whole Answer

You are evaluating Cognigy for your contact center, or you already run one there, and the question keeps surfacing: when a customer comes back tomorrow, does the agent know them, or does it start over like a stranger? The honest answer is that Cognigy remembers between sessions, but only one specific thing, and only if you set it up deliberately. Everything else dies with the session.

The short answer

Yes, with an asterisk. Cognigy.AI gives its AI Agent Node two memory types. Long-term memory persists across conversations and sessions. Short-term memory covers only the current conversation and is never stored once it ends. Long-term memory lives in exactly one place: the user's Contact Profile. So "does Cognigy remember between sessions" really means "does your agent have access to the Contact Profile," and the answer depends on how you configured the flow.

What long-term memory actually is

The Contact Profile stores general contact information, name, email, and the like. It can also hold descriptive facts Cognigy calls "Memories": one-line statements such as "The user wants to be called by their first name" or "The user prefers an aisle seat on long-distance flights." Once stored against the profile, that information is available the next time the same user chats or calls.

Getting it into the agent takes an explicit step. In the AI Agent Node settings there is a memory handling section with a Long-Term Memory Injection option. Set it to "Inject full Contact Profile" and the agent gets the customer's profile, fields and memories included, injected into its context. Alternatively, you can configure Contact Profile Information usage for all jobs at the AI Agent level under Data Privacy and Security. Either way, nothing about this is automatic: a default AI Agent Node does not read the profile unless you tell it to.

Getting memories INTO the profile takes a second explicit step. The simplest path is the Add Memory Node, which stores any text you pass it as a user memory; from that moment it is available through long-term memory. To automate it, you can expose an add_memory tool action to the AI agent so it stores user-provided facts on its own, one sentence per memory, with a description like "This tool stores user-provided information such as facts, preferences, or specific requests." Without one of these, the profile stays empty and long-term memory is a feature with nothing in it.

What dies when the session ends

Short-term memory exists to track the current conversation: which plan the customer selected, what topic is being discussed, the half-finished claim. Cognigy's own documentation is direct about its lifespan: unlike long-term memory, it is not stored or saved after the conversation ends. The session closes, and that working context is gone.

This split has a practical consequence for automation operators. If your flow relies on anything beyond profile facts, if the agent needs to know what it did last time, what a tool call returned, what it decided, what failed, there is nowhere inside Cognigy for that to live. The Contact Profile remembers the customer. Nothing remembers the agent's own work.

The limits that matter for scheduled agents

Three boundaries are worth knowing before you build on this.

First, the memory is per-contact, not per-agent. It is shaped for customer-facing agents that personalize across touchpoints. A scheduled agent that runs reports, monitors systems, or triages tickets has no "contact" to hang facts on, and no operational memory of its own previous runs.

Second, capture is manual or tool-built. Neither profile memories nor run history accumulate on their own. If the Add Memory Node is missing from your flow and the add_memory tool is not wired up, the agent wakes up each session with an empty long-term memory no matter how many conversations it has handled.

Third, it is customer data, so it inherits customer-data obligations. Cognigy itself notes that contact profile memory sits under regimes like GDPR and the AI Act, and the profiles are editable and deletable through the Contact Profiles view and an API. That is the right design for a CX platform, and it is also a reason not to stretch this mechanism into a general agent-memory store.

When you need memory that follows the agent, not the contact

Cognigy's model answers one question well: "what do we know about this customer?" Scheduled and multi-tool agents ask a different one: "what happened last run, and what should I do differently this time?" That question needs memory that follows the agent across sessions, tools, and devices, and that the agent can write to and read from directly.

That is the shape Vilix AI is built for. It is cloud-hosted, so there is no infrastructure to manage; the first question anyone asks, local or cloud, is answered up front. Because it connects over MCP, the same memory and context follow the agent on phone apps, laptop, and every AI tool, one memory on every device and every app. It stores full conversation history, not just extracted facts, so the real run can be revisited anytime. There is a free plan forever and a 7-day Pro trial with no credit card, and your data is portable: export everything or delete it anytime.

If your agents wake up blind every run and re-brief themselves from scratch, the fix is not a bigger profile. It is one memory that belongs to the agent itself. Give your scheduled agents a memory layer at https://vilix.ai/?utm_source=vilix-blog&utm_medium=article&utm_campaign=does-cognigy-remember-between-sessions and let them pick up where they left off.

Sources

• Cognigy Help Center: "Give your AI Agent access to memory" — https://support.cognigy.com/hc/en-us/articles/17346572088348-Give-your-AI-Agent-access-to-memory
• Cognigy: "An Ultimate Guide to AI Agent Memory" — https://www.cognigy.com/product-updates/an-ultimate-guide-to-ai-agent-memory