We Let Our Agent Create Its Own Tasks. It Created the Same One 40 Times.

A proactive audit cron scanned a production system every few hours, looking for issues and creating a task whenever it found one. It worked exactly as designed, and that was the problem: the exact same issue, found on every run because nothing had changed, generated a new duplicate task every single cycle. The first fix attempt was the obvious one: add an instruction to the prompt telling the agent to check for existing tasks before creating a new one. It didn't hold up reliably. Prompt instructions are advisory, not enforced, and across enough repeated runs the model skips the check, misjudges a near-duplicate as genuinely novel, or calls the tool anyway. The fix that actually worked moved the check out of the prompt entirely and into the tool handler itself, on the server. Before a create-task call is allowed to create anything, it fetches all currently open tasks in that context, normalizes the candidate text, and short-circuits with an "already exists, skipped" response on a match. One detail that matters: this guard only applies to the automated caller specifically. A human using the same create action isn't blocked from intentionally adding something similar, because a person doing that is being deliberate, not looping. This is a specific and increasingly common failure mode as more people wire AI agents into scheduled jobs, webhooks, and autonomous audits. If your agent can call a "create X" tool on any kind of schedule or across independent sessions with no shared memory, build the dedup guard at the tool boundary before you ship it, not after you find forty duplicate tasks in production.