> ## Documentation Index
> Fetch the complete documentation index at: https://docs.duvo.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Choosing How Your Agent Starts
> Manual Start Work, schedules, triggers, and Queues each fit a different shape of work. The start mechanism decides latency, retries, and what happens when Runs overlap.
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
```mermaid theme={"dark"}
flowchart TD
A[How does this work arrive?] --> B{Reacting to an event in
a connected service?}
B -->|Yes| C[Event trigger]
B -->|No| D{A stream of discrete items
that each need tracking?}
D -->|Yes| E[Queue + consumer Agent]
D -->|No| F{On a clock?}
F -->|Yes| G[Schedule]
F -->|No| H[Manual Start Work
or API]
```
| Mechanism | Fires | Best for | Watch out for |
| -------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------- |
| **Manual Start Work** | When a person clicks | Building, testing, one-off jobs | Everything downstream of a person remembering |
| **[Schedule](/user-guide/assignment-features/scheduling-assignments)** | On a clock, in your timezone | Recurring reports, syncs, checks | Overlapping ticks are skipped; missed ticks aren't backfilled |
| **[Event trigger](/user-guide/assignment-features/event-driven-triggers)** | New email, Slack message, Linear event, file drop, status change | Reacting to things as they happen | Polling triggers react on an interval, not instantly; set up per user |
| **[Queue](/user-guide/assignment-features/case-queue)** | A Case arrives or comes back | Streams of items needing per-item tracking and retries | One consuming Agent per Queue |
| **[API](/user-guide/running-assignments/running-assignments-via-api)** | Your system calls Duvo | Embedding Duvo in existing software | The caller owns retries and deduplication |
## 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](/user-guide/assignment-features/assignment-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](/user-guide/running-assignments/running-assignments-via-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](/best-practices/reliable-connections).
## 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](/best-practices/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
Frequency presets, cron expressions, and timezone setup.
Every trigger type with latency, dedup, and retry behavior.
Producer/consumer design and the rules that keep a Queue healthy.
Why the schedule's creator determines what a Run can access.