Your Scheduled Agent Keeps Creating Duplicate Records. It Never Learned What It Already Created
Your CRM has three copies of the same customer. Your ticketing system has two tickets for the same problem, both open, both being worked. Your invoicing tool has two invoices for one job, and nobody is sure which one the customer already paid. Nothing crashed. No error message appeared. Your scheduled agent did exactly what it was told to do, on schedule, every run. The duplicates are not a bug in the agent's instructions. They are a gap in its memory: the agent never learned what it already cr
Your CRM has three copies of the same customer. Your ticketing system has two tickets for the same problem, both open, both being worked. Your invoicing tool has two invoices for one job, and nobody is sure which one the customer already paid.
Nothing crashed. No error message appeared. Your scheduled agent did exactly what it was told to do, on schedule, every run. The duplicates are not a bug in the agent's instructions. They are a gap in its memory: the agent never learned what it already created.
A scheduled run starts with no memory of its own work
A scheduled agent wakes up, reads its prompt, and looks at the world in front of it. It sees a new form submission, a new support request, or a new row in a spreadsheet. What it does not see is its own history. It cannot see that last Tuesday's run already created a contact for this person, or that yesterday's run already opened a ticket for this issue, because that history was never stored anywhere the next run can read.
So the agent does the reasonable thing. It creates the record. The next run sees the same trigger, or the same unresolved-looking input, and creates it again. Each run is diligent, careful, and completely unaware of the runs before it.
This is why duplicates keep appearing even after the workflow is "fixed." The prompt is fine. The tools are fine. The missing piece is a record of completed creations that survives from one run to the next.
The four ways duplicates happen
Duplicates usually arrive through one of four routes, and most operators have seen at least two of them.
First, the blind retry. The agent calls an API to create a record, the connection times out, and no response comes back. From the agent's side, the creation failed. From the destination's side, it succeeded. The agent retries, and now two records exist. The retry was correct behavior. The missing piece was a way to check, before retrying, whether the first attempt actually landed.
Second, the overlapping run. A run takes longer than the interval between runs, so two runs pick up the same input at the same time. Neither run knows the other is working. Both create the record.
Third, the re-run after a fix. Something goes wrong halfway through a batch, the operator fixes the cause, and the batch runs again from the top. Every record the first attempt already created gets created a second time, because the second run has no list of what the first run finished.
Fourth, the same person through two doors. Someone signs up with a personal email, then later books a demo with a work email. Both submissions are legitimate. Neither is an error. But without a shared memory that connects the two, the agent treats them as two different people and creates two contacts.
Notice what all four share. In every case, the agent is missing the same thing: a durable, readable record of what it already created, keyed to the work itself rather than to one run.
What a creation memory needs to hold
Fixing this does not require a bigger model or a more detailed prompt. It requires the agent to check before it creates, and to write down what it created the moment it creates it.
The check needs three parts. First, a stable key for the unit of work, built from the action and the entity: "create-contact for customer 4471," or "open-ticket for order 8892." A timestamp must never be part of the key, because a timestamp makes every attempt look like new work, which is exactly the problem being solved. Second, a lookup the agent performs before every creation: has this key already been completed, and if so, what record id resulted? Third, an immediate write-back: the moment a creation succeeds, the key and the resulting record id go into memory, before the run moves on to anything else.
That sequence turns a retry from a duplicate into a no-op. The agent retries, finds the key already completed, reads the existing record id, and moves on. An overlapping run finds the same key and skips the creation instead of doubling it. A re-run after a fix skips everything already completed and picks up where the first attempt stopped. And the same person arriving through a second door gets matched to the existing contact, because the memory holds the connection between the two addresses.
The order matters. Memory must be read before the run plans its work, not consulted halfway through after creations have already happened. And the write-back must happen immediately, not at the end of the run.
Why a file or a spreadsheet is not enough
Many operators try to solve this with a spreadsheet of processed ids, or a file the workflow updates. That works until it doesn't. The file lives in one workflow, so a second workflow, or a second tool, cannot read it. The file gets overwritten by overlapping runs, and its format drifts as someone adds a column.
What the agent needs is memory that every tool can read, that survives platform changes, and that holds more than a flat list of ids. It needs the reasoning too: why two records were merged, which record was kept as canonical, and what exception was approved.
One memory every run reads before it creates
That is what a hosted memory layer gives a scheduled agent. Vilix AI is cloud-hosted, so there is nothing to install and nothing to maintain: the memory lives in the cloud and the operator manages no infrastructure. Every tool connects to the same memory over MCP, so a contact created by a run in one tool is visible to a run in another tool. The agent reads the same memory before every run, checks its creation keys, and writes back each new record id as soon as it is created.
Because Vilix AI keeps full conversation history, not just extracted facts, the memory also holds the reasoning behind the decisions: the merge rule that was agreed, the exception that was approved, the correction that was made in a chat the night before. A correction made in one tool is visible to the scheduled run the next morning, without anyone copying it into a workflow.
The deal is plain: a free plan that is free forever, a 7-day Pro trial with no credit card, and data that stays yours, with export of the whole memory anytime or deletion whenever you want. Start with one agent and one creation ledger: the action keys it checks, the record ids it writes back, and the merge rules it follows. The duplicates stop when the agent can finally answer, before it creates anything, the one question it has never been able to answer: did I already do this?
Your scheduled agent does not have a creation problem. It has a memory problem. Give it a memory of what it already created, and the second copy stops appearing.