News Monitoring Agents: Retry the Job Without Sending the Alert Twice

A news monitoring agent can finish its research, send an alert and lose the delivery response. If the job restarts, “try again” may send the alert twice. If the application marks the alert as delivered before sending it, the job may crash and lose the notification.

Snowflake’s November 3, 2026 announcement makes this a practical design question for recurring agents. It announced the general availability of CoCo Automations, which include task history, audit trails and reruns. The same announcement says CoCo and CoWork Bots would enter private preview soon. Scheduling work and recovering a run leave an application-level question: what happened at the destination?

I would keep the decision to notify separate from the action to deliver. Notification services should save the approved notification as durable application state. A restarted agent should retrieve the record, rather than creating a new notification.

An article identifier is not a delivery receipt

Webz.io’s News API provides structured articles with a unique post UUID, source URL, text and publication metadata. Your application can recognize an article and retain its source context. This does not indicate whether your email or messaging service accepted your notification.

It makes a difference even with a single article. With this constructed example, a monitor discovers article A-17 about a watched supplier and approves an alert for the operations team. The sender submits it to a notification service. That service accepts the request but breaks the connection before the sender receives an acknowledgment.

The next request retrieves A-17 again. A new run identifier makes the execution trace different, but does not make the intended alert different. Generating another summary or a new timestamp should not silently authorize another send.

Choose the notification identity before delivery

For this monitor, define one initial alert per tenant, watchlist entry, article UUID, and destination. Store that combination under a database uniqueness constraint. Two workers racing to approve the same alert should resolve to the same record.

This is an article-level rule, not a generalization that every article represents a distinct event. Webz.io’s article on duplicate news states that multiple articles may be published about the same event. If your product alerts on events, resolve event grouping before choosing the notification identity.

For the alert, store the chosen payload. When a retry is needed, the model should not create a new payload based on its interpretation of the original intent. An intentional correction needs a separately defined revision and an explicit policy for sending it.

Commit the alert and a pending delivery request in the same database transaction. A different processor can handle the requests that are pending. AWS’s transactional outbox pattern states how to handle inconsistent database writes and message notifications. This guidance cautions that messages can be duplicated, so the application needs to have its own mechanism for handling message duplication.

An outbox solves one failure case: the application can recover the approved alert that was not sent. It does not, however, make the external email or messaging operation part of the transactional integrity of the database.

Resolution of an uncertain send at the destination

For A-17, keep the same notification ID for all retries. If the destination supports idempotency keys, use the documented mechanism and check the retention policy and payload. Do not assume that an arbitrary request header makes the operation idempotent.

If the service allows lookup by the request reference, resolve the timed out request. A confirmed acceptance can update the alert. Retain the destination’s reference so an investigator can look it up later.

When neither suppression of duplicates nor a reliable lookup is available, the timeout remains uncertain. Choose explicitly whether to retry and accept possible duplicates, or hold the alert for reconciliation and accept a delay. A local sent flag cannot remove this trade-off.

Use status to express evidence. In this example: “A-17 alert approved; attempt 1 timed out; destination acceptance unknown; retry held for reconciliation.” Use the term “delivered” in conjunction with the evidence that the destination confirmed. Acceptance by a service does not indicate the recipient has seen the message.

Test the crash after acceptance

You can use an article fixture and a notification endpoint that you control. Configure the endpoint to accept the A-17 alert, capture its identity and drop the response. Restart the worker with the same pending record. Check if the endpoint recognizes the repeated identity and if the application reconciles its state.

Test with two concurrent workers and a crash before the alert transaction commits. The first test should not allow two logical alerts. The second test should not leave any partially committed alerts.

Finally, test an actual correction to A-17. Verify your revision rule allows the actual correction and does not allow an ordinary retry to count as a correction. Analyze the stored payloads, and the endpoint records, not the agent’s account of its actions.

Webz.io’s adverse-media monitor tutorial covers retrieval, saved article identifiers and recurring searches. A delivery path in production needs to test for this additional failure: after the sender loses its reply, can a different worker determine whether to retry, reconcile or wait?