Choosing How Your Agent Starts

How an Agent starts is a design decision, not an afterthought. The start mechanism determines how fast the Agent reacts, what it receives as input, what happens when two Runs would overlap, and whether a missed event gets a second chance. This page helps you pick deliberately.

​

The Decision in One Pass

​

Schedules Skip, They Don’t Stack

Two facts about schedules shape how you should design for them:

• If the previous Run is still going when the next tick fires, the tick is skipped — Runs never stack up behind each other. A schedule whose work regularly outlasts its interval doesn’t run more often; it runs less predictably.
• Missed ticks are not backfilled. A tick that doesn’t fire is gone; the next one fires on its own time.

The design that survives both: make every scheduled Run self-healing. Instead of “process the last hour of orders”, write the AOP as “process everything new since the last successful Run”, tracking the last-seen state in Agent Memory. Then a skipped or missed tick costs latency, not data. Also worth knowing: each schedule has its own timezone, and schedules created through the API can carry an optional task prompt that is added to the Run when they fire — useful when several schedules on one Agent should emphasize different work.

​

Triggers: Expect Once, Design for Twice

Duvo tracks which items a trigger has already fired for, so a matching email or message normally starts exactly one Run. Still, write the AOP as if an occasional duplicate can happen — have it check whether the record it is about to create already exists before creating it. Cheap insurance, and it also makes manual re-runs safe. Things trigger authors regularly trip over:

• Enabling a trigger does not process the backlog. On first activation, existing items in the inbox or folder are marked as seen without firing — only new items from that point on start Runs. If the backlog matters, have someone Start Work once manually to work through it.
• The event arrives as the Run’s opening message. The triggering email, message, or file lands as input on top of the AOP — so the AOP should say what to do with “the item in this Run” rather than instructing the Agent to go find work.
• Triggers are personal. Each trigger watches its creator’s account and its Runs use that person’s access — see Connections and Logins That Don’t Break.

​

Queues When Items Matter Individually

If each item needs its own record, its own retry story, and its own outcome someone can review, a trigger that just starts a Run isn’t enough — put the items in a Queue as Cases and give the Queue a consumer Agent. You get per-Case status, postponing, and parallel processing for free. The design rules for that live in Designing Work Around Queues and Cases. One rule to repeat here because it fails confusingly: a Queue should have exactly one consuming Agent. When two Agents both have triggers on the same Queue, Duvo refuses to pick a winner and conflicted Cases don’t run at all. The setup flow warns you when you’re about to create this situation.

​

When a Start Fails

A Run that starts and fails is not automatically retried — for schedules the next tick simply fires on time, and for Cases you can reprocess from the Queue. Design recovery into the mechanism you chose (self-healing schedules, reprocessable Cases) rather than assuming the platform replays failures. There is one automatic guard: a schedule or trigger that keeps skipping because a required Connection is missing gets auto-paused, and its owner is emailed. Reconnect the account and switch it back on.

​

Related