A wait is not a loop

Most demonstrations compress work into a single session. Real processes contain waits measured in minutes, days and weeks. An approval must arrive. A CI job must finish. A record may change or never change. An agent that cannot represent a wait as durable state is forced either to poll or to forget.

Polling can be sensible for a fast, cheap API call. Repeated model inference is different: it consumes context, money and attention without producing new information. The thing that should remain alive is the condition, not the reasoning loop.

An example might be: 'When a purchase invoice is revised and the supplier confirms the corrected amount, resume reconciliation; if nothing arrives before Friday, raise an exception.' The task is meaningful now, but its next execution step depends on facts that do not yet exist.

A raw event says something happened. A business condition combines that event with scope and timing. One email is not a supplier confirmation. One invoice update may belong to a different order. Correlation must consider identifiers, sources, sequence and bounded windows.

Some conditions are structural: event A AND event B, a count over a window, an expected event absent after a deadline. These should generally be evaluated deterministically. Other cases can benefit from constrained semantic interpretation, but the decision should be narrow and recorded, not a perpetual open-ended reasoning session.

The output is not necessarily a model response. It can be a durable fact—'the expected confirmation window expired'—or an activation targeted at a specific piece of waiting work.

An important boundary is easy to miss. An incoming event is evidence that a condition may hold; it is not a command that authorizes a write. A webhook payload can be duplicated, delayed, malformed or malicious. Even a correct match may arrive after the user's permissions have changed.

The event layer should evaluate conditions and deliver a host-owned activation. The host must decide whether and how to resume the work, whether permissions remain valid, and whether the intended effect has already occurred.

This separation is why an event runtime should not need to own the host's conversation model, credentials or complete agent execution logic. It can target an opaque continuation identifier and leave business authority to the environment that owns it.

Imagine one parent task delegating two checks: wait for a supplier reply and wait for a finance approval. If the reply arrives, the supplier branch can become runnable. That does not imply the finance branch is ready, or that the parent may finalize reconciliation.

An exact continuation target, durable wait registration, and clear dependency semantics make the difference between resuming work and simply replaying a prompt. The parent can proceed when its declared join condition becomes true.

For an automation the situation differs again. A rule like 'Every morning inspect new overdue invoices' starts a new run. An already-waiting investigation resumes an existing run. Conflating those two produces duplicate work and confusing histories.

Absence is not just silence. If a supplier confirmation does not arrive by a stated deadline, the failure to observe it becomes part of the condition being evaluated. A useful event runtime must make the time window and the interpretation of absence explicit.

There are hard cases: sources can go offline, cursors can lag, and clocks can disagree. 'No event received' is not automatically equivalent to 'nothing happened'. Temporal correctness depends on the source and on how late data is handled.

This is why timing belongs in the design, not only in a scheduler configuration.

Once the relevant event arrives, reasoning becomes useful again. The agent can inspect new records, compare them with the earlier evidence, ask a person about a discrepancy or complete the task after verification.

The principle is simple: wait with state; reason when new information justifies reasoning. It makes cost more predictable and the resulting work easier to inspect.

MCP Event Intelligence is a separately published experiment in this direction. Its current package behaviors and a fully integrated business-product execution model are different maturity claims. The lesson stands regardless of any one integration.