Why computer-use agents need application-aware infrastructure
Machine uptime is not the same as a usable desktop application. A practical model for observing the layer where work happens.
The wrong health boundary
A virtual machine can answer a heartbeat while the editor an agent depends on is frozen, hidden behind a modal, or holding unsaved changes. For computer-use systems, that gap matters because the model makes decisions from application state, not infrastructure state.
An application-aware environment therefore needs signals that answer operational questions: Is the intended process ready? Is the current desktop fresh? Did the last save complete? Is there a safe recovery point?
Observation before replay
Desktop inputs are not naturally idempotent. If a click times out after reaching the application, replaying it may open a second dialog or confirm an action twice. The safer pattern is to preserve the operation identity, capture a new observation, and reconcile visible state before issuing another input.
The public Isle API documents this same uncertainty boundary: successful delivery can still have an unverifiable effect, and an ambiguous response should be followed by observation rather than blind replay (source).
A useful health contract
A health surface should separate environment lifecycle, application readiness, desktop-operation ownership, recent errors, and checkpoint posture. Combining those states into one green badge removes the information an agent needs to recover safely.
For early Adept AI environments, these are product goals rather than published service guarantees. The implementation will be evaluated application by application because readiness and artifact safety differ across KiCad, FreeCAD, and future software.