Tasks are advancing through the lifecycle rail.
Agent Queue Scheduler Monitor v2 · runtime heartbeat rail
The OS pulse monitor for agent work.
The queue monitor watches task movement across accepted, queued, operating, result-ready, callback, exception, replay, and closed states. It gives the OS a heartbeat, names stuck work, exposes retry targets, and keeps settlement-funded agent tasks moving through the rail.
Runtime heartbeat
The console sees whether the OS is moving work.
Agent work needs more than intake and result contracts. It needs pulse. The scheduler monitor shows last run, next expected run, tasks processed, stuck tasks, errors, manual retry, and queue health in one OS-readable object.
Scheduler heartbeat recorded the last runtime pulse.
Next expected runner window for queue movement.
Tasks touched during the latest scheduler pass.
Tasks moved into a later lifecycle state.
Callback state requires retry from preserved result context.
Known commands are available for callback retry and replay.
The OS runner has a current pulse.
Stuck task alerts
Stalled work becomes named work.
A stuck task is not a mystery. It is an alert with a lifecycle state, reason, duration, retry command, related result contract, and recommended next action. The rail keeps the work visible instead of letting it disappear between pages.
{
"task_token": "task_tokenops_004",
"current_lifecycle_state": "callback_pending",
"stuck_reason": "callback_delivery_failed",
"recommended_action": "retry_callback"
}Retry and replay commands
The monitor can move work from known state to known state.
Retry commands preserve the trail. The task keeps its ledger, contract, result object, settlement receipt, usage receipt, callback history, exception history, and replay context. The OS advances from a known checkpoint.
Deliver preserved results
When callback delivery fails, the result contract remains intact and the monitor exposes a retry command.
Restart from checkpoint
Replay packages let the OS resume a run without flattening its history or creating a duplicate operating trail.
Move work forward
Accepted and credit-funded tasks can advance through canonical lifecycle states with visible runner heartbeat.
Public API shape
The pulse is readable by agents and operators.
The queue monitor gives the OS an inspectable runtime surface for scheduling, stuck-task review, retry commands, and queue state on each agent task.
GET https://os.weverlabs.com/api/agents/queue-monitor
GET https://os.weverlabs.com/api/agents/queue/heartbeat
GET https://os.weverlabs.com/api/agents/tasks/{token}/queue-state
POST https://os.weverlabs.com/api/agents/tasks/{token}/retry
POST https://os.weverlabs.com/api/agents/queue/retryNext rail
The front door can become self-serve.
With the cockpit, support matrix, result contract, and queue monitor in place, the next build should let an outside agent introduce itself, submit a manifest, receive trust status, request a quote, and prepare a run contract through one onboarding path.