How Superintelligence Works | Agent Transactional Outbox — Database Writes, Reliable Events and Dual-Write Recovery

Did you know that an AI agent can successfully save a school notice and still fail to tell the next system it was saved? Modern applications often need to do two things for one user request: commit a record in a database and publish a message so another service can update a search index, send an approved notification or perform another step. A crash between those actions creates a dual-write problem. The transactional outbox pattern protects the relationship between the saved business change and the durable intention to send its event.

The method is to write the application state and an event record within the same properly scoped database transaction, then use a separate, monitored relay to publish committed outbox records to a broker. Delivery can be repeated, so downstream consumers must handle duplicates safely. The workflow still needs current authorisation, source versions and independently verified external outcomes. This chapter develops an original 120-change laboratory, a second school-publishing transfer exercise and a practical testing plan. The example numbers are invented—not measured eduKate operations, live model benchmarks or evidence that artificial superintelligence already exists.

Read this as part of How Super Intelligence Works. The Event-Driven Agents guide explains callbacks and duplicate delivery, while Agent Sagas covers recovery across several real-world services. Here the specialist focus is one database boundary: recording a business change and its outbound event reliably together, without falsely promising that all downstream services completed atomically.

Find your reading route

• New to event-driven agents? Start with the dual-write gap and the atomic local transaction.
• Building an outbox relay? Focus on event IDs, polling versus change-data-capture, replay and per-resource ordering.
• Learning Mathematics? Recalculate the 120-change laboratory and the forty-worksheet transfer.
• Responsible for publishing? Follow approval binding, consumer verification and safe reconciliation after uncertain results.

Contents

• 1. The dual-write gap is a real window for disagreement
• 2. Atomic local recording changes the failure shape
• 3. Outbox events need stable, meaningful identities
• 4. Transactional scope is narrower than the business process
• 5. A relay turns durable intent into outbound delivery
• 6. At-least-once delivery implies possible duplicates
• 7. Consumers need an idempotent outcome contract
• 8. Ordering matters within the right aggregate
• 9. The event body should be narrow and privacy-conscious
• 10. Publisher acceptance is not consumer completion
• 11. A fictional 120-change outbox laboratory
• 12. Use a reconciliation table, not one green badge
• 13. Test crashes at the four decisive moments
• 14. Polling and change data capture need different operations
• 15. Poison messages and dead-letter queues need decisions
• 16. Source updates still need current user permission
• 17. Original event ordering protects cancellation and revisions
• 18. Changed-context school-publishing exercise
• 19. How to explain these ideas to students and parents
• 20. A practical deployment checklist for one small system
• 21. Limits and the most important promise
• Frequently asked questions
• Primary technical documentation
• Related specialist guides

1. The dual-write gap is a real window for disagreement

A writing service might first commit a document to a relational database and then send `DocumentUpdated` to a broker. If the process crashes after commit but before publishing, the source database has the new document while the search index or approval service never hears about the change. Users can see an old version in one place and the correct new version in another. The model may be innocent of the infrastructure failure and still produce misleading information from stale downstream data.

Reversing the order is not a general solution. If an event is sent first and the database transaction then fails, another service may act upon a business change that did not commit. A school-notification worker could tell parents an event date changed even though the authoritative timetable still shows the old date. Either order leaves a failure window when the operations belong to different independent systems.

AWS Prescriptive Guidance identifies this as the dual-write problem and describes the transactional outbox pattern as a way to keep the source update and an outbox record within one database transaction. That local atomicity is the important promise. It does not mean the broker, email system, search index and WordPress site all participate in one global transaction.

Start with the actual user task. A teacher may need one approved current notice saved and later reflected in a search service. The database commit may establish one milestone; broker publication another; actual downstream projection or public delivery another. The agent should distinguish these milestones rather than collapse them into a single sentence saying every part of the workflow is finished.

Return to contents or continue to Atomic local recording changes the failure shape.

2. Atomic local recording changes the failure shape

The application writes the business record and a corresponding outbox event in the same local transaction. If validation fails, both changes roll back. If the transaction commits, both the new state and the pending event exist durably under that database’s transaction guarantee. The independent relay can find the event after the original application process exits. This prevents the lost-intention gap inherent in saving state and only later deciding to publish an event.

Imagine a fictional update to lesson L-42, moving its review status to Approved. Inside one transaction the system stores the new status and an event record bearing source ID L-42 and source revision 5. If the transaction aborts, the outbox record must not survive alone. If it commits, the eventual relay can find the event even if the caller timed out immediately after the commit.

Microsoft’s Dataverse transactional-outbox reference architecture uses a synchronous plug-in to create the outbox row as part of the originating data transaction and an asynchronous component to send events to Azure Service Bus. The documented example illustrates local atomicity and asynchronous delivery. Its details are specific to that platform, but the design lesson transfers to other transactional data stores with suitable capabilities.

Keep the transaction short and precise. It should validate the relevant business change and insert the durable event record; it generally should not wait for a distant network broker or email provider to respond while holding database locks. Network operations can be slow or uncertain. The outbox relay exists partly to decouple that external work from the local commit.

Return to contents or continue to Outbox events need stable, meaningful identities.

3. Outbox events need stable, meaningful identities

A useful outbox row has a unique event identifier, event type, aggregate or resource identity, payload and enough ordering or schema information for its consumers. The Debezium Outbox Event Router documentation describes a typical relational table with columns such as `id`, `aggregatetype`, `aggregateid`, `type` and `payload`. Its event ID can support duplicate detection, while the aggregate ID can be used as a broker key for partitioned ordering.

An event ID identifies the event record, not every conceivable user operation. A single school-notice update may generate one event consumed by several services. The public publishing system might also have its own stable operation ID for the action it performs. Keeping source event, logical user task and downstream effect identities distinct makes retries and reconciliation safer.

Do not use a document’s display title as its only identifier. Two schools may have a notice called Mathematics Workshop, and the same notice can change title while retaining its source identity. Use stable internal resource IDs and trusted tenant scope. A generated title or URL slug can be human-friendly, but it is not necessarily a safe authorization or deduplication key.

Version the event contract. A consumer that expects `status=approved` might misinterpret a new enum value or source revision format. The publisher should record what business change occurred, not just a model-generated summary claiming that something important happened. An unexpected event schema needs a controlled compatibility decision rather than being silently mapped to Success.

Return to contents or continue to Transactional scope is narrower than the business process.

4. Transactional scope is narrower than the business process

A relational database transaction can include records stored under the same transactional resource and its specified isolation semantics. It cannot ordinarily atomically commit a remote email send or a separate WordPress publication without additional coordination. The outbox guarantees a durable event intention when the source commits, not that every consumer observes or finishes the event instantaneously.

Azure Cosmos DB’s transactional-batch example makes a particularly useful scope distinction: its batch can atomically write a business document and outbox event when both lie within the same logical partition key. Storing them in unrelated partitions or in two separate services does not automatically inherit that guarantee. An implementation must use the exact transaction boundary its datastore truly supports.

Separate storage semantics from user promises. A parent may ask whether a revised syllabus notice is now visible on the public site. An internal source update with a matching committed outbox event is not yet a public publication. The agent should wait for the relevant published resource and independently read its actual status or explain that the update is pending.

If the task includes another consequence, such as notification to a recipient, current human approval applies to that separate effect. A model cannot use the fact that one database transaction committed to invent permission for sending emails. The event may trigger a permitted review queue while final transmission stays gated by the user’s current recipient-bound decision.

Return to contents or continue to A relay turns durable intent into outbound delivery.

5. A relay turns durable intent into outbound delivery

After commit, a worker or change-data-capture connector finds outbox entries and publishes them to the broker. There are common variants: polling an outbox table for pending records or tailing a database change log that includes committed outbox inserts. Both aim to deliver events after the local transaction is durable without forcing the original request to synchronously contact the broker.

A polling relay must select entries safely when several workers run concurrently. Depending on the datastore and implementation, claims or leases can prevent avoidable duplicate concurrent processing, while bounded retries and visibility timeouts help with recovery. These controls reduce waste but cannot remove all uncertainty about messages already accepted by the broker before the relay lost its acknowledgement.

Debezium’s Outbox Event Router is a documented change-data-capture approach. It expects inserted event rows in the outbox table and can route messages using aggregate information. Its transform is designed around a particular table pattern rather than arbitrary updates to an outbox row. An engineer should not mix its insert-only assumptions with a custom polling design that frequently rewrites status in the same table without understanding the connector.

Either way, relay success is one milestone. The broker may acknowledge the event, but a downstream indexing or communication service may still be processing it. A useful observability design records the source transaction, relay progress, broker admission and consumer outcome with separate statuses and stable identities.

Return to contents or continue to At-least-once delivery implies possible duplicates.

6. At-least-once delivery implies possible duplicates

Suppose the relay publishes event E-51 and the broker accepts it. The relay crashes before it can persist a record that publication succeeded. On restart, it finds E-51 still pending and sends it again. Both deliveries may be authentic and refer to the same original source change. That is a natural at-least-once failure mode, not necessarily an attacker or malformed event.

AWS Prescriptive Guidance and Microsoft’s transactional-outbox examples both warn that repeated delivery is possible and recommend idempotent consumers. The outbox pattern closes one lost-message window but does not generally provide magical exactly-once effects across every downstream service. A user-facing action can be duplicated if the consumer simply executes a side effect on every received copy.

Use the event’s stable ID for deduplication where appropriate. A consumer may store a processed-event record atomically with its own local state change. If it sees the same event again, it can return the existing result rather than send another message or increment a count twice. The exact mechanism depends on whether the consumer’s effect and deduplication record share a real transaction boundary.

Some platforms offer broker-level duplicate detection or ordered sessions. Those features can help within their documented scope but do not automatically prevent a downstream service from repeating an unrelated API call. Test the actual effect. A broker reporting one accepted message does not prove one externally visible email was sent and no duplicate escaped.

Return to contents or continue to Consumers need an idempotent outcome contract.

7. Consumers need an idempotent outcome contract

An idempotent consumer produces the intended business result once even when the same event is delivered repeatedly under its declared rules. This is more specific than ignoring every event with a familiar source title. Two legitimate revisions of one school notice need to be processed separately, while a repeated delivery of revision 5 should not create a second public article.

A practical receiver checks source event ID and resource revision before performing its own side effect. If the local database supports a suitable transaction, it can record the processed event together with the resulting state update. If the effect occurs in another provider, it should use a stable logical operation key and reconcile the target before creating another resource.

Think of a WordPress publisher. An event saying approved article P-41 revision 5 is ready should map to one canonical post identity. If the consumer times out after publication, a retry should inspect the original post ID or slug before creating anything. A duplicate with a suffixed URL is not a valid improvement just because the agent can report two successful API calls.

Idempotency cannot substitute for authorization. A correctly deduplicated event for another tenant’s private file is still not permitted to expose that file. The consumer must check current identity, source scope, intended target and any human approval required for the downstream action. A valid event ID establishes identity for the event, not universal permission.

Return to contents or continue to Ordering matters within the right aggregate.

8. Ordering matters within the right aggregate

Consider an education record progressing from Draft to Approved and then Cancelled. If the consumer processes a delayed Approved event after the newer cancellation, it could mistakenly re-enable an action that should remain stopped. Unique event IDs do not solve this ordering problem. The consumer needs an applicable revision or sequence rule so older state cannot overwrite a newer authoritative decision.

Debezium’s outbox router uses the `aggregateid` as an event key by default, which can help preserve order for related events within a Kafka partition. That is not a guarantee of one total order across all independent records and downstream systems. The application must define which aggregate’s event sequence matters for the user task.

Azure Service Bus sessions can provide ordered processing under a consistent session identity, as Microsoft’s architecture guidance explains. A school notice can use a stable document ID as the grouping identity in an appropriately configured design. Still test how a retry, dead-lettered message or disconnected consumer affects the observed sequence. One late record should not override a newer confirmed decision.

Temporal semantics are part of the state. An event may be issued on Monday but effective next term, and a delayed event can be historical rather than current. Store the relevant business effective date and version where appropriate. Arrival order, emission order and effective authority are different dimensions; a model should not blend them into a one-line assertion of latest.

Return to contents or continue to The event body should be narrow and privacy-conscious.

9. The event body should be narrow and privacy-conscious

An event often needs a stable resource identity, change type, revision and enough context for the consumer to fetch authorized details. It does not always need the entire underlying school file, student’s personal notes or user’s conversation. Copying all source content into broker messages can create another broadly accessible data store with its own retention and data-location risks.

Prefer minimal payloads when consumers can re-read the necessary data securely under current permission. The alternative of self-contained event snapshots can be appropriate for specific integration contracts, but then classify and protect the information accordingly. A message bus is not automatically a safe place for raw private parent correspondence merely because the service is internal.

Protect credentials. An outbox row should not contain the model’s API key or a temporary private download token just to make the relay convenient. Give the relay its own narrowly scoped broker identity. Give consumers their own authorized source-read capabilities. An event created under one tenant must not cause a consumer with a broad shared credential to read another tenant’s records.

Audit the information flow, including change-data-capture, broker topics, replay storage, dead-letter queues and monitoring. A debugging tool that prints full payloads can undo careful minimization at the producer. Record safe event IDs, statuses and resource references; use controlled access for any sensitive evidence a qualified investigator genuinely needs.

Return to contents or continue to Publisher acceptance is not consumer completion.

10. Publisher acceptance is not consumer completion

A successful local transaction means the business record and event intention were committed. A successful relay acknowledgement means the broker accepted the event under its stated semantics. A consumer’s processed acknowledgement may mean it updated an internal projection. A final user’s requested external effect, such as a public article or transmitted confirmation, can require a further independently checked destination state.

Give these milestones distinct names: Source Committed, Event Pending, Broker Accepted, Consumer Applied, External Effect Verified and Unknown. They need not all appear in the user interface, but their meanings should remain available to the controller. One `success=true` flag shared across all layers invites incorrect final answers.

A search-index consumer might process the event but lag before a query reflects the new document. That is an eventual consistency problem, not necessarily failure of the source transaction. A public publishing worker might be waiting for valid human approval. The event’s successful delivery does not make these downstream obligations disappear.

Use a verified result tied to the original user intention. If the user requested four articles, they need four actual live links with correct content and metadata, not simply four event IDs in a broker. A system can truthfully say that an outbox event was queued while declining to claim publication until the destination confirms it.

Return to contents or continue to A fictional 120-change outbox laboratory.

11. A fictional 120-change outbox laboratory

Consider a fictional Cedar Learning Workflow with 120 intended business changes. Seventy-four have a committed source update, delivered event and independently verified downstream state. Eighteen are committed with events still waiting for relay or broker processing. Twelve have reached consumers but remain awaiting final effect verification. Ten attempts were properly rejected or rolled back, leaving no committed source change and no matching committed outbox event. Six have uncertain external acknowledgement or final-state evidence.

Check the exclusive categories: 74 + 18 + 12 + 10 + 6 = 120. Fully verified outcomes are 74 ÷ 120 ≈ 61.67%. Pending relay or broker work is 18 ÷ 120 = 15%. Consumer-applied-but-not-finally-verified work is 12 ÷ 120 = 10%. Correct rollbacks are 10 ÷ 120 ≈ 8.33%, while unknown evidence is 6 ÷ 120 = 5%. The small differences from one hundred in displayed percentages are rounding, not lost cases.

These are invented counts of logical business-change attempts, not real agent performance or broker availability. A correct rollback may protect source consistency even when it did not complete the user’s request. A pending event is not proof the eventual email was sent. A consumer-applied update still needs final-state verification if the user specifically asked for a public saved artifact.

The lesson of the ledger is why operational categories matter. A dashboard reporting 104 successes by adding verified, pending and consumer-applied outcomes would overclaim user completion. Another dashboard counting every unresolved state as an immediate failure might initiate dangerous duplicate sends. The next action depends on trustworthy evidence of the specific stage.

Return to contents or continue to Use a reconciliation table, not one green badge.

12. Use a reconciliation table, not one green badge

A useful table shows planned source changes, committed events, relay state, consumer state, target readback and current task authorization. A single summary column can then be computed from these facts without replacing them. A source row that committed while its outbox event waits is an internally consistent pending workflow, not a lost event if the event record is durably stored.

The ten rolled-back cases in the fictional ledger should have no committed business change or matching committed event under the exercise’s declared atomic transaction. An event observed downstream for one of them would be a serious contradiction worth investigation. This is an invariant that independent tests can verify without asking the AI model whether it followed the right plan.

Unknown acknowledgement needs its own branch. The relay may have published an event before losing the broker response, or the consumer may have acted before its receipt was lost. Reconciliation by event ID, consumer receipt and actual resource state is safer than assuming either that nothing happened or that everything finished. Avoid creating a new event ID for a mere retry of the same logical change.

Keep protected information out of the general operations table. It may be enough to record source ID L-42, revision 5, event E-51 and verified target ID P-41. A qualified reviewer can fetch content through its authorized system when needed. A reliable ledger should expose causality and user outcome without becoming a second copy of every private source document.

Source-to-consumer status	Cases	Share	Required check
Verified source and downstream result	74	61.67%	Final target checked
Committed with event pending	18	15.00%	Relay or broker work pending
Consumer-applied; final outcome unverified	12	10.00%	Check requested external effect
Transaction rejected or rolled back	10	8.33%	No committed source or event
External evidence unknown	6	5.00%	Reconcile original event and target
Total logical changes	120	100.00%	Fictional laboratory denominator

Return to contents or continue to Test crashes at the four decisive moments.

13. Test crashes at the four decisive moments

Construct a controlled test that can stop an application immediately before the source transaction commits. Under the expected semantics, neither the new business state nor its matching event should be visible. Now stop just after commit but before the relay runs. Both source state and pending event should remain durable, allowing a later worker to resume delivery.

Next, simulate a relay that has sent the event to a broker but loses the acknowledgement. The resumed relay might send the event again; the test should verify that a consumer’s idempotency mechanism prevents duplicate downstream business effects. Finally, simulate a consumer that completes its local update but loses its acknowledgement. A repeat delivery should not apply the same source change twice.

Keep these tests inside an isolated environment with invented student and document identifiers, fake email endpoints and controlled provider responses. An intentionally crashed service should not touch real WordPress public pages or parents’ inboxes. The expected outcomes come from actual simulated database, broker and target state, not from the tested model’s generated description.

These failure-injection points expose different mechanisms. The first two validate the local transaction and durable event recording. The third and fourth validate relay and consumer recovery. A passing schema validation or happy-path demo does not prove any of them. Preserve the exact failing condition as a regression test before enabling the affected production workflow.

Return to contents or continue to Polling and change data capture need different operations.

14. Polling and change data capture need different operations

A polling relay selects pending outbox records, sends them and advances its progress. The implementation must deal with multiple workers, leases or claims, batching, fair retry and potential lost acknowledgements. A worker crash can leave an entry pending; the next worker should recover without creating a second logical event. A suitable schema and transaction design determine how the poller safely moves through records.

Change-data-capture observes committed database changes from a log or change stream and emits events. It can avoid frequent application polling, but introduces connector health, offsets, snapshot state and schema compatibility requirements. The Debezium event router has its own documented assumptions, including the basic outbox table shape and how to route by aggregate.

Choose a mechanism according to the actual database and operations team rather than a trend. A small site with modest event volume may prefer a simple reliable polling service, while an established change-data-capture platform can integrate with existing event infrastructure. Neither architecture is automatically correct if its consumer ignores duplicates or if the source transaction does not actually cover the outbox insert.

Monitor whichever relay exists. Track old pending events, time since source commit, publish attempts, broker acknowledgements and connector offsets. An empty backlog may mean everything delivered, or it may mean the relay stopped discovering committed records. Pair metrics with sampled source-to-consumer verification and explicit alerts for unexpected event-generation gaps.

Return to contents or continue to Poison messages and dead-letter queues need decisions.

15. Poison messages and dead-letter queues need decisions

An event may be well authenticated but impossible for the current consumer to understand because of a schema mismatch, missing required field or unsupported action type. Retrying it endlessly can occupy processing capacity and block later updates. A dead-letter policy can isolate the problem for qualified review while preserving the original event identity and payload under appropriate access control.

Moving an event to a dead-letter queue is not final business completion. A source record may remain newer than the downstream projection. The user may need a clear Pending or Unresolved status. A downstream consumer should not silently skip a critical approval or cancellation event and then apply newer events without assessing their ordering and dependency rules.

Repair should follow cause. A malformed contract needs schema correction, an authorization denial needs legitimate permission review, and a temporary broker outage may need bounded retries. Do not use a broad administrator credential or ask the model to invent required fields merely to clear a backlog. The actual contract and resource identity govern which action is permitted.

When replaying after repair, use the original event ID and current target version to avoid duplicate effects. Test out-of-order processing and poison-event removal with fictional resources. An operator’s ‘replayed successfully’ message should mean the relevant consumer and user-facing effect were checked, not merely that an HTTP call was accepted.

Return to contents or continue to Source updates still need current user permission.

16. Source updates still need current user permission

A committed outbox event can be valid while a related external action is no longer allowed. A teacher may cancel the publication after the source recorded an approved revision, or a parent may withdraw permission to send a message while the relay is delayed. The consumer must check current authorization at the boundary for the new consequential action where the workflow requires it.

Separate a historical fact from present authority. The source state that a reviewer approved revision 4 remains a recorded event even after the user cancels. It does not automatically authorize sending revision 5 to a new recipient. An event can instruct a controlled downstream evaluation without granting the worker unrestricted discretion over its tools.

Keep exact content and recipient binding. If a WordPress publication is intended for one canonical post and a model changes its title or slug, the consumer should not create a new public resource because it thinks that better expresses the old event. Reconcile source and target IDs and seek renewed approval for material changes under the actual editorial policy.

An outbox event cannot bypass tenant isolation. A shared broker can contain messages from multiple schools, but each consumer should validate the event’s trusted source and its rights to retrieve or modify the target resource. A valid event from Cedar does not give the consumer permission to read Willow’s private documents.

Return to contents or continue to Original event ordering protects cancellation and revisions.

17. Original event ordering protects cancellation and revisions

Imagine source L-42 changes from Draft revision 4 to Approved revision 5 and then Cancelled revision 6. A consumer processing revision 6 first should not later overwrite it with a delayed Approved revision 5. Deduplication by event ID is insufficient because these are distinct events. Use per-resource revision or sequencing checks that reject stale changes under the declared business contract.

Per-aggregate ordering can be supported by consistent broker keys or ordered sessions where the configured platform guarantees them. But an event may be dead-lettered, retried or delayed while later messages proceed, depending on the system. The consumer still needs to understand which state version governs the current action. Infrastructure ordering features support but do not replace that logic.

Do not confuse event creation time, receipt time and effective business date. A future-starting school policy may be recorded today, and a historical correction may arrive after a newer notice. A simple ‘last message wins’ rule can be wrong. Store the applicable source revision and effective date, and make the latest permitted interpretation an explicit decision.

A helpful status message might say that revision 6 cancelled the planned publication while the earlier approval remains part of the audit trail. It should not erase history or pretend every old event was a mistake. Trustworthy systems preserve what happened while restricting what may happen next.

Return to contents or continue to Changed-context school-publishing exercise.

18. Changed-context school-publishing exercise

Transfer the method to an invented school worksheet publisher. The authoritative database records forty draft or approval changes, each with a matching outbox event under its real local transaction. Twenty-six have independently verified current public or private target state, six are committed with outbound events pending, four were correctly rolled back during validation, two reached consumers but lack final target verification, and two have uncertain provider acknowledgements.

The accounting total is 26 + 6 + 4 + 2 + 2 = 40. Verified outcomes are 26 ÷ 40 = 65%, pending delivery 15%, correct rollbacks 10%, consumer-applied but unverified 5%, and unknown external acknowledgement 5%. These counts are invented and deliberately include difficult cases; they do not estimate WordPress publication success or model reliability.

Now suppose one of the two uncertain outcomes is independently confirmed under the original post ID. Verified rises to twenty-seven and unknown falls to one, with every other category unchanged. The forty logical tasks remain the same. No new post should be created merely because a prior response was lost. This is how a stable event and target identity prevent duplication.

Change the user’s permission for a final test. An editor approved one worksheet revision but the assistant generated a new version with a different deadline before the consumer published it. The committed event about the earlier revision does not grant permission to publish the changed content. Hold the effect for appropriate current review, while preserving the historical outbox and source records.

Return to contents or continue to How to explain these ideas to students and parents.

19. How to explain these ideas to students and parents

Think of a school office keeping two matching entries at the same moment: one says ‘the timetable was updated’ and the other says ‘the update notice must be sent’. A proper local transaction ensures neither entry is committed alone. A messenger may take longer to carry the second entry to another office, or deliver it twice, so that office must recognize the same notice and avoid applying it twice.

The student can check the 120-change ledger and explain why seventy-four verified outcomes are not the same as seventy-four broker accepts. The categories concern different stages. A parent can ask whether a specific revised notice is actually public, not only whether the school’s internal system recorded an update. This is systems thinking applied to everyday information.

An outbox is also a useful analogy for careful study. Recording that an assignment was submitted is different from receiving confirmation that the intended teacher obtained and assessed it. The analogy has limits—school submissions do not inherit database transaction guarantees—but it clarifies why an attempted action and a verified outcome need distinct evidence.

The same cause-and-effect method applies beyond education: bookings, inventory changes and approved communication workflows all have state changes and dependent notifications. A capable agent should explain which part is known complete, which remains pending and what trustworthy check will settle it.

Return to contents or continue to A practical deployment checklist for one small system.

20. A practical deployment checklist for one small system

Start with a legitimate task requiring both a business data update and a downstream notification. Name the authoritative datastore and confirm it supports an actual transaction across the source row and outbox event record. Define the event ID, aggregate ID, type, revision, minimal payload and applicable tenant scope. Do not design the agent’s prompt as the transaction boundary.

Implement one reliable relay using polling or change-data-capture under an understood contract. Configure bounded retries, per-aggregate ordering where needed, and a consumer that deduplicates events and independently validates permission and source state. A model should not have to know the broker’s inner mechanics to decide whether the user consented to the next action.

Test crash windows and replay with fictional sources before allowing consequential live effects. Verify the source and outbox roll back together, survive a commit-and-crash sequence, tolerate repeated publication and do not duplicate downstream effects after lost acknowledgements. Record the actual target state after each controlled test, not just the generated explanation.

Monitor unrelayed events, processing age, duplicate deliveries, dead-letter cases and final user outcomes. Provide a human correction route for genuine ambiguities. A useful service can hold an unresolved task instead of claiming a guessed success. The broader standard is an accountable, verifiable user result rather than maximal throughput of event messages.

Return to contents or continue to Limits and the most important promise.

21. Limits and the most important promise

An outbox pattern does not guarantee that every remote system is always synchronized, that a model generated factually correct information or that a human approved a newly changed recipient. It also does not universally create exactly-once external side effects. Its specific value is ensuring that a business data change and the durable event intention are recorded together under a real local transaction.

Different platforms implement that transaction boundary differently. Microsoft’s Cosmos DB example uses an atomic batch within one logical partition, while relational implementations can insert the business and outbox rows under one database transaction. A change feed and a polling relay have different operational trade-offs. Always verify the exact source platform’s documented guarantees.

Consumers can still fail, process the wrong revision, lack permission or produce an external effect whose acknowledgement is lost. Reliable design adds idempotency, version checks, current authorization, bounded recovery and independent readback. None of these principles requires the claim that artificial superintelligence has been achieved; they are necessary for ordinary present-day agentic software.

The durable lesson is that a trustworthy agent should not confuse recording a plan, committing a source change, publishing an event, applying a consumer update and completing the user’s real request. The outbox helps join the first two reliably; the rest require explicit engineering and verification. That is what turns a plausible automation pipeline into a system people can responsibly rely on.

Return to contents.

Frequently asked questions

What problem does a transactional outbox solve?

It avoids the failure gap between committing a business database change and recording the intention to publish its corresponding event.

Does an outbox guarantee exactly one delivered message?

Not generally. A relay or broker can redeliver an event; consumers should use stable event IDs and idempotent handling.

Is the entire workflow atomic after adding an outbox?

No. The source change and event record share one local transaction; downstream messaging and external actions have separate states.

Can a consumer ignore an old cancellation or approval event?

It must follow the business contract. Per-resource revision, effective time and ordering checks help prevent stale events from overwriting current decisions.

Does an outbox event authorize sending to a new recipient?

No. The executor must check current user consent and the approved recipient or content revision for the intended external effect.

How do I verify the workflow succeeded?

Check the source commit, event and relay state, consumer receipt and actual destination under the task’s success definition.

Primary technical documentation

References checked 24 October 2026. Vendor-specific guarantees and configuration scopes are distinct. Every Cedar task, numerical count, document revision and example outcome in this article is fictional and should not be interpreted as real operational statistics.

• AWS Prescriptive Guidance — Transactional Outbox: Dual-write failures, relational outbox or CDC, duplicate delivery and ordered events.
• Microsoft Learn — Dataverse Transactional Outbox: Synchronous local outbox commit, asynchronous publication, ordered sessions and idempotent consumers.
• Microsoft Azure Architecture — Cosmos DB Transactional Outbox: Atomic transaction scope, change feed, replay and consumer design.
• Azure Cosmos DB 2026 Sample — Transactional Outbox: Same-partition transactional batch, simulated crash and at-least-once event replay.
• Debezium Outbox Event Router: Insert-style outbox schema, event ID, aggregate key and routing semantics.
• Microservices.io — Transactional Outbox: Polling or transaction-log tailing relays and duplicate-message consequences.

Related specialist guides

Explore Super Intelligence curriculum; Event-Driven Agents; Agent Sagas; Agent Batch Writes; Tool Contract Drift; Agent Dual Control. A reliable system preserves current user authority and exact source state from the local commit to the final verified effect.