Give an agent one durable job per incoming message

A messaging agent spans a provider, an event consumer, a model and a sending path. Each can fail independently.

Accept and record the event

Verify a webhook according to the provider’s current signing guide, then persist the message identifier and conversation before starting expensive processing.

A repeated delivery should point to the same application job. Do not deduplicate solely on message text; two legitimate customer messages can contain the same words.

Separate drafting from sending

Store the generated draft and the action decision independently. That lets an operator review a draft and lets a recovered worker know whether it has already attempted the send.

Use the provider’s current idempotency and status behavior where documented. The application must still preserve its own message-to-job relationship.

Treat uncertainty as a state

A network timeout can happen after the provider accepts the action. An immediate retry may therefore create a duplicate. Look up the known action or route the uncertainty for review.

Do not report a queue acceptance as a delivered or read message. These states answer different questions and deserve different operational labels.

Exercise recovery before launch

Use owned traffic to interrupt processing after event persistence, after draft creation and after the send attempt. Observe whether recovery creates exactly the intended actions.

This is an implementation checklist rather than a benchmark performed by the publication. The source reviews explain which provider paths are documented, and the team should validate the chosen current account.