Dialogflow CX Remembers for 30 Minutes. Your Scheduled Agents Need Yesterday, Not Just This Session.

A Dialogflow CX agent can feel remarkably attentive. Ten turns into a conversation it still knows the caller's name, the product they asked about, and the date they picked three pages ago. Then the conversation ends, half an hour passes, and the same caller returns to an agent that knows none of it.

Both halves of that experience come from the same design. CX has a well-built memory for a live conversation and no built-in memory beyond it. Understanding where the line sits explains most of the confusion around what these agents can and cannot recall.

Inside the session, the memory is genuinely good

Dialogflow CX tracks a conversation as a session, and everything the agent collects along the way is stored as session parameters. Those parameters travel across pages and flows, can be pulled into responses and conditions through $session.params, and let fulfillment act on the full picture gathered so far.

For the length of one interaction, that coverage is exactly what good service needs. Details are asked once. Routing reflects what was already said. A caller who corrects an address mid-conversation gets an agent working from the corrected value, not the first one.

The catch hides in the word session. A parameter is scoped to that session, not to the person, the account, or the job the agent is doing. It is a whiteboard for one meeting, wiped when the meeting ends.

The expiry is documented, and it is short

Google's own session documentation sets the default plainly: session data is maintained for 30 minutes. Leave longer than that and the next interaction opens a fresh session, parameters empty, context gone.

A session TTL can be set on the request, through QueryParameters.session_ttl, and the maximum reaches 24 hours. Within a day, a paused conversation can be picked back up. Past a day, no setting inside CX keeps it alive.

Compare that ceiling with how businesses actually follow up. The delivery problem that needs a check tomorrow. The support case reopened next week. The renewal conversation that happens every quarter. Recurring work runs on a calendar of days and weeks, and a memory that expires in hours is structurally mismatched to it, however far the TTL is stretched.

The revive pattern tells you who owns persistence

Google documents a route around expiry, and its shape is revealing. To restore an earlier session's position, your application saves the state the API returned, the current page and the parameters, and later sends that saved state in with a new request. The platform resumes from the state it is handed.

In other words, revival is a storage feature of your system, not of CX. Your code decides what to record, your database holds it, and your code matches it to the right returning user. Teams routinely build exactly this, often through webhooks that read and write a CRM or a custom store during fulfillment. The agent ends up with something that behaves like long-term memory, assembled from parts the team maintains itself.

That assembly also stays local. The saved state makes sense to the one agent it was built for. A second agent, a scheduled workflow in another platform, or an assistant working in a different tool has no way to read it, so every addition to the stack starts maintaining its own separate version of the past.

Scheduled runs live entirely on the far side of the line

For an agent triggered by a schedule rather than a person, the gap is total. There is no returning caller to match a session to. Each run begins as a new session, which means it begins without the previous run's findings, the commitments made last time, or any record of which steps already failed and were retried.

So operators rebuild continuity underneath the agent: exports, tables, hand-written summaries passed in as parameters at the start of each run. The agent performs well inside its 30 minutes while the organisation around it does the remembering by hand, in formats nothing else can use.

Memory that starts before the session does

The alternative is to stop storing the past inside sessions at all. A dedicated memory layer holds the history independently, so a run, whether it starts from a caller, a webhook, or a clock, begins by reading the relevant record and ends by adding its own. Continuity becomes a property of the memory, not of how recently the last session ended.

Vilix AI provides that layer. It is cloud hosted, so there is nothing to deploy or maintain, and it connects over MCP, which means the same memory follows the work across a Dialogflow CX agent, other automation tools, coding assistants, and chat tools. It keeps full conversation history rather than only the facts pulled out of it, so the reasoning behind an earlier decision stays available word for word, not just as a saved parameter.

Getting started carries no commitment: the free plan is free forever, the Pro trial runs 7 days with no credit card, and everything stored can be exported or deleted at any time. Let Dialogflow CX do what it does well inside the conversation. Put the memory outside it, and the next run, tomorrow or next quarter, opens with yesterday already loaded.