Agents started by events and schedules

In production, agents rarely start because a person typed into a chat window. They start because something happened: SAP marked a container as delayed, a ServiceNow incident was reassigned, a customs file landed in an SFTP folder, or a schedule said "every 15 minutes, re-check open exceptions". The trigger layer turns those signals into agent work, and it has to do so exactly once in effect, even though almost every delivery mechanism delivers at least once, sometimes out of order, sometimes in bursts of hundreds. So you design an event envelope with a stable ID and a business key, make every consumer idempotent, bound retries and park poison messages in a dead-letter queue, keep ordering only where the business needs it, group correlated bursts before they fan out, run schedules with explicit time zones and overlap policies, and hand each unit of work to a durable workflow whose ID makes duplicates impossible. And you decide, in writing, what is never allowed to trigger an agent.

Key takeaways:

• Assume at-least-once delivery everywhere. Idempotency is the consumer's job.
• The deduplication key is the event's identity (source plus ID), and the workflow ID is the business identity. You need both.
• Order per business key, not globally. Global ordering is expensive and rarely needed.
• Debounce correlated bursts: one vessel re-sequence should start one batch, not 180 crews.
• Every schedule needs a time zone, an overlap policy and a catch-up policy written down.