Your Scheduled Agent Lost Track of Step Three. Every Customer Is Back at Step One.

A trial nurture sequence has five steps. Day one sends a welcome message. Day three sends a setup tip. Day five sends a case study. Day seven sends an upgrade nudge. Day ten sends a final check-in before the trial ends. It is a simple plan, and on paper the scheduled agent runs it perfectly.

In practice, the agent wakes up each morning unable to tell who is on day three and who is on day seven, so it starts everyone at step one. A customer who signed up nine days ago gets another welcome message. A customer who replied to the case study gets the upgrade nudge as if the conversation never happened. Nobody in the workflow failed. The runs all show green. The sequence is quietly broken in the one place no dashboard watches: the agent's memory of where each customer stands.

A sequence is a state machine, and your agent has no state

A multi-day sequence is not five separate messages. It is one process with a position. Each customer sits at exactly one step, and the step they are on determines what happens next. Move them forward when a step completes, sideways when they reply or ask to stop, and hold them still when they are waiting. The position is the whole job.

A scheduled agent without sequence memory has no position. Each run is a fresh start with no record of the last one. The workflow variables that held the position during the run vanish when the run ends. The CRM may hold a status field, but it updates in batches and says nothing about which branch the customer took or what the last message actually said.

Four ways a forgotten position breaks the sequence

The restart loop is the most visible. The agent sends step one again to people who already passed it. Customers read a welcome message for a product they have used for a week, and the message tells them the sender does not know who they are. Trust drops with every repeat, and the repeat is on a schedule.

The skipped step is quieter and worse. The agent assumes a step happened because the schedule says it should have, and moves on. A customer never got the setup tip because that run errored, but the sequence advanced anyway. By day seven the customer gets an upgrade nudge for a product they never set up. They just never convert, and nobody connects the missing step to the lost deal.

The wrong branch is the most embarrassing. A customer replies to step three with a question. The agent answers the question in a separate thread, but the sequence itself never records the reply. The next run sends step four as if the customer never spoke. The customer learns that replying changes nothing, so they stop replying.

The out-of-order step is the strangest to debug. Two runs overlap, or a retry fires after a delay, and a customer gets step five before step four. The messages contradict each other.

What sequence memory actually has to hold

A working sequence memory is small, and that is the point. For each customer it holds four things.

First, the current position: which step the customer is on, stated plainly, not a timestamp to interpret or a log to search.

Second, the outcome of the last step: sent, delivered, opened, replied, bounced, skipped. A step that errored is not a step that happened.

Third, the branch: which path the customer is on. A customer who replied is on a different path from one who went quiet.

Fourth, the timing anchor: when the last step actually went out, so the next step is spaced from reality. A step delayed by two days should push the rest of the sequence by two days.

With those four facts, the morning run becomes simple: read the position, do exactly the next step, write back the new position and outcome before the run ends. A run that does work but does not record it has not finished the job.

The read, do, write loop

Read first. Before the agent drafts anything, it loads the customer's position, last outcome, branch, and timing anchor.

Do exactly one step. The temptation is to catch up a customer who fell behind by sending two or three steps at once. Resist it. A sequence works because each step lands on its own day, in its own context. Catch-up batches read as spam and destroy the pacing the sequence was designed to create.

Write back immediately. The moment the step is done, the position, outcome, branch, and timing anchor get saved, before the run moves to the next customer. If the run crashes halfway through, processed customers keep their new positions and the rest keep their old ones. Nobody gets restarted, nobody gets skipped, and the next run picks up exactly where this one stopped.

This loop also fixes the branch problem. When a customer replies, the reply is recorded as a branch change in the same memory, so the next run sends the reply-path step instead of the default one. The customer sees that their reply changed what happens next, which is the entire reason to run a sequence instead of a broadcast.

Give the sequence a memory that survives the run

The loop only works if the memory it reads and writes outlives the run that uses it. A variable inside the workflow does not. A spreadsheet edited by hand does not, reliably. What the sequence needs is a memory layer underneath the automation: the agent reads it when a run starts and writes to it when the run ends, and the record is still there tomorrow, next week, and after the workflow gets rebuilt.

That is what Vilix AI is built for. It is a cloud-hosted memory layer, so there is nothing to install or maintain. The same memory follows the agent across tools over MCP: the scheduled agent, a chat app, a laptop, all reading and writing one shared memory. It stores full conversation history, not just extracted facts, so branch decisions and replies stay retrievable. It is free forever, with a 7-day Pro trial that needs no credit card, and you can export everything or delete it anytime.

The checklist

Check these four things before the next run.

• Can the agent state, per customer, which step that customer is on right now, without searching logs?
• Does a failed step stay failed in the record, instead of silently counting as done?
• Does a customer reply change the branch the next run takes?
• Is the new position written back before the run ends, not at the end of the day, not in a batch, not eventually?

If any answer is no, the sequence has a memory gap, and it will keep showing up as restarts, skips, wrong branches, and out-of-order messages. Close the gap, and the agent stops treating every customer like a stranger on day one.