They Already Finished It. Why Does Your Scheduled Agent Keep Asking Them to Do It Again?

A customer fills in every field on their profile in January: name, company, role, timezone, notification preferences. In February, your scheduled agent sends them a message asking them to complete their profile. In March, it sends the same message again, with a progress bar showing 60 percent. The profile is still complete. The customer has changed nothing, and the agent has learned nothing.

The damage is quieter than a wrong charge or a duplicate invoice, but it adds up the same way. A customer who keeps being told their profile is incomplete starts to doubt the product. Did their answers save? Is something broken on their account? Some reply to support. Some fill the form in a second time with slightly different answers, and now the business holds two versions of the truth. Some simply stop reading messages from you, because the messages clearly do not know who they are.

Nothing in the workflow looks broken. The schedule fires on time, the template is approved, and the audience list comes from a real tool. The failure sits in what the agent knows when the run starts.

A completed profile is a state, not a form

Most onboarding flows treat profile completion as a form submission. A customer submits a form, the form lands in a table, and the job is done. A scheduled agent, though, does not read forms. It reads whatever source it was pointed at on the day the workflow was built, and that source is rarely the same place the completed answers live.

Picture the usual split. The profile form writes to the product database. The onboarding sequence reads from the email tool, which holds its own copy of a few fields. The scheduled agent reads a spreadsheet or a CRM view that was exported weeks ago. Each copy was accurate on the day it was made. None of them updates when the others change, so the agent keeps working from the oldest copy and keeps asking for information supplied long ago.

Identity makes it worse. A customer who signed up with a personal email address and later completed their profile while logged in with a work email looks like two people. The completed profile sits under one address, the onboarding sequence follows the other, and no run ever joins them.

Why the nagging never stops on its own

A scheduled agent that asks once and gets no reply usually asks again. That is the design: follow up until the task is done. But when the task is already done and the agent cannot see it, the follow-up loop has no exit. There is no reply that satisfies it, because the customer already did the thing, and doing it again only creates a second submission for the agent to reconcile.

Worse, repeated nudges train customers to ignore the channel. The third "complete your profile" message gets less attention than the first, and when a genuinely important message arrives through the same channel, it gets ignored too. The cost of a stuck nudge is not just one annoyed customer. It is a channel that stops working, plus conflicting data: every re-submission may answer slightly differently, leaving two records that disagree about the same customer.

What a finished-profile memory actually holds

Fixing this does not mean building a longer form. It means giving the next run a short record it can check before it asks for anything. That record needs five parts.

First, the completion state itself: complete or not, per customer, in one place. Not a percentage scattered across three tools, but a single state the agent reads first.

Second, the field-level detail behind that state: which fields are filled, which were deliberately left blank, and why. A freelancer with no company website is finished. A customer missing a billing address is not. The record has to tell those two apart.

Third, the date and source of the last update. When the profile was completed, and where the answers came from, so a later run can tell a fresh completion from a stale copy.

Fourth, the identity links: which email addresses and accounts belong to the same person. Without the links, every new login restarts the onboarding sequence from zero.

Fifth, a suppression rule with a reason. When the agent decides not to send a nudge, it should write down why: profile complete on a given date, confirmed in a given system. The next run reads that reason instead of re-deciding from scratch.

With that record in place, the run order flips. The agent checks completion state before it drafts anything. If the profile is complete, it moves on. If it is genuinely incomplete, it asks only for the missing fields, by name, instead of sending a generic "complete your profile" message.

Three ways to give the agent that record

The simplest version is a completion file the run reads at startup: one line per customer, with state, missing fields, and last update. It works until the file and the product database drift apart, which they will, because someone has to keep them in sync by hand.

The sturdier version is a single field in the system that already owns the customer record, updated by the same action that saves the profile. This works well inside one system and breaks the moment a second tool needs the same answer.

The version that holds up across tools is a shared memory layer that every agent and workflow reads from and writes to. The profile completion becomes a fact that lives outside any single tool, so the onboarding agent, the support agent, and the re-engagement agent all see the same state. A customer who completes their profile once is finished everywhere, not just in the tool where they happened to fill in the form.

How Vilix AI fits

Vilix AI is a cloud-hosted memory layer, so there is no infrastructure to run: the same memory follows your agents across every tool over MCP, and every run starts from the same shared record instead of its own copy. It stores full conversation history, not just extracted facts, so the context of a completed profile, including what was left blank on purpose and when, stays available to the next run. It is free forever, with a 7-day Pro trial and no credit card required, and your data stays portable: export everything or delete it anytime.

For a profile-completion agent, that means the completion state, the field-level detail, the identity links, and the suppression reason all live in one place that every scheduled run can read before it acts and write to after it acts. A customer who finishes their profile stops getting nudges, in every channel, on the next run.

The check to run this week

Open your last profile-nudge send and pick ten recipients at random. For each one, check the profile in the product itself. If even one of them is already complete, the problem is not your copy or your timing. It is the memory your agent starts from.