Two People, One Task: Why Your Scheduled Agent Keeps Assigning the Same Work Twice

Two team members start the same task on the same morning. Each believes they own it. By midday, both have done part of the work, neither version is complete, and someone has to sort out which one counts. The scheduled agent that handed out the work did not make a typo. It assigned the task twice because, from its point of view, the task was still unassigned both times.

This is a memory failure, not a scheduling failure. A task assignment is a claim: once someone takes a task, every later run should see that claim and move on to the next item. When the claim lives only inside a single run, the next run cannot see it, and it assigns the task again with full confidence.

How one task becomes two assignments

Scheduled work usually flows through a queue. A list of open tasks sits in a spreadsheet, a project board, or a CRM. On a schedule, the agent reads the list, picks the next open item, and assigns it to the next available person. So far, so reasonable.

The trouble starts with what happens after the assignment. The agent may send a message, create a ticket, or update a row, but the queue itself often keeps the task marked as open. The assignment happened in a message or a ticket, not in the record the next run reads. The next run opens the same list, finds the same open task, and assigns it to someone else.

There are three common ways this happens.

The first is an assignment that never writes back. The agent notifies a person but never updates the shared list. The list stays open, so the next run treats the task as untouched.

The second is two workflows reading the same list. One workflow assigns tasks in the morning, another assigns follow-ups in the afternoon, and neither knows about the other's assignments. Each one works correctly from its own list, and together they double-assign.

The third is a retry that looks like a new task. A run starts, assigns the task, and then fails partway through, or a duplicate trigger fires. The retry reads the list again, finds no record of the first assignment, and assigns the task a second time. The system now has two owners and no way to tell which assignment was the retry.

In each case, the agent is not careless. It is blind. It cannot see a claim that was never written to a place all runs share.

Why a checklist cannot fix this

Teams often try to fix double assignment with a checklist or a rule: "check before assigning" or "only assign tasks marked unassigned." Those instructions fail for the same reason the original workflow failed. A checklist is a static document. An assignment is a changing fact. A run that reads a checklist at the start cannot know what another run assigned five minutes later unless the checklist itself is updated by every run, immediately, in a shared place.

What the agent actually needs is a record with four properties. First, the task has a single identity, so the same job arriving through two triggers is recognized as one task, not two. Second, the record shows who claimed it and when, so a later run can see the claim at a glance. Third, the claim is written before the work starts, not after it finishes, so no second run can slip in during the gap. Fourth, the claim can expire or be released, so a task abandoned by one person returns to the pool instead of staying locked forever.

Without that record, every run makes its decision from stale information, and stale information assigns the same task twice.

The pre-assignment check

Before a scheduled agent assigns any task, it should answer three questions from a record shared with every other run.

Has this task already been claimed, and by whom? If the answer is yes, the run should skip it, no matter what the original queue still says.

Is the claim still live? A claim from last week, with no progress since, may need to be released back to the pool. A claim from this morning does not. The record needs timestamps and progress notes to tell the difference.

What is the current state of the task? A task that is already in progress, already done, or already blocked needs a different action than a task that is genuinely unassigned. Sending it to a second person is the wrong action in all three cases.

When those answers come from shared memory, the visible change is simple: each task gets one owner at a time. The second person never receives the duplicate assignment, never starts the parallel version, and never has to reconcile two half-finished attempts.

How shared memory changes assignment

Vilix AI gives scheduled agents a shared memory they can read before they act and write to after they act. It is cloud-hosted, so there is no infrastructure to run, and the same memory is available to every tool over MCP, not just the tool that made the first assignment. That cross-tool reach matters here, because the morning workflow and the afternoon workflow may live in different tools. A memory stored inside one workflow cannot stop the other workflow from assigning the same task again.

The memory also holds full conversation history, not just extracted facts. A bare status that says "assigned" hides the details a later run needs: who was assigned, what they were told, what they have already done, and whether the task changed hands. Full history carries those details, so a later run can tell a live claim from a stale one and a handover from a duplicate.

With that in place, the assignment workflow changes in one practical way: the run checks the shared record first, claims the task there, and only then notifies the owner. The claim and the notification draw on the same record, so the next run, in any tool, sees the same owner.

Vilix AI is free forever, with a 7-day Pro trial that needs no credit card, and you can export or delete your data anytime. Get started for free. Free forever, no credit card.

The test to run this week

Pick one assignment workflow and look at its last twenty assignments. Count how many tasks were assigned to more than one person, or assigned again after someone had already started. If the count is more than zero, the workflow does not have a people problem or a workload problem. It has a memory problem: the run that made the second assignment could not see the first one.

Fix that visibility first. A scheduled agent that remembers who already claimed a task does not need a stricter schedule. It needs the one thing its current setup cannot give it: a claim record that survives from one run to the next, in a place every run can read.