Babysit Runs

Operate existing runners toward the authorized outcome at the agreed quality. Prefer targeted repairs over a new scheduler or pipeline rewrite. Use the selected provider/runtime skill when invocation or access needs troubleshooting; use live-ai-pipelines only when recovery architecture needs implementation.

Choose the operating mode

Completion mode: finish the authorized workload using the established implementation, repairing defects as needed.

Pilot-and-improve mode: exercise an existing or modified workflow on representative inputs, inspect execution and output quality, and make bounded improvements before broader rollout. State what is being tested, the quality baseline, resource/spending limits and the completion boundary. A pilot is complete when the requested behavior is demonstrated and material findings are resolved or clearly reported; optional optimization ideas do not keep it running indefinitely.

Adopt, detach and schedule

Inspect actual processes, owners, logs and retained results. Adopt a matching live run rather than launch a duplicate. Discover routine facts from existing metadata and task history instead of re-interviewing the user.

Keep a compact continuation brief in the existing run metadata or monitor prompt:

• Goal, operating mode, scope, checkout, command, owner and run/log/artifact locations.
• Requested model/provider, shared concurrency ceiling, independent transfer limits and applicable resource/cost bounds.
• Agreed quality references, authorized repairs, completion evidence and release or handoff boundary.
• Current progress, retry state, next recovery time and monitoring/reporting cadence.

Check changed or uncertain dependencies before submitting work: launcher permissions, authentication/model access, actual tool configuration and capacity. Reuse recent comparable successful evidence. Record the effective rules and versions where acceptance or replay depends on them; stale historical instructions must not override the current authorized contract. Do not silently substitute models.

Detach substantial runs using the existing manager or simplest reliable mechanism. Verify that execution survives the launching shell/tool and logs remain discoverable.

Create or update one temporary monitor. In Codex, use the automation tool and a heartbeat in the main thread, normally every 2–5 minutes during a pilot or unstable run; reuse a matching automation. Use another scheduler when requested or appropriate. Disclose unavailable scheduling rather than promise future check-ins. Make the saved prompt self-contained using the continuation brief, including intervention authority and stopping conditions, and update it when the run moves or resumes. Persist decisions so wakeups do not depend on conversation memory or a stale PID.

Each wakeup inspects actual ownership, progress, recent traces, errors and representative new results. Periodically use a stronger model within the authorized model and spending scope to spot-check substantive outputs and diagnose trace patterns, especially after model substitutions, implementation changes, repeated failures or unexpected slowdowns. Reuse prior assessments when their inputs are unchanged. Process health and valid schemas do not establish output quality.

Reduce monitoring frequency once execution is healthy. Notify the user of meaningful milestones, material regressions, required external action and completion; stay quiet when unchanged.

Saturate useful work

Fill slots with ready work and advance independent items without whole-batch barriers. Parallelize preparation, LLM calls, transfers and downstream stages where dependencies permit. Do not add inference or busywork merely to occupy capacity.

Apply the allowance across all runners sharing the same constrained resource, rather than giving each runner the full ceiling. Keep independently justified transfer/media/provider caps. Retain established healthy concurrency instead of repeating ramp experiments on every resume.

Identify the current bottleneck, commonly LLM calls or data transfer. Adjust parallelism using comparable accepted throughput, latency, retries, throttling and resource pressure. Downshift when useful performance degrades and recover capacity when healthy. Increase capacity at the demonstrated bottleneck; active-call count alone is not success.

Close the supervision loop

Notify promptly when an unfinished run stops making progress because all workers have stopped or eligible independent work is blocked. Report the cause, retained results and next recovery action even when no user action is needed; do not wait for the routine reporting interval.

Each wakeup must advance a concrete ready step or record the actual dependency, persisted cooldown or service wait and its next check time. Status inspection and rewriting continuation notes alone are not recovery. Follow through on completed asynchronous prerequisites, including release checks, so ready work resumes without waiting for the user to notice.

When the existing runner lacks the recovery behavior needed to finish, repair it within the authorized scope and resource limits, using safe execution boundaries and required validation/release gates. Keep persistent retries, delivery reconciliation and failure isolation in the repository implementation; this skill makes the supervisor responsible for identifying and repairing those gaps, not for inventing a replacement runner or bypassing safeguards.

Verify recovery by observing useful work resume: a previously blocked eligible stage advances or produces a valid retained result, and independent work can continue while affected items remain isolated. A patch, passing tests, merge or restarted process alone does not establish recovery. If work does not advance, continue diagnosis and report the remaining blocker accurately.

“Stay quiet when unchanged” applies to healthy execution or a previously explained dependency wait whose next check is scheduled. It does not justify leaving an unattended stall unreported. Avoid repeating unchanged alerts; report a new cause, missed recovery deadline, material forecast change or restored progress.

Recover without losing successful work

Each check compares accepted/remaining counts, active/queued stages, oldest work, ownership, recent logs, deliveries and retry state with the previous observation. Quiet logs alone do not establish a stall; use representative durations and other progress signals.

Isolate failed items or surfaces while independent work continues. Before replacement, reconcile retained results and cancel or fence a stale owner. Drain affected active work before activating incompatible runner changes. Preserve successful stages and repair only the failed dimension.

• Established intermittent failure: recover automatically with bounded backoff and jitter. A status code alone does not establish quota exhaustion or permanent denial.
• Explicit authentication, entitlement or quota failure: isolate the affected surface and use normal authorized recovery. If external action is needed, report the concrete requirement.
• Unknown delivery: a client timeout is not the provider's final outcome. Check retained output, request IDs and provider status. If the API cannot show the result, use the authorized authenticated dashboard through Chrome/Computer. An API permission error does not rule out dashboard access. Preserve attempt history; missing local output or an early empty provider log does not prove failure.
• Runner or content defect: fix the demonstrated cause and resume unfinished work, rather than regenerate accepted results.

Close the uncertainty loop. If the provider may still be processing, persist the next check time based on its expected completion window and check again then. Recover successful output; follow up on pending work; investigate confirmed failures and retry within authorization and budget. If the outcome remains unresolved after bounded checks, report exactly what evidence or access is missing. Do not leave an item indefinitely marked unknown, and keep independent work moving.

Retain the actual error and its cause, elapsed time and available request identifiers. Do not replace useful timeout or transport details with only a generic “delivery unknown” message. Distinguish the client's response state from the provider's completion state in reports.

Use bounded immediate retries, followed by persisted cooldowns for periodic outages. Respect existing budgets. Wakeups must not reset retry history. When repeated recovery produces no useful progress, diagnose or pause the affected work and report evidence instead of maintaining a hot retry loop. Routine recoverable failures should not require another approval interruption.

Authority to intervene

Within the authorized outcome and resource/spending limits, the supervisor may autonomously pause admission, drain or stop affected work, repair or refactor the existing implementation, resume retained stages and increase useful concurrency. Routine diagnosis, targeted refactoring, recovery and concurrency adjustment are part of the delegated job and do not require repeated approval.

Intervene when evidence shows incorrect output, a stall, excessive latency, repeated unreliability or substantial wasted work. Preserve original evidence and accepted results, reconcile ambiguous deliveries, and change executable code only at safe boundaries.

Prefer one coordinated repair over repeated small interruptions. Record the finding, intervention and observed result. Stop repeating an intervention that produces no useful improvement. Do not weaken quality requirements, invent a replacement pipeline or expand the workload merely to keep workers busy.

Preserve quality; remove accidental gates

Use agreed examples and past transcripts to judge quality and unnecessary blockers. Local repairs may address runner bugs, contradictory stage rules, performance and finishing defects within the authorized goal. Throughput improvements must preserve substantive quality.

Separate content acceptance, execution validity and metadata completeness. Suggestions and model self-check flags do not become blockers without evidence of a defect. Retain required blockers for demonstrated unsupported claims, identity conflicts or substantive loss where those affect the task. Declared tool access should match actual execution; do not allow normal tool use and reject it downstream.

Sample after changes that could materially affect agreed quality, using existing accepted calibration when sufficient. Test the affected interaction when a repair risks acceptance, replay or output integrity. Neither sampling nor broad verification is a prerequisite for every resume. Stop gathering proof once the relevant risk and authorized outcome are resolved. Preserve applicable privacy, security and release boundaries.

Instrument performance

Instrument enough of the critical path to distinguish useful execution, queue waits, retries/backoff, release waits and duplicated work. Use existing structured logs/status artifacts, not a new telemetry service. Record run/item/stage/attempt IDs, effective model/configuration, input size, active/queued counts, concurrency, queue/start/end timestamps, outcome, retry reason, output disposition and receipt where available. For transfers, record bytes and duration. Exclude credentials and unnecessary source content. Instrumentation should answer an operational question; incomplete optional observability should not block a useful pilot.

Look for missed opportunities: idle capacity despite ready work, unnecessary stage barriers, serial independent I/O, repeated validation of unchanged artifacts, redundant model calls and repeated builds. Prioritize the largest measured delay. Measure accepted output delivered per elapsed hour, and record user interventions as an operational cost; worker activity alone is not progress.

Diagnose the largest unexpected delay on the critical path: slow calls, starvation, transfers, repairs or gating. Record performance changes with their hypothesis and before/after useful throughput. Variance is a diagnostic signal, not an automatic blocker.

Report progress and ETA

Use report-progress-eta-analyze for whole-task summaries, remaining-stage forecasts, comparisons with prior estimates and analysis of measured inefficiencies. Keep evidence in the existing run artifacts. Apply findings through the intervention authority above; reporting does not create a second monitor or completion ledger.

Normally report routine meaningful progress at most every fifteen minutes, with material regressions, completion and required action reported promptly. Stay quiet when progress, forecast and risk are unchanged; answer explicit status requests directly.

Stop and hand off

Completion is the authorized outcome: validated outputs for generation, or deployment/live evidence when shipping was authorized. Optional unavailable checks are disclosed; a blocked required dependency receives a precise incomplete handoff.

For pilot-and-improve runs, report output quality, timing, reliability, significant interventions and remaining optimization opportunities. Update the existing workflow documentation to reflect verified behavior, distinguishing measured results from proposals.

Link outcomes and remaining qualifications. Pause the monitor after verified completion or explicit external handoff. Preserve reusable results and receipts; clean known disposable resources and avoid orphaned workers or duplicate monitors. Babysitting does not itself authorize additional scope or publication.