She Left in March. Why Does Your Scheduled Agent Still Assign Her Tasks?

A team member leaves in March. The farewell lunch happens, the laptop goes back, the accounts get disabled. In May, a client onboarding task lands in her old inbox, assigned by your scheduled agent. Nobody on the team sees it until the client asks why nothing has happened.

The agent did not malfunction. It ran on schedule, followed its instructions, and logged a success. The problem is quieter: the team changed, and the agent's picture of the team did not. Every run works from a roster that was true once and is wrong now.

This is one of the most common stale-state failures in scheduled automation, and one of the easiest to miss, because the work disappears into a dead inbox instead of failing loudly.

Why the roster goes stale

A scheduled assignment agent usually reads a list of people, not the team as it exists today. That distinction is where the phantom assignments come from.

First, the roster lives in a different system than the agent. HR or the identity provider records the departure. The agent reads a spreadsheet, a task template, or a hardcoded assignee list inside the workflow. If no step carries the departure from the HR system into the list the agent reads, the next run has no way to know the person is gone. The HR system did its job. The agent simply never asked it.

Second, assignments get baked into the workflow itself. Many automations store the assignee in the step definition: "assign onboarding tasks to Sarah." That made sense when the workflow was built. Months later, Sarah has moved teams or left the company, and the workflow still carries her name like a fossil. Nobody edits a workflow that appears to be working, so the stale name keeps assigning.

Third, a deactivated account does not stop an assignment. Disabling someone's login ends their access, but it does not remove them from the task tool's member list, the rotation table, or the agent's lookup sheet. The agent assigns the task, the tool accepts it, and the work sits against a name that can no longer open it.

Fourth, role changes break assignments just as surely as departures do. A person who moved from support to sales still exists in the company, but the support queue should no longer be theirs. An agent that assigns by name instead of by current role keeps sending support tickets to a salesperson, and the tickets wait while the real support team never sees them. Joiners, movers, and leavers all change the roster. Most agents only ever learned the joiner part.

Fifth, several agents each keep their own copy of the team. The onboarding agent, the support triage agent, and the review-chasing agent may all hold separate rosters built at different times. A departure honored by one agent is invisible to the others, so the next agent in line assigns work to the same departed person as if the first conversation never happened.

What an assignment record actually needs to carry

Stopping phantom assignments is not about assigning less work. It is about recording the team in a form the next run can actually check before it assigns anything.

A useful record answers five questions. Who is the person, identified by a stable record rather than a name typed into a workflow step? What is their current status: active, moved, on leave, or departed, and on what date did that status change? What work was already assigned to them, so it can be handed over instead of silently abandoned? Who covers their work now, so the next run has somewhere real to send it? And when was this record last confirmed against the source of truth, so a run can tell a fresh roster from a stale one?

The decision a run makes should come from the current roster. If the assignee is active, assign normally. If the assignee has moved, assign to their current team or the person covering that queue. If the assignee has left, assign to the named replacement and flag the handover. If there is no replacement and no current record, the run should stop and say so, not assign into the void.

The fix, in practice

The practical shape of the fix has three parts, and none require rebuilding the automation.

Read the roster at run time. The assignment run should pull the current team list from the HR system or identity provider when it starts, not from a copy saved when the workflow was built. A roster fetched fresh each run can never be months out of date.

Check status before assigning. The run should verify that the intended assignee is still active in their current role before the task is created. That check costs one lookup and prevents the entire failure. If the check fails, the run reassigns to the cover person or escalates to a manager instead of writing the task to a dead inbox.

Record the handover, not just the departure. When someone leaves or changes roles, the handover needs to live where the agents can read it: which tasks move, who takes them, and what was already in flight. A departure recorded only in an email thread is invisible to the next scheduled run. A departure recorded in shared memory is visible to every agent that reads it.

That last point is where most teams discover the real gap. The information exists somewhere. It just does not exist in the one place every agent checks before acting.

One memory every agent reads

The pattern behind the phantom assignment is always the same: each run starts from a frozen snapshot instead of shared, current state. The fix is to give every agent the same living record to read, and to update that record the moment reality changes.

That is what Vilix AI is built for. It is a cloud-hosted memory layer, so there is nothing to install or maintain, and the same memory follows your agents across every tool over MCP: the roster change, the handover note, the cover arrangement, and the full conversation history behind each decision, not just a status flag. When the team changes, the next run reads the change, because every agent reads from the same memory instead of its own stale copy.

The free plan is free forever, and the 7-day Pro trial needs no credit card. Your data stays portable: export everything or delete it at any time.

A short checklist before the next run

Before the next scheduled assignment goes out, check four things. Does the run fetch the roster fresh, or read a saved copy? Does it verify the assignee is still active before assigning? Is there a named cover person for every queue, so a departure routes work instead of losing it? And when someone leaves or changes roles, does that change land in a place every agent reads, or only in a thread one person saw?

If the answer to any of those is no, the next phantom assignment is already queued. The team changed. Make sure the agent knows.