Ask how to deploy an AI agent and you'll get a framework answer: LangGraph, CrewAI, the Agents SDK, a graph of nodes. But the framework is the inside of the run. The decision that actually shapes the agent's behavior in production is the one nobody frames as a decision — how the run gets started in the first place.
There are three real answers: a clock, an event, or a queue. And the thing worth internalizing is that the choice you make there, not the library you wrote the agent in, determines what happens when the agent crashes, when it's slow, when the same input arrives twice, and when a hundred inputs arrive at once.
The trigger is where retries, durability, and concurrency come from. The framework is just what runs once the trigger has already decided the rules.
Cron: the clock that lies about "once"
A scheduled trigger looks like the simplest case — run the agent every hour, every night. The hidden complexity is in two words: overlap and missed.
Overlap is when the 2:00 run is still going when the 3:00 tick fires. Missed is when the platform was down at 3:00 and the tick never happened. Different schedulers answer these differently, and the differences are not cosmetic. Google Cloud Scheduler delivers jobs at least once, so a single scheduled tick can invoke your agent more than once — your handler has to be idempotent or you'll double-send that nightly digest. Inngest, by contrast, queues missed scheduled runs and catches them up rather than silently skipping them. "It ran, once, on time" is not a property you get from the word cron; it's a property you select by choosing a scheduler and then designing around its guarantees.
Webhook: the trigger that can't wait for the agent
A webhook trigger starts the agent from an inbound event — a new message, a payment, a pull-request comment. It is the most natural fit and the one that breaks first, because of a timing mismatch nobody designed on purpose:
- The sender times out fast. Webhook providers expect a response in seconds and retry if they don't get one.
- The runtime caps execution. AWS Lambda's hard ceiling is 900 seconds — 15 minutes.
- The agent is slow. A few reasoning turns and tool calls can blow past both.
Process the agent inside the webhook handler and you get the worst outcome: the run is still going, the sender decides delivery failed, it redelivers, and now the agent is running twice on the same event. The fix is the same everywhere and worth memorizing as a rule: verify the signature, enqueue the job, return 200 immediately, and run the agent in the background. Which means a serious webhook-triggered agent isn't really webhook-triggered. It's queue-triggered, with a webhook out front.
Queue: where durability actually lives
This is the trigger that pays rent. A durable message queue gives you, at the substrate level, the exact properties an agent needs and that are painful to hand-roll:
- At-least-once delivery. The message stays on the queue until the consumer acknowledges success. An agent that crashes mid-run doesn't lose the work — the message reappears and another worker picks it up. (Cloudflare Queues and AWS SQS both deliver at least once.)
- Visibility timeout. While one worker holds a message, it's hidden from others so two agents don't process the same input concurrently. SQS lets that window run up to 12 hours — enough to cover a genuinely long agent run.
- Dead-letter queues. After N failed attempts, the message moves to a DLQ for inspection instead of poisoning the worker forever.
- Consumer concurrency limits. Cap how many agent runs execute at once and you've implemented backpressure and rate-limiting — protecting both your model quota and your database — without writing a token bucket.
None of that is in your agent code. It's in the queue. Swap LangGraph for CrewAI and every one of those guarantees still holds; remove the queue and every one of them evaporates.
Durable execution sits on top, it doesn't replace
This is where engines like Temporal, Inngest, and Restate, plus Cloudflare Workflows and Trigger.dev, come in — and where they're easy to misunderstand. They add within-run durability: each completed step is checkpointed, and after a crash the run replays, skipping finished steps and reusing their results, so the agent doesn't re-call the tool it already called. They standardize retry policy too (Temporal activities retry with exponential backoff by default). EventBridge will retry a target up to 185 times across a 24-hour window before giving up.
But notice what they are: a layer on top of a trigger, not a substitute for one. You still decide whether the workflow is kicked off by a schedule, an event, or a queue — and that decision still sets the outer delivery semantics the durable engine operates inside.
The actual decision
Stop asking "which agent framework," at least first, and ask "what starts this run, and what failure semantics do I want for free?"
- Recurring, time-driven work → cron, and make the handler idempotent because the clock lies about "once."
- An external event must kick it off → webhook, but immediately hand off to a queue, because the agent outlives the request.
- You want retries, backpressure, and controlled concurrency without writing them → queue, every time.
This pairs with the other half of the deployment question — where the agent actually runs, which decides how long a single run is allowed to live. Trigger and runtime together set the agent's whole operational envelope.
The framework decides how the agent thinks. The trigger decides whether it survives.
