Transactional outbox pattern: stop losing AI handoffs

Start with the gap between two successful steps

Illustration, not a customer case: an AI-assisted service desk records an approved service request and then tells a scheduling system to assign a technician. The database update succeeds, but the process stops before sending the scheduling event. Staff see a saved request, yet no scheduling work begins.

Changing the order creates a different risk: the scheduling system could receive an event for a request that never commits. Engineers often call this the dual-write problem. In Chris Richardson's description of the transactional outbox pattern, the service stores the message in its database as part of the transaction that updates the business data, and a separate message relay then sends it to the message broker. See the pattern source below, checked on 11 November 2026.

Our recommendation is to identify the precise business transition that creates the obligation. The event should come from validated application logic after permissions and business rules are checked, not merely from an agent saying that it finished.

Check the transaction boundary before adding a table

For the example, both the service-request update and its outgoing event must participate in the same local transaction. An unrelated event table written afterward recreates the gap. Ask the engineer to show what commits together and what happens if either write fails.

A wrapper around an external legacy API cannot automatically include that remote update in its own database transaction. If the legacy system owns the change, investigate a supported event mechanism, a suitable change feed or an explicit reconciliation process. Treat these as integration options to verify, not interchangeable guarantees.

Before adopting the pattern, write a boundary note: which system owns the record, where the transaction ends, who publishes the event and who confirms the next business step. If that boundary cannot be explained, adding an outbox can create false confidence rather than dependable continuity.

Outbox pattern best practices: track the whole handoff

The same description notes that the relay can publish a message and crash before recording that it did so. After a restart it may publish the same message again, so the pattern requires an idempotent consumer: one that can receive a duplicate without repeating the business effect.

We recommend stable event identifiers and separate statuses for local commit, publication and downstream completion. Broker acceptance is not proof that a technician was assigned. If the consumer writes to its own database, review how it coordinates duplicate detection with the business update. A standalone 'already seen' check can leave its own failure gap.

For changes to the same business record, define how sequence and record version affect processing. An old event should not silently overwrite a newer state. Also decide how failed events are inspected and retried without generating a fresh business request. The agent can explain a pending handoff, but should report only the state supported by records.

Test the missing event, not just the happy path

Use synthetic data in an isolated environment. Interrupt the process before commit, after commit but before publication, and after publication but before the relay records success. Inspect both the saved request and the downstream outcome. The goal is to demonstrate the intended behavior at each boundary, not merely a successful final log line.

Our acceptance checks also include a consumer outage, duplicate delivery and an event too old to apply automatically. Assign an owner to the oldest unresolved event. Monitor backlog age, publication failures and completed downstream work, and define retention rules that preserve enough evidence for investigation.

Avoid an indefinite accumulation of event payloads. Keep only the data needed for the handoff and its operational record, with appropriate access restrictions. Measure the relay's load on the business database before choosing polling frequency and batch size.

Keep the improvement inside ongoing engineering ownership

Start with one important transition rather than converting every interaction to events. If the next step is not required, or an existing supported mechanism already provides the needed evidence, another delivery subsystem may add unnecessary maintenance.

AI coding tools can help an experienced developer build the implementation quickly. Engineers still need to validate transaction boundaries and operate recovery. UVISION provides dedicated developers and managed projects with at least one full-time developer per project, combining long-term maintenance of critical legacy systems with continued development and AI integration. The useful deliverable is a handoff the team can explain, test and maintain.