Shopify Sidekick Remembers the Chat. Your Automations Still Wake Up Blank.

On Tuesday you describe the automation in plain English and Sidekick builds the whole Shopify Flow workflow for you: the trigger, the conditions, the actions, visualized on screen. It feels like the assistant knows your store. On Friday you open Sidekick and ask it to tweak that workflow, and it asks which workflow you mean.

Both moments are Sidekick working as designed. The assistant remembers your conversation. The automation never met your conversation. If you run anything on a schedule for your store, that gap is where your context keeps dying.

Sidekick's memory, accurately scoped

Sidekick does remember things, and it is worth crediting what it does before drawing the boundary. With the memory toggle on, Sidekick keeps context across your conversations, so a question today can build on what you discussed last week. It stores up to 50 explicit preferences about how you like things done. Over time it adapts its answers to your communication style. It is included free with every Shopify plan, which makes it one of the most widely used merchant-facing AI assistants in ecommerce.

The boundary has three edges. First, the retention window is capped: guides put it at your last 10 conversations, with the oldest removed as new ones arrive. Second, the memory is conversational. It makes the next chat better; it does not keep a durable record of what your business decided. Third, it is scoped to the chat surface. Sidekick's memory never leaves the sidebar.

Gap one: the builder is not the runner

The headline feature for operators is that Sidekick turns a sentence into a working Flow workflow. "Tag customers when they place an order over $200" becomes a real workflow with triggers and conditions, no visual builder required.

But once built, the workflow runs on Flow's engine, on its own schedule and triggers. The AI step inside that workflow receives whatever data the workflow passes it. It does not receive the six conversations where you explained to Sidekick that wholesale orders should be excluded, that VIP means something specific in your store, or that last month's version of this workflow double-tagged everyone and you had to clean it up. The builder sat in all those conversations. The runner sat in none of them.

Every automation platform has this split between the design-time assistant and the runtime agent. The demo always looks like one mind. In production there are two, and only one of them has a memory.

Gap two: scheduled work re-briefs itself every time

The second place the gap bites is recurring work you do through Sidekick itself. Saved prompts let you store a recurring request, like a weekly performance summary, and fire it with a shortcut. It feels like delegation to an assistant that knows you.

Look at what actually happens each time the prompt fires: Sidekick re-reads your store's data, re-generates the summary, and you get a fresh answer. What it does not do is remember what last week's summary concluded, what you did about it, or what you told it to watch for this week. The prompt repeats the request. It does not carry the learning. If you want continuity across weeks, you are the continuity: you paste last week's context into this week's chat, or you re-explain the thing you already explained.

For a merchant checking in occasionally, that is a minor friction. For an operator running daily review triage, restock watches, or discount hygiene on a schedule, it is a recurring tax: every run starts from zero, and the agent that should be getting smarter with every run is not.

What a scheduled agent needs instead

A recurring agent needs memory that survives the run boundary. Concretely, three things:

1. What past runs decided, with reasons. The escalation, the tag, the skipped order, and why. An outcome without its reasoning is a label the next run cannot reuse.
2. What broke and how it was fixed. The retry cadence that worked, the exception that was not really an exception. Without a record of failures, every run re-learns the same lesson at full price.
3. Preferences that do not expire. Routing rules, thresholds, the "never do this" list. These should hold in month six as firmly as week one, not fade when a retention window slides past them.

This is not a chat feature. It is infrastructure: a durable, searchable store that lives outside any single run, readable by the next run and by every tool you operate, not just the one sidebar where the conversation happened.

The honest DIY version is a database, an API, embeddings, and retrieval code, plus the ongoing maintenance nobody budgets for: the schema that drifts, the index that degrades, the store that quietly goes stale. Some teams have the capacity. Most operators do not, and should not have to.

One memory, every run, every tool

Vilix AI is the hosted version of that infrastructure. It is cloud-hosted, so there is nothing to provision and nothing to maintain. Your agents reach it over MCP, the open protocol, which means the same memory follows them across every tool you run, not just inside one platform's chat. It stores full conversation history, not just extracted facts, so an agent can revisit what was actually decided instead of reconstructing it from a summary. The free plan stays free forever, the 7-day Pro trial asks for no credit card, and your data remains yours: export everything or delete it anytime.

The pattern it enables is the small boring one that works: the agent writes what it decided and why at the end of the run, and reads back what is relevant at the start of the next one. Run ten thousand becomes as informed as run ten.

Chat recall is not automation memory

Sidekick's memory toggle is good at its job: making the next conversation better than the last one. It was never designed to be the memory of your automations, and judging it for that would miss the point. The point is architectural. Conversational memory lives inside the chat. Automation memory has to live outside the run. Once your store's agents run on a schedule, give them a memory that does too, one that the next run, and the tool after that, can actually read.