Waiting Without Spinning: Monitors, Backoff, and Host Boundaries
LoopX treats waiting as part of the long-horizon lifecycle, not as a blank space between agent turns. This chapter focuses on two linked mechanisms: the continuous monitor that records what external condition is being watched, and the scheduler hint that tells a replaceable host when to look again. Together they let the system remain available without spending delivery compute on unchanged evidence or confusing a proposed cadence with a cadence that the host actually applied.
A monitor is a work item with a future
An instruction such as “check the pull request again later” sounds harmless, but it leaves nearly every operational question unanswered. Which pull request? What does “later” mean? What change matters? How many unchanged checks are useful? What should happen if the check never becomes terminal? Which Agent is responsible for the observation, and how can another session know whether the last poll actually occurred?
LoopX represents that waiting state as a continuous_monitor. A useful monitor has a stable target identity, a cadence or next due time, a bounded observation handle, a rule for deciding whether a change is material, and an expiry or termination condition. It also records a compact observation result, such as a result hash, the time it was checked, and a per-target count of consecutive no-change observations. The point is not to make the monitor a second application scheduler. The point is to give waiting an identity and a recoverable condition.
Four situations must be distinguished.
Before the monitor is due, the correct action is to wait. The host may remain active and follow a later wake-up schedule, but it should not poll early merely because the Goal has quota left. An early poll consumes external resources and may create the illusion that the system is making progress when the authoritative source could not yet have changed.
When the monitor is due and the observation is unchanged, the Agent or provider may perform one bounded read-only poll. The monitor records the observed identity, result hash, no-change state, and next due time. It does not create a delivery successor simply because it looked. It does not spend a delivery slot for an unchanged external condition. The no-change record is still useful: it proves that the system checked the right target and gives the scheduler a basis for backoff.
When the monitor is due and evidence changes materially, the observation can alter the work graph. A failed CI check may create a repair successor. A reviewer request may create a scoped correction or user Gate. A completed external job may create an evaluation Todo. A new artifact may satisfy a dependency or make a deferred successor ready for explicit reconsideration. The monitor remains an observation mechanism; the Capability or domain layer interprets the change, and the Kernel accepts the resulting successor, Gate, blocker, or terminal candidate.
When the monitor reaches an expiry or stop condition, it must not continue indefinitely under a new timestamp. The system should close it with evidence, supersede it, write a concrete blocker, or create a successor with a bounded recovery route. If the Goal is complete and no follow-up is needed, terminal closure requires more than the monitor disappearing: the rest of the frontier, acceptance gaps, handoffs, and retryable readbacks must also be closed.
This lifecycle prevents two opposite errors. The first is hot polling: every heartbeat invokes the same external check, rewrites the same summary, and spends resources despite no new information. The second is silent abandonment: the system decides not to poll and then treats the absence of a new observation as proof that the Goal is finished. A monitor makes the difference visible.
The identity of no-change evidence matters when several monitors are interleaved.