human-interruptible-unattended-runner

name	human-interruptible-unattended-runner
description	Use when running long unattended agent tasks, model training, evaluations, batch jobs, experiment loops, or autonomous coding sessions where work should continue without immediate user feedback but remain observable, interruptible, and adjustable after feedback arrives.
version	0.1.0
author	zhjai
license	MIT
metadata	{"hermes":{"tags":["ai-agents","unattended","autonomous-agents","training","experiment-tracking","human-in-the-loop","feedback","checkpoints","codex","claude-code"],"related_skills":["agent-arena","deliberative-analysis"]},"tags":["ai-agents","unattended","autonomous-agents","training","experiment-tracking","human-in-the-loop","feedback","checkpoints","codex","claude-code"]}

Human-Interruptible Unattended Runner

Overview

Use this skill for long-running work where the agent should keep making progress when the human is unavailable, while staying observable, interruptible, and correctable.

Core principle: continue reversible work under an explicit provisional policy; never silently change acceptance criteria or pretend a provisional fallback is final success.

This is a protocol/instruction skill for Claude Code, OpenAI Codex, Hermes Agent, OpenCode, OpenClaw, and other agentic coding workflows. It is not a notifier, daemon, queue, or orchestrator.

Capability Boundary

This skill can require the agent to:

• classify decisions by risk,
• create checkpoints,
• record assumptions and fallbacks,
• emit machine-readable events when tools exist,
• check for feedback at safe points,
• adjust after feedback arrives,
• report what is still provisional.

This skill cannot guarantee by itself:

• Feishu/Lark, Slack, Discord, email, or SMS delivery,
• real-time interruption while a long command is running,
• process kill/restart/resume,
• durable heartbeats after the agent process exits,
• secret-safe notification routing,
• user replies being injected back into the agent.

Those require runtime support: hooks, a wrapper/runner, MCP tools, a gateway such as Hermes, a workflow engine, or platform-specific APIs. Do not claim direct user notification unless a configured notification tool actually returned success.

When to Use

Use for:

• unattended model training, evaluation, hyperparameter search, or data processing,
• long autonomous coding tasks where the user may reply later,
• batch jobs with checkpoints and artifacts,
• experiment loops that should not stop on every uncertainty,
• tasks where provisional fallback is acceptable but final acceptance must remain honest.

Do not use for:

• short one-turn questions,
• irreversible actions with no approved fallback,
• tasks where the user explicitly asked to stop and wait on any ambiguity,
• cases where missing credentials, payment, privacy approval, or production access must be resolved before any useful safe work can proceed.

Decision Classes

1. Auto-continue

The agent may continue without notifying the user when the action is low-risk, reversible, and within the stated goal.

Examples:

• retrying transient network failures,
• reducing batch size once after OOM,
• running a smoke test before a full test suite,
• choosing the documented default command,
• continuing local analysis while a non-critical service is unavailable.

Requirements:

• record the assumption or retry in the decision log,
• preserve artifacts needed to undo or compare,
• do not change the final acceptance criteria.

2. Provisional-continue-with-notification

The agent may continue if no user feedback is available, but must mark the run provisional and emit a notification/checkpoint event for the runtime to deliver.

Examples:

• preferred cloud experiment tracking is unavailable, but local logs can preserve progress,
• several reasonable experiment configurations exist and one default is selected,
• a long training run is about to start within the approved budget,
• a partial evaluation is run first because the full evaluation is blocked or slow.

Requirements:

• record state = provisional_running or equivalent,
• explain what assumption is being made,
• explain what user feedback would change,
• save checkpoints/artifacts before expensive steps when practical,
• keep the final report clear that provisional work is not final acceptance.

3. Must-block

The agent must not proceed without explicit approval when the next action is destructive, irreversible, privacy-sensitive, externally visible, or changes a user-specified acceptance condition.

Examples:

• deleting data or overwriting the only checkpoint,
• production deploys or public releases,
• force-pushing or rewriting shared history,
• spending unapproved money or using extra paid compute,
• exposing secrets, private data, private logs, or credentials,
• uploading sensitive data to a new service,
• changing the required final deliverable and presenting it as accepted,
• requesting or using new credentials/permissions.

If a runtime supports hard blockers, emit an approval request and stop at a safe checkpoint. If no runtime exists, stop and report the blocker.

Checkpoint Protocol

Before starting long-running work, define a compact run contract:

job_id: <stable id if available>
goal: <user-visible goal>
hard_requirements: []
soft_preferences: []
allowed_fallbacks: []
forbidden_fallbacks: []
default_if_no_feedback: continue_with_best_reversible_plan
feedback_checkpoints: []
completion_proof: []

At each checkpoint, report or emit:

{
  "job_id": "train_001",
  "phase": "preflight|running|evaluation|final",
  "state": "running|provisional_running|waiting_feedback|blocked|failed|completed",
  "severity": "info|warning|needs_user|error",
  "summary": "What changed since the previous checkpoint",
  "assumptions": ["Current provisional assumptions"],
  "next_step": "What the agent will do if no feedback arrives",
  "needs_feedback": false,
  "default_if_no_feedback": "Continue with the current plan",
  "can_interrupt_at": "now|next checkpoint|after current command",
  "artifacts": []
}

Create checkpoints at minimum:

• before the first long-running command,
• before spending significant compute or money,
• when choosing a non-obvious default,
• when using a fallback,
• when external logging/notification/storage changes state,
• after each major phase,
• before final completion claims.

Feedback Protocol

At every safe checkpoint, check the feedback channel provided by the runtime: MCP tool, wrapper inbox, file inbox, CLI stdin, issue comment, Feishu/Hermes relay, or another configured mechanism.

When feedback exists:

1. restate the feedback in one sentence,
2. decide whether it overrides a provisional assumption,
3. apply it if safe,
4. if it cannot be applied immediately, state the next safe application point,
5. if rejecting it, explain the safety, feasibility, or conflict reason,
6. record the decision in the log/final report.

User feedback outranks provisional assumptions. It does not automatically authorize destructive, expensive, or privacy-sensitive actions unless it explicitly does so.

External Services and Logging Fallbacks

Do not silently downgrade observability, logging, notification, storage, evaluation, or external reporting.

If a requested service is unavailable:

1. classify whether it is a hard requirement, soft preference, or provisional fallback candidate,
2. emit a warning or needs-user checkpoint,
3. continue only if the fallback is allowed or low-risk and reversible,
4. preserve artifacts needed to recover, sync, or restart,
5. final reports must distinguish verified external success from local/provisional records.

SwanLab / W&B / MLflow Example

If the user required cloud-visible experiment tracking and the cloud service is not logged in or unavailable:

• do not claim cloud tracking succeeded,
• if policy allows provisional continuation, use local/offline logs only as provisional evidence,
• save checkpoints so the run can restart or resume with cloud logging,
• record the local log path and attempted recovery/sync path,
• final completion requires a cloud run URL or an explicit statement that cloud logging remains unmet.

Good status:

SwanLab cloud logging is unavailable. Continuing local/offline as a provisional run under the no-feedback policy. This does not satisfy the cloud-logging acceptance requirement. Checkpoints are being saved for restart or sync.

Bad status:

SwanLab logging is working.

Runtime Integration Pattern

Preferred architecture:

Agent skill -> checkpoint/approval events -> hooks or MCP -> runner/orchestrator -> Hermes/Feishu/Slack/etc.
User reply -> gateway/orchestrator -> feedback store/MCP -> agent checks at checkpoint

Responsibilities:

• Skill: behavior protocol, decision classes, checkpoint content, fallback honesty.
• Hooks: lifecycle events, dangerous-tool gates, turn-stop validation, notification triggers.
• Wrapper/runner: state machine, process control, timeouts, budgets, retries, event store, notification routing, feedback injection.
• MCP server: semantic tools such as feedback.check, checkpoint.post, approval.request, artifact.register.
• Gateway: Feishu/Lark, Slack, Telegram, Discord, email, or other user-facing delivery.
• Files/JSONL: useful fallback/audit transport, not the only trusted control plane for high-stakes runs.

Agent Adapter Notes

Claude Code

Use Claude Code hooks when available:

• Notification for waiting-input or permission-attention events,
• Stop for checkpoint/final summary validation,
• PreToolUse for dangerous action gates,
• PostToolUse for artifact and command logging.

Claude Code can also use MCP tools for feedback and checkpoint posting. Hooks are better for mandatory lifecycle events; MCP is better for semantic agent-initiated actions.

OpenAI Codex

Use Codex lifecycle hooks/notify support when available, or wrap codex exec in a runner that monitors output, exit status, event files, and timeouts.

Codex skills should not embed Feishu/Lark webhook URLs or secrets. Prefer a runner endpoint or MCP server that exposes generic feedback/checkpoint tools.

Hermes Agent or Other Orchestrators

Let the orchestrator own the messaging channel. The agent should emit structured checkpoints and use the orchestrator's feedback mechanism. For durable work, prefer runner, cron, queue, or background-process supervision over relying on a single model turn.

Minimal File Fallback

When no MCP or runner exists, use an explicit run directory as a best-effort fallback:

.agent_runs/<job_id>/
  run_contract.yaml
  events.jsonl
  status.json
  feedback_inbox.md
  decision_log.md
  artifacts/

Rules:

• append important events to events.jsonl,
• update status.json atomically if possible,
• read feedback_inbox.md at checkpoints,
• do not store secrets or credentials,
• mark file-based coordination as best-effort in the final report.

For reliable production use, replace this with a wrapper-owned event store such as SQLite or an append-only service.

Final Report Requirements

The final report must include:

• what was completed,
• which assumptions were used while no feedback was available,
• what feedback arrived and how it changed the plan,
• which fallbacks were used,
• which acceptance requirements are verified,
• which requirements remain provisional or unmet,
• artifact paths, run URLs, checkpoints, logs, and reproduction commands,
• recommended next actions.

Never mark a run complete solely because the agent kept working. Completion requires evidence matching the run contract.

Common Mistakes

• Treating no user reply as permission for irreversible actions.
• Silently replacing a required cloud service with a local/offline substitute.
• Sending secrets or private logs through user notifications.
• Letting the model claim it notified the user when only a local file was written.
• Relying on the agent to poll feedback while it is inside an uninterruptible long command.
• Using one mutable status.json as the only audit trail.
• Reporting provisional progress as final success.

Quick Prompt

Use human-interruptible-unattended-runner. Continue reversible work if I do not reply, but emit checkpoints for anything that may affect acceptance, cost, privacy, or long-running execution. Provisional fallbacks are allowed only when recorded as provisional and recoverable. If feedback arrives later, apply it at the next safe checkpoint and explain what changed.