Event-driven AI agents react when a relevant event is delivered, rather than repeatedly polling every connected service. Webhooks, event buses and queues can make these workflows responsive, but a delivered event is not guaranteed unique, ordered, authentic or complete. A reliable agent must verify the event’s origin, reconcile the current source state and preserve the authority of the original task.
This article follows an invented Cedar Library Notice Feed with twenty-four different event identities and thirty delivery attempts. It separates duplicates, rejected events, outdated revisions, valid state updates and pending source checks. Readers calculate each category and transfer the method to a second fictional service.
It is a technical companion to eduKateSG’s completed How Super Intelligence Works curriculum, not evidence of achieved artificial superintelligence.
Contents and event-processing routes
1. Events report that something happened · 2. A webhook is a delivery mechanism · 3. Polling and subscription have different costs · 4. The CloudEvents specification describes interoperable event envelopes · 5. An event ID is not a business object ID · 6. The fictional Cedar Library Notice Feed · 7. Six repeated deliveries do not mean six new events · 8. Verify authenticity before applying content · 9. Current, stale and pending valid events · 10. Why the receiver should not trust delivery order · 11. The P-03 and P-02 ordering example · 12. Event time differs from arrival time · 13. An acknowledgement is not an applied state change · 14. Why event handlers need queues and backpressure · 15. A queue is not a licence to ignore an event · 16. Duplicate handling belongs before side effects · 17. Authentication does not establish source truth · 18. CloudEvents does not standardise webhook signatures · 19. An AI summariser needs an authorised scope · 20. Watch for changes in event payload schema · 21. A state reconciliation job catches lost updates · 22. Independent transfer: a smaller library feed · 23. Changed-context answer: same programme, two revisions · 24. A student exercise with event cards · 25. Frequently asked questions · 26. Primary sources and the advanced reading route
1. Events report that something happened
An event is a record of an occurrence, such as a document being revised, a booking being approved or a worksheet being published. Its payload may contain the changed fields or a reference to a canonical resource. An event is not necessarily a command to perform an unrelated action.
If a school timetable changes, the correct consumer may refresh a public-information cache or notify an appropriate reviewer. It should not infer that an event gives permission to contact every family or read confidential records. Event meaning and authority must be specified by the application.
2. A webhook is a delivery mechanism
A webhook allows one system to send event information to a configured receiver, commonly through an HTTP request. The receiver verifies the event according to the provider’s contract and processes it under its own permissions. This can reduce unnecessary polling when the producer already knows about changes.
Webhook delivery may be asynchronous, repeated after failures or received out of order. A successful HTTP acknowledgement can mean the receiver accepted the message, not that every downstream task has finished or that the user’s final goal is verified.
3. Polling and subscription have different costs
Polling asks a source repeatedly whether something has changed. It can be simple to understand and recover but may generate many checks during quiet periods. Event delivery can push changes promptly, but introduces subscriptions, authentication, retries, ordering and consumer-state management.
A good application selects a strategy according to timeliness, service contracts, volume and failure behaviour rather than assuming events are always superior. Some systems combine events for prompt notification with periodic authorised reconciliation to detect missed changes.
4. The CloudEvents specification describes interoperable event envelopes
The CNCF CloudEvents v1.0.2 core specification describes a vendor-neutral event format. Its required context attributes include id, source, specversion and type. The combination of source and id identifies a distinct event within the specified convention.
These fields help consumers parse and correlate events across systems. They do not automatically prove that a payload is authentic or current. Transport security, authorised producers and domain-specific checks remain separate responsibilities.
5. An event ID is not a business object ID
An event with ID E-17 might describe a revision to programme P-03. A later event E-18 can describe another revision to the same programme. Both are different occurrences affecting one business object.
Deduplicating by programme ID alone would wrongly discard legitimate updates. Conversely, accepting repeated deliveries of the same event as distinct updates can cause duplicate notifications or work. Keep event identity and subject identity separate.
6. The fictional Cedar Library Notice Feed
The invented Cedar Library receives twenty-four distinct event notifications in a reporting period. They describe revisions to public study-programme records. During delivery retries, six events are delivered a second time, so the receiver sees thirty webhook submissions in total.
The consumer is permitted to update a bounded public-information index from verified source revisions. It may not inspect protected family records or send unrelated messages. All identities, revisions, counts and outcomes are original paper-only fixtures.
7. Six repeated deliveries do not mean six new events
There are thirty webhook submissions but only twenty-four distinct event identities under the packet. Six are repeat deliveries of already identified events. The repeated-transmission fraction is 6/30=20%, while the distinct-event share of submissions is 24/30=80%.
Those are traffic measures, not evidence that six extra timetable changes occurred. A dashboard that counts raw deliveries as unique institutional updates exaggerates activity. Reliable processing deduplicates according to the producer’s documented event identity and relevant object semantics.
8. Verify authenticity before applying content
Of the twenty-four unique fictional event identities, twenty-two pass the stipulated source-authenticity checks and two do not. The rejected two must not change the public index. The proportion passing this particular teaching check is 22/24, approximately 91.7%.
This is a made-up record of verification outcomes, not a measured cryptographic security rate. An invalid event may be malformed, forged or incorrectly configured; the failure alone does not establish attacker intent. The first priority is to prevent unauthorised effects.
9. Current, stale and pending valid events
Among the twenty-two authenticated unique events, eighteen contain applicable newer revisions and result in verified index updates. Three refer to older revisions and are correctly ignored as stale. One refers to an update whose authoritative source cannot currently be fetched; it remains pending.
Check the accounting: 18+3+1=22 valid unique events. Add the two rejected events and the total is twenty-four. The accepted current-update share is 18/24=75% of all unique event identities, but that rate should not be described as model accuracy.
10. Why the receiver should not trust delivery order
Events may arrive in an order different from the order in which the underlying changes occurred. For example, an update to revision three can be delivered before a delayed update to revision two. Simply applying the last message received can overwrite a newer state with an older one.
Stripe’s webhook guidance explicitly states that event ordering is not guaranteed for that integration. The general engineering habit is to inspect authoritative version or object state according to the source’s contract, not infer currency from arrival position alone.
11. The P-03 and P-02 ordering example
Suppose an imaginary public programme P receives approved revision three listing 11:30 before a delayed revision two listing 10:00 reaches the index consumer. If revision three is verified as current, processing the older event later should not restore 10:00.
The receiver should compare the source’s revision and state under the authorised data contract. A timestamp alone may be ambiguous if events share a time resolution or originate in different systems. The correct user-visible answer follows the controlling official revision.
12. Event time differs from arrival time
An event’s occurrence time may differ from when the webhook receiver obtained it. Network retries and queues can delay delivery. The CloudEvents time attribute is optional and has producer-defined consistency requirements; it is not guaranteed proof that the event was received immediately.
Record source revision, event occurrence context and receipt time as distinct fields where needed. A late-arriving event may still be genuine, but not necessarily current. The application should interpret it in relation to the authoritative business object.
13. An acknowledgement is not an applied state change
A receiver may quickly acknowledge that an event has been accepted for processing and then place it in a queue. The final index update may happen later or fail. It would be inaccurate to tell readers that the timetable was refreshed merely because the webhook endpoint returned success.
Use separate states such as received, authenticated, queued, processed, applied, ignored_as_stale and unresolved. If an index update is consequential, verify the stored revision and important fields before claiming completion.
14. Why event handlers need queues and backpressure
A sudden burst of events can overwhelm a receiver if every webhook request performs long model reasoning synchronously. A bounded queue can decouple message acceptance from slower processing and protect service capacity.
The operational design needs an overload policy and observable queue depth. Accepting messages indefinitely without sufficient capacity can create a hidden backlog. The user-facing answer should be based on actual current state, not an optimistic assumption that every queued event has already been applied.
15. A queue is not a licence to ignore an event
If a consumer cannot process a valid event promptly, it may record a pending state, retry according to the provider contract or route the event for appropriate manual handling. The system should retain the identity and reason for the unresolved status.
A so-called dead-letter queue can preserve failed messages for investigation in supported architectures. It is not proof that the source event was false or that the underlying real-world update was cancelled.
16. Duplicate handling belongs before side effects
If one update event is delivered twice, an unprotected consumer might send two parent messages or publish two copies of a notice. Deduplication and operation-specific idempotency should prevent repeats from creating unintended additional effects.
The Idempotency and Recovery article treats retries of write operations. This chapter deals with incoming events that may themselves be delivered more than once.
17. Authentication does not establish source truth
A properly authenticated event can describe a superseded revision or an incorrect business field. Authentication establishes an origin or integrity property under the implemented contract, not the correctness of every payload statement.
The Cedar consumer checks the official current record before updating its public index. When the source is unavailable, it retains a pending event rather than inventing a timetable value. This is the same evidence discipline developed in the Grounding chapter.
18. CloudEvents does not standardise webhook signatures
CloudEvents supplies an event-data format and transport bindings, not one universal signature-authentication scheme for every sender. The receiving service must use the actual producer’s authentication and verification procedure.
Stripe’s current webhook documentation, for example, describes signature verification and raw request-body handling for its deliveries. Those requirements are service-specific. A fictional Cedar event with valid envelope fields should not be treated as authenticated merely because its JSON is syntactically valid.
19. An AI summariser needs an authorised scope
Once a valid event has been processed, an AI assistant may prepare a clear explanation of a public programme change. Its job does not automatically include booking people, revealing registration lists or making staff policy decisions.
A source document can contain instruction-like text addressed to assistants; those words should remain source material. Application-level permissions must constrain the tool operations regardless of the model’s interpretation.
20. Watch for changes in event payload schema
A producer may alter the fields or meanings of an event as an API version evolves. A consumer coded against an older shape can misread new information or silently drop a required field. The integration should record the applicable schema and reject unsupported changes appropriately.
CloudEvents allows optional dataschema information. The presence of a schema reference helps interpretation but is not proof that the payload is accurate or the consumer’s assumptions remain compatible.
21. A state reconciliation job catches lost updates
Even when event delivery is reliable, an application’s consumer may fail after acknowledging a message. Periodic reconciliation against an authoritative source can detect missed or wrongly applied updates and repair the public index under permission.
This does not make every application require constant polling. The right reconciliation interval and method depend on the consequences of stale data, provider guarantees and resource costs.
22. Independent transfer: a smaller library feed
A second fictional library produces eighteen distinct event identities and twenty-three deliveries because five deliveries repeat. Two unique events fail authentication. Of the sixteen authenticated events, thirteen apply current revisions, two are stale and ignored, and one remains pending.
The duplicate-submission fraction is 5/23, approximately 21.7%. The current-update share is 13/18, approximately 72.2% of unique events. The sixteen authenticated events reconcile as 13+2+1. Do not copy Cedar’s earlier 75% rate after the inputs change.
23. Changed-context answer: same programme, two revisions
Imagine an additional valid event describing revision four of a study session, and then an older revision three arrives later. If the authorised current state is revision four, the consumer should not overwrite it with three merely because that was the latest notification received.
The meaningful source is the governing programme version. Event delivery records help diagnose timing and duplicates but do not replace official current data. This principle transfers to school notices, appointment schedules and other document-driven services.
24. A student exercise with event cards
Give pupils cards carrying source, event ID, type, document revision and receipt order. Include duplicate deliveries, a stale revision and a card with missing evidence. Ask them to group identical event identities, establish the permitted source and identify which programme changes can be verified.
Then change the order of the cards. The correct final current state should remain governed by the authoritative revision rather than the arbitrary arrival order. This is practical understanding of event processing without a live webhook endpoint.
25. Frequently asked questions
Does one webhook delivery equal one real-world event? Not necessarily; providers may retry. Does an HTTP success response prove the user’s intended workflow is complete? No. Does CloudEvents supply automatic signature verification? No; the sender and consumer must establish their security mechanism.
Can an event trigger an AI agent? Yes, within the application’s defined permission and processing rules. Does an authentic event always describe the latest state? No; version checks and reconciliation may still be needed.
Applied event-delivery laboratory: duplicate identities, queues, integrity and source state
Event creation and event delivery are separate clocks
The source may generate a programme-revision event when an approved record changes, while the receiver may see that notification seconds or minutes later. Delayed transport does not change when the underlying source revision became effective. An agent should not treat receipt time as the time of the policy decision.
For a current-programme answer, the consumer must determine which source is applicable, not which webhook happened to be the last packet in its queue. The distinction becomes particularly important after outages and retries.
One business change can generate several event types
A single approved programme update could produce a document_changed event and a cache_refresh_requested event. These represent different occurrences or stages even though they refer to the same programme. Deduplication by programme ID alone can incorrectly remove legitimate work.
The application should know which event types it subscribes to and what each means. A type field is a useful routing aid, not authority to call any tool described in arbitrary payload text.
Duplicate identity and semantic duplication differ
A producer may resend one event using the same source and event ID. Another producer could emit a separate event describing the same underlying business change. The first is a repeated delivery by the protocol identity; the second may be a different event that still needs business-level reconciliation.
This is why unique delivery counting and correct business-state handling are separate. A robust consumer does not blindly apply both payloads just because their event IDs are different.
Successful signature verification has a limited scope
A valid signature under the provider’s configured verification procedure supports the claimed origin and integrity of the signed message. It does not establish that the person publishing the source was correct, that the programme revision is still current, or that the webhook describes a permitted action.
The system should next check the relevant source version and authorisation. A signed stale event can still be ignored appropriately without implying any signature failure.
Ack quickly only after safe acceptance
Some webhook services recommend acknowledging delivery promptly and handling expensive work asynchronously. An application should not return success before it has safely accepted whatever message it intends to process according to its durability contract. Otherwise it may lose the event after informing the sender it was received.
Exactly when to acknowledge depends on the producer, queue and handler guarantees. A general article cannot promise that every 2xx status proves the durable queue already stored the payload.
Queues create backpressure rather than infinite capacity
Imagine an invented Cedar processing worker can apply ten valid updates per minute but twenty arrive every minute for three minutes. Under constant rates and no other handling, backlog grows by ten per minute to thirty. The events may be authentic even while they wait.
A faster model summary will not fix a queue constrained by a slower protected database. The operator needs relevant capacity, rate limits or a legitimate overload plan, together with honest pending states.
Repeated deliveries do not increase unique completed outcomes
Suppose six retries are received for already processed event identities. If deduplication works, the receiver may acknowledge them without repeating the external update. The unique applied-state count remains eighteen in Cedar’s packet, not twenty-four.
Counting all acknowledgements as applied business changes would inflate the completion report. Each metric needs an explicit unit: network delivery, unique event, valid event or verified source update.
Stale events can be useful audit evidence
An older revision arriving after a newer one should not overwrite the current index, but its arrival can still matter for diagnostic records. It may reveal delivery delay or help explain why an earlier consumer made a wrong decision.
The audit can record that the event was authenticated but ignored for currency. Keeping this distinction is more informative than classifying every non-applied event as corrupt or failed.
An event timestamp can share a value with another event
Some systems create several events within the same timestamp resolution. Two events with matching timestamps are not automatically duplicates and do not necessarily have a defined ordering. Source revision numbers or relevant object retrieval may provide stronger currency evidence under the system’s contract.
The consumer should not use an equality test on event time as a universal replacement for stable event IDs and authorised source versions.
Large payloads raise privacy and transport questions
CloudEvents guidance encourages compact events and warns about sensitive data in context attributes. A public timetable update generally needs a programme identifier and change reference, not the full private membership record.
A consumer can retrieve additional authorised data when necessary, applying separate access controls. Moving unnecessary personal records through every event intermediary creates exposure without improving the schedule answer.
A forged event must not be acted upon
The Cedar packet’s two unverified events must not trigger changes to the public index. Even if their content matches plausible future notices, the receiver lacks the required confidence in their origin under the fictional authentication rule.
The appropriate next step may be logging a safe failure category, alerting the designated operator or requesting clarification. The model should not treat rejected source content as authoritative simply because it is formatted like a legitimate event.
A valid event with a missing source remains pending
One Cedar event passes authentication but cannot fetch its authoritative revision record. The system should preserve its event identity and pending status, then attempt an authorised reconciliation route when appropriate. It should not silently guess which timetable changed.
This is a source-availability issue, different from authentication failure and different from a stale revision. Keeping those classes separate improves diagnosis and avoids invented user-facing conclusions.
Event consumers must handle changing schemas
A producer may introduce a new field or version and the consumer might no longer parse its source revision correctly. This can cause valid messages to be rejected or, more dangerously, misinterpreted. Schema versioning and compatibility tests should be part of release practice.
The consumer can use an explicit schema identifier where provided but still needs task-specific semantic checks. A valid JSON envelope does not prove every required application field is present or meaningful.
The receiver’s generated response must remain grounded
An AI assistant can explain that Cedar updated the public programme index using source revision P-03. It should not infer that every subscriber received a notification or every family saw the new page unless those outcomes were separately observed.
An event-driven system may complete its internal processing while a downstream delivery service fails. The completed state must be defined at the right boundary for the user’s actual request.
Monitoring should include event lag and unresolved age
An event backlog count is useful, but a small queue might contain one very old unresolved update. Measure the age of pending items, actual source-version lag, repeated delivery volume and verified applied outcomes. Those measures describe different causes of delay.
A model’s average response time may remain low while public information stays stale. End-to-end monitoring needs source state and consumer state rather than only inference latency.
A changed source identity can break naive deduplication
CloudEvents identifies distinct events using source together with id. Two producers could coincidentally use the same local ID. Deduplicating globally by id alone can suppress a legitimate event from a different source.
For the teaching packet, treat the two fields as the identity pair. A real implementation follows the provider’s actual event contract, which may use a different documented identifier scheme.
An authorised update can require human review
Some public records should not automatically change in response to every upstream event. The event may tell an editor that a proposed timetable revision exists while the institution still requires review before publication. The receiver’s policy determines which steps it may perform.
Event delivery is not a replacement for approval. A valid notification can appropriately result in a pending review task rather than a public edit.
Conclude with a source-state reconciliation
The best final check for Cedar compares the public index with the authorised current programme records. The receiver should be able to account for eighteen verified updates, three deliberately ignored old revisions, one pending source lookup and two unverified events.
Those categories together describe all twenty-four distinct events. The six retransmissions explain why thirty deliveries were observed without creating six extra updates. The exercise teaches accurate status reporting through different technical layers.
Final verification and backfill safeguards
Why a dead-letter queue is not a wastebasket
A valid event that repeatedly fails processing may be placed in a separate queue for controlled investigation, depending on the architecture. The operator should retain the event identity, safe failure reason and relevant source version, then decide whether to correct the consumer or retry. Silently discarding these records can leave a public index out of date while normal monitoring appears healthy.
The final user-facing sentence must reflect a real observation
A model can correctly explain what an event means but cannot prove that the target website has updated solely from the arrival of a webhook. The receiver should read the relevant current page or source-of-truth record before declaring that the requested publication occurred. If a required check is unavailable, it should report that precise limitation rather than invent a success.
Backfill changes the age distribution of deliveries
After an outage, a producer may redeliver many older events. The consumer should compare each event’s identity and source version, avoiding duplicate writes and obsolete overwrites. Backfill can temporarily increase throughput and queue depth without representing a fresh surge of real-world programme changes. Report the period of occurrence separately from the processing time.
A learner’s final transfer check
Ask pupils to explain how twenty-three deliveries can represent eighteen distinct events and why only thirteen of those might produce current, verified updates. They must reconcile repeats, authentication denials, old revisions and missing source checks. If they can do so on a new packet without copying Cedar’s percentages, they understand event-driven systems as evidence workflows rather than just messaging technology.
Continue the four-part agent reliability route: Durable Workflows · Agent Sagas · Reliability & Error Budgets. Together these laboratories trace a saved task across failures, event delivery, multi-service compensation and measured complete-task reliability. See the completed 100-topic series hub and Agent Observability for the corresponding full-system checks.
26. Primary sources and the advanced reading route
Read CloudEvents v1.0.2 for required event context and Stripe webhooks documentation for an implementation illustrating retries, event ordering, duplicate handling and signature checks. These references do not validate Cedar’s invented records.
Continue through eduKate’s Durable Agent Workflows, Idempotency, Agent Observability and How Super Intelligence Works. All event counts, identities and results in the exercises are fictional. Sources checked 22 October 2026.