Your Autonomous AI Agent Will Spam Itself. Here's the Fix.

## The trap every autonomous loop falls into Give an AI agent the ability to create tasks for itself on a schedule, and eventually it will create the same task repeatedly. Not because the model is broken, but because each run has no memory of the last one. A cron-triggered audit that finds an inconsistency at 2pm will find the exact same thing at 6pm, because nothing changed and nothing told it that a task for this already exists. ## The fix that didn't work The obvious first move is to just tell the agent, in its system prompt, to check for existing tasks before creating a new one. This sounds like it should work and it doesn't, reliably. Prompt instructions are advisory. Under enough repetition, the model skips the check, misjudges a near-duplicate as genuinely new, or calls the tool anyway. A production audit cron built exactly this way ended up creating dozens of duplicate tasks over a few days before anyone noticed. ## The fix that did Move the check out of the prompt and into the tool itself. Before a `create_task` call is allowed to actually create anything, the handler fetches all currently open tasks in that context, normalizes the candidate text (trim, lowercase), and short-circuits with an "already exists, skipped" response if a match is found. One detail matters a lot: this guard should only apply to the automated caller. A human deliberately creating a task that looks similar to an existing one isn't looping, they're being intentional, and blocking them for it would just be annoying. The dedup check needs to know the difference between "an autonomous loop calling this on a timer" and "a person who meant to do this." ## Why a concurrency cap isn't enough It's tempting to think a simple limit on how many tasks can run at once solves this. It doesn't. A concurrency cap controls how many things execute simultaneously; it does nothing to stop the same thing from being recreated on the next cycle. You need both: a cap to prevent runaway parallel execution, and idempotency to prevent runaway duplication over time. ## The generalizable pattern Any time an LLM-driven loop can call a "create X" tool on a schedule or across independent sessions with no shared memory between runs, apply this: 1. Normalize the identifying text of the thing being created. 2. Compare only against currently open/active items, not the full historical log (a task closed six months ago shouldn't block a legitimately new one today). 3. Short-circuit with a clear, structured "skipped, duplicate" response the caller can react to. 4. Scope the guard specifically to the automated path. As more people wire AI agents into cron jobs, webhooks, and scheduled audits, this exact failure mode is going to show up constantly. It's worth building the guard once, correctly, rather than discovering it in production the way most people do.