Your Voiceflow Agent Remembers Your Name. It Does Not Remember the Conversation.

Picture the second call in a follow-up sequence. Your Voiceflow agent rings a customer, greets them by name, and notes their plan tier without being asked. It feels like memory. Then the agent asks the customer to describe the problem again, the same problem they spent fifteen minutes explaining on the first call. The greeting was remembered. The conversation was not.

That split is the whole story of how Voiceflow handles memory. Understanding exactly what survives between sessions, and what quietly resets, decides whether your automation feels personal or robotic.

Variables: short-term memory with an opt-in toggle

Voiceflow describes variables as the agent's short-term memory. Inside a session they carry the practical details: the caller's name, account information, the option they picked from a menu, the result of an API lookup. They move between workflow steps, playbooks, condition branches, and tool calls, and they are scoped per user through the user_id, so concurrent callers never share values.

Persistence across sessions exists, but it is a choice you make variable by variable. Open the Variables tab, pick a variable, and flip Persist across sessions on or off.

Leave it on, and the value follows the same user into their next session. The agent greets the returning caller by name and skips the "which plan are you on" question. Leave it off, and the variable resets to its default every time a new session begins, which is exactly what you want for a one-time code or a temporary selection.

The catch is the default shape of things: only the facts you explicitly marked survive. Everything else is session-bound by design.

The session boundary is real

Two built-in details from Voiceflow's documentation show where the boundary sits.

The vf_memory variable contains the last ten user inputs and agent responses, bundled into one string, tool calls included. Ten turns is the agent's working window. It keeps the current session coherent. It does not roll forward into the next one.

Every conversation also gets a transcript ID (vf_transcript_id), and a Get transcript API can pull the full history. That history is real, but the agent never consults it unprompted. It waits behind an API call for a developer to fetch it and inject it somewhere useful. Meanwhile the chat widget's own persistence setting, "never forget, forget after a period, or forget on every reload," decides what the visitor sees on screen, not what the agent knows.

So the agent walks into every new session knowing a handful of slots and nothing of the story. Name: yes. Plan tier: yes. That the customer already tried the router reset twice and it only worked for a day: no, unless someone turned that fact into a variable by hand.

Where operators feel it first

This design holds up fine for a single live agent. It starts to crack in the workflows automation operators actually run.

Take a re-engagement sequence. A voice agent calls dormant customers once a week, checks whether the issue from the last call was resolved, and either closes the loop or books a follow-up. Each call is a fresh session. The persisted variables know the customer's name and segment. They do not know that last week's call ended with a promise the technician would arrive Thursday, or that the customer was frustrated about being asked the same questions for the third time. The agent opens with confidence and immediately proves it was not listening.

Or take the multi-tool version, which is the more common one. Voiceflow handles the call, a CRM holds the customer record, a scheduled workflow scores and routes the outcome overnight, and a different agent picks up the thread next week. The variables that persisted never left Voiceflow. The CRM has the record but the agent cannot read it mid-call. The follow-up agent starts from the CRM's fields, which never contained the conversation. Every handoff drops the context, and every tool is working from a different fragment.

Adding more persisted variables does not fix this. You end up maintaining a fragile list of slots, hand-mapping "what the customer said" into fields, and hoping nobody forgot a toggle. The conversation itself, the thing that would have answered every question, stays locked in a transcript nobody reads.

One memory every tool can share

The pattern that actually resolves this is to stop treating memory as each platform's private feature and give the whole automation one shared memory instead.

Vilix AI is built for exactly that. It is cloud-hosted, so there is nothing to install or maintain, and it connects over MCP, which makes the same memory available to every connected AI tool: the Voiceflow agent on the call, the workflow orchestrating around it, the agent that follows up next week, the dashboard where the morning's results get reviewed. When a call ends, the exchange is saved, the full conversation, not a handful of extracted fields. When the next session begins, wherever it begins, the agent pulls back the context that matters. The customer is never asked to repeat themselves, because nothing was forgotten in the first place.

Shared also means consistent. With last-write-wins semantics, one correction updates the truth everywhere: mark the billing dispute resolved in one place, and no tool reopens it. Your data stays portable and under your control, export it all in a portable format or delete it entirely, whenever you want. The free plan is free forever, and the 7-day Pro trial does not require a card.

Stop maintaining slots. Keep the story.

Voiceflow gives you short-term, per-user, opt-in slots, and it is upfront about that. For one agent in one platform, slots are enough. For scheduled calls, re-engagement sequences, and automations that span tools, they are not. The thing your customers actually want remembered is the conversation, and a conversation belongs in a memory every part of your system can read.