Preventing Duplicate Agent Fires From the Same Trigger Event

Duplicate agent fires happen when the same trigger event causes an agent to run more than once on identical input, and the fix most teams reach for first, tightening the trigger, does not solve the problem, because the trigger was never built to guarantee exactly-once execution. Retry limits, tuned webhook configuration, hoping the delivery mechanism behaves better this time: none of it works. In production this shows up as duplicate invoices sent to the same customer, notifications delivered twice, database writes that contradict each other, or two conflicting PR comments posted seconds apart on the same commit. The causes are mechanical: race conditions, overlapping schedules, at-least-once delivery guarantees, missing idempotency. Distributed systems engineers solved this exact class of problem decades ago in payment processing and message queues, and agent teams are now relearning it the hard way, having inherited the problem without inheriting the tooling that came with it.

The reason it's easy to miss during development is structural. Demos run on fast, synthetic inputs with no slow upstream APIs and no webhook retries to contend with, and a single-instance local run never surfaces a concurrency problem, because there's only one instance to race against itself. The failure shows up under real load, real latency, and real delivery semantics, conditions a laptop prototype doesn't generate. Teams graduating from a sandbox to an organization-wide deployment hit this at scale, when the same trigger mechanism that behaved fine in testing fails the first time a flaky webhook redelivers an event or a cron job overlaps with itself.

The four root causes that produce most duplicate fires

Webhook delivery is at-least-once, and any system built on the assumption of exactly-once delivery will eventually double-fire. Stripe's own documentation illustrates this plainly: "Webhook endpoints might occasionally receive the same event more than once. You can guard against duplicated event receipts by logging the event IDs you've processed." The same logic governs GitHub webhooks, CI triggers, and Slack events. Assume "might redeliver," not "probably won't." That single assumption separates a system that survives a retry storm from one that doesn't.

Overlapping cron execution is the second cause, and it's almost embarrassingly simple once named. A scheduled agent set to run every 60 minutes that takes 90 minutes to finish will have a second instance started by the scheduler before the first one completes. Both instances read the same state, reason independently, and write to the same targets, and neither throws an error. From the scheduler's point of view, both runs are healthy; it has no concept of "this job is already running."

Race conditions at the trigger-to-execution boundary are the third cause. A trigger fires while a previous agent loop is still in flight, and without some shared signal that a run is already active, the execution layer just starts a new one. Multi-agent swarms make this worse: several agents may share no visibility into what's currently executing, so identical tool calls fire from more than one agent at the same moment, each unaware of the other.

The fourth cause sits at the action layer rather than the trigger layer, and it's the one teams reach for last, usually after they've already fixed the first three and still see duplicates. Even a trigger that fires exactly once can produce a duplicate if the agent's own reasoning loop retries a failed action without checking whether it already succeeded. An LLM that doesn't detect prior success just reissues the same tool call, and when that call has a side effect, an API write, an email, a database insert, the blast radius scales with the cost of the action. Worth naming on its own: malformed or empty trigger data that causes an agent to spin, exit, and get re-triggered from the same original event. That produces a duplicate with nothing to do with concurrency at all.

Separating the trigger layer from the execution layer

A trigger's job is reliable event capture, not deduplication. Trying to make the trigger itself exactly-once is fighting a battle it was never built to win, and teams that keep tuning webhook retry logic to fix duplicates are solving the problem at the wrong layer entirely. Delivery mechanisms across the industry, webhooks especially, are built around at-least-once semantics, and no retry configuration changes that guarantee.

The transactional outbox pattern, borrowed from distributed systems design, handles this by writing "starting run X for input Y" and the eventual work result inside the same database transaction. If the agent crashes mid-run, the record on disk reflects an incomplete run rather than a successful one, so a retry is safe by construction. The trigger stays free to fire again; the execution layer checks the record before doing any work and proceeds only if no completed run already exists for that input.

Queuing offers a similar separation boundary. An event arrives, gets enqueued with a unique event ID, and a single consumer dequeues and runs the agent. The queue absorbs the retries; the consumer is what processes exactly once. A queue built around at-least-once delivery with consumer-side deduplication is the more honest design, since exactly-once across a network is a guarantee almost nothing can make truthfully. Any vendor claiming otherwise is glossing over a network partition they haven't hit yet.

This reframes what the trigger is for: a thin, stateless ingestion point. The execution environment becomes the source of truth for run state, and the audit trail lives there instead of scattered across trigger logs nobody reconciles. The costliest version of this mistake is using a short-lived function, a Lambda or a Cloud Run job, as the execution environment for an agent whose LLM calls run for many minutes. The function times out, the trigger retries because it saw a failure, and a duplicate run starts on infrastructure that was never built to hold state across the run's actual duration.

Idempotency keys: borrowing from payment processing to protect agent actions

Payment processors solved this years ago: the same action, submitted twice with the same idempotency key, produces the same outcome and no additional side effect. Agent infrastructure can borrow the pattern directly, and there's little excuse not to.

Constructing a deterministic key means hashing whatever parameters define uniqueness for that specific action. For an email, that's recipient, subject, and date. For an API write, it's resource ID, operation type, and an idempotency token. Same inputs, same key, every time. Before executing anything, the system checks whether that key already exists in an action log; if it does, the prior result gets returned and nothing re-executes. If it doesn't, the action runs and the record gets written atomically alongside it.

Enforcement belongs at the tool-call layer, not inside the LLM prompt, and this is where most implementations go wrong. A model cannot reliably track its own prior execution state across a reasoning loop no matter how carefully the prompt is worded; asking an LLM to remember whether it already sent an email is asking it to do bookkeeping it has no durable memory for. Put the check in the tool wrapper or the MCP handler instead, so it applies no matter which agent or which run issues the call. That matters enormously once more than one agent can invoke the same tool.

The action log becomes more than a deduplication store. It's the audit trail for every side effect the agent produced, letting a team reconstruct exactly what happened, in what order, with what parameters. Scope the overhead deliberately: idempotency keys earn their keep on irreversible or expensive actions, external writes, emails, anything with a real-world consequence. A duplicate read-only call costs almost nothing, and building the same enforcement around it usually isn't worth the engineering hours.

Preventing overlapping cron runs with single-instance scheduling and heartbeats

Restated concretely: a cron job scheduled for every 60 minutes that takes 90 minutes because of a slow upstream API will have the scheduler fire a second instance 30 minutes into the first one's run. Without conflict detection, both instances proceed as if the other doesn't exist.

A distributed lock on job start closes this gap. The agent acquires a lock with a time-to-live before doing any work; a second instance that finds the lock already held exits immediately without executing. Set the TTL to exceed the realistic maximum run duration. Set it too short, and the lock expires mid-run, which lets a duplicate start anyway and defeats the entire mechanism.

A heartbeat pattern beats continuous polling, and the difference isn't cosmetic. The agent fires at a configured interval, processes whatever events arrived since the last run, logs the result, and goes back to waiting. Every heartbeat cycle starts from a known checkpoint rather than "whatever happens to be in the queue right now," which makes recovery predictable: if the agent was down when a heartbeat should have fired, it runs once on recovery, not repeatedly trying to catch up on missed cycles.

Trusting the scheduler to guarantee single execution on its own is the mistake teams keep making. Most cron systems can fire more than once under clock skew or infrastructure restarts. Building a reliability strategy on an assumption the scheduler was never designed to honor invites exactly the failure this section describes.

Debounce and coalescing patterns for webhook and event-driven triggers

Event-driven triggers produce bursts more often than clean, isolated events. A single PR update might fire three separate webhook events within two seconds: a label added, a reviewer assigned, a status changed. Each one is individually a valid trigger for a code review agent. Without debouncing, three agent runs start for what is functionally one PR state, and a reviewer ends up looking at three overlapping comments instead of one coherent review.

Debounce delays execution until the event stream settles. A sliding window resets its timer every time a new event with the same key arrives, and the agent fires once, only after the window closes with no further events landing inside it. This is the right tool when the final state is what matters and the intermediate states along the way are noise.

Coalescing solves a related but distinct problem: merging identical in-flight calls issued by different agents. In a swarm, two agents can independently issue the same tool call, same tool name, same canonicalized input, within the same short window, each unaware the other did the same thing. Solve this at the infrastructure layer rather than inside each agent's own logic; the call executes once and both callers get the shared result. None of it works without shared visibility into what's currently in flight. No shared state means no coalescing, no matter how well-designed the individual agents are.

A debounce hook at the lifecycle layer implements this directly. A BeforeToolCallEvent hook tracks (tool_name, input) pairs within a sliding window, and if a duplicate call arrives inside that window, the hook returns the cached result instead of re-executing. The SUCCESS state gets set explicitly so the agent's own reasoning loop recognizes the action as already complete and doesn't retry it on its own initiative.

For notification-type actions, a cooldown window is a simpler substitute. It enforces a minimum elapsed time between executions of the same action type; the trigger stays free to fire again, but the agent won't act until the cooldown expires. It's less precise than a proper debounce, but far simpler to reason about when duplicates are merely annoying rather than genuinely costly.

Run state as shared infrastructure: what agents need to see to avoid stepping on each other

Every pattern above depends on the same underlying requirement: one agent, or one run, has to know what other agents or prior runs are doing. That's the thread connecting locks, debounce windows, coalescing, and idempotency keys, and none of them function without a shared record of what's already happened or already in progress.

In practice, shared run state means a durable record containing a run ID, the trigger event ID that caused it, a start time, a current status (pending, running, complete, or failed), and a last-processed checkpoint. Any agent instance or trigger evaluator needs to read that record before starting new work, which rules out keeping it in memory. Storing run state in memory is the single most common mistake here, because a single-process lock doesn't survive a restart, a container replacement, or a horizontal scale-out event, and two instances running on different hosts have no way to see each other's in-memory state at all. From each instance's perspective, it's the only thing running, and that blind spot is exactly where the duplicate comes from.

Durable backends exist for exactly this. A relational database with a unique constraint on (trigger_source, event_id) will simply reject a duplicate insert, and that rejection is the signal to stand down. A distributed key-value store with atomic compare-and-set, Redis's SETNX or DynamoDB's conditional writes, offers the same guarantee without a full relational schema. A workflow engine that treats run state as a first-class managed artifact goes further still, making the state something the platform tracks rather than something each team bolts on by hand.

Run state, once it exists, becomes the foundation for observability as well as a deduplication mechanism. A complete record answers whether an agent fired for a given event, what it did, and whether it succeeded, and that record doubles as the audit trail: every tool call and every decision attributable to a specific run, a specific trigger, and whatever automation or person caused that trigger in the first place. In a swarm, the absence of this is what turns a small coordination gap into a systemic one. Without shared run state, each agent believes it's the only actor in the system, and the same event gets processed once per agent instead of once, period. Shared run state turns a swarm from a pile of independent actors into a coordinated system.

Why duplicate execution is also a cost and governance problem

Every duplicate run burns tokens, compute, and tool-call quota, and across a team running agents hundreds of times a day, that's not a rounding error. It compounds the way any unmetered waste compounds: quietly, until the aggregate shows up large enough to notice on a bill.

The deeper issue is that duplicate spend is invisible without per-run attribution. A dashboard showing total spend climbing can't distinguish growth from new, legitimate work versus growth caused by a third of the runs being duplicates of runs that already completed successfully. Catching that requires run-level cost tracking tied to a specific run ID, not an aggregate token count rolled up across a team or a project.

The governance dimension underneath the cost one deserves equal weight, and treating it as a footnote is the mistake most teams make. Per the EY/AIUC-1 Consortium survey published in Help Net Security in March 2026, only a minority of organizations monitor AI traffic end-to-end across prompts, tool calls, and outputs. If a duplicate run makes an unauthorized write, or reaches a resource the original run was never supposed to touch, that event exists somewhere in the logs, but only if every tool call gets captured at the session level in the first place. Scoped credentials that expire at the end of a session limit the damage a runaway duplicate can do; a credential minted for run A cannot be reused by duplicate run B, which caps the blast radius even when deduplication itself fails.

A hard budget cap, per session or per trigger, is worth having as a backstop, and it complements deduplication well. A cap stops a runaway duplicate from consuming unbounded resources, but it does nothing to prevent the duplicate from starting in the first place, so it should never stand in for deduplication itself. By the time the cap trips, the duplicate invoice or the double notification has usually already gone out.