Agent Supervision

Agent Supervision

Run lightweight, evidence-first supervision for another OpenClaw agent.

Prefer short fixed-format messages, low token usage, and minimal tools. Use this skill to keep another agent moving without turning supervision into a long debate.

Quick start

Before wiring any automation, confirm four things:

1. target sessionKey 2. supervision mode: fixed interval or ETA 3. definition of progress 4. escalation threshold

If any of these is missing, ask first.

Required inputs

Collect these before creating supervision:

1. Target session key - Usually the other agent's direct session key, for example: agent:boss:feishu:boss:direct:ou_xxx - This is the primary identifier needed to read and send messages.

2. Supervision mode - every: fixed interval, such as every 10 minutes. - eta: let the target report goal + ETA + deliverable, then check at ETA. - Hybrid is allowed: fixed interval cron running ETA-aware logic.

3. Progress standard - Decide what counts as progress: - new deliverable - new file/disk evidence - new online evidence - version increment only - blocker changed

4. Escalation rule - Example: after 3 stagnant checks, require either new evidence or a blocker list.

5. Delivery policy - Prefer isolated bridge cron + delivery.mode=none. - Do not assume sessions_send timeout means failure.

What this skill is good for

Use it for:

Do not use it when the user only wants a one-off reminder or a human management policy memo with no automation.

Recommended architecture

Use this pattern by default:

Why:

Supervision workflow

1. Read recent target messages

Read only the last 5-8 messages unless the user explicitly wants deeper review.

Look for:

2. Judge status with short codes

Prefer compact states:

Do not reward narrative updates without evidence.

3. Send a short supervision message

Examples:

4. Verify delivery on send timeout

If sessions_send returns timeout, do not conclude failure immediately.

Instead:

1. read the target session again 2. inspect the last 3 messages 3. if the supervision text appears, treat delivery as successful

This matters because cross-session sends may time out synchronously while the message still lands.

ETA mode rules

Use ETA mode when the user wants less noisy supervision.

Default rules:

Reject vague replies like:

unless they also include a concrete blocker and next check promise.

Fixed-interval mode rules

Use fixed interval mode when the user wants hard periodic nudges.

Recommended defaults:

What the skill needs from the user

At minimum, ask for:

Without the session key, the skill cannot reliably supervise the other agent.

Minimal cron template

Use an isolated cron with payload like this shape:

{
  "kind": "agentTurn",
  "message": "Read recent target messages, classify A/P/W/R/E4, send one short supervision line, and verify delivery only if send times out.",
  "timeoutSeconds": 120,
  "toolsAllow": ["sessions_send", "sessions_history"],
  "thinking": "off",
  "lightContext": true
}

Operational defaults:

Example user requests

Typical requests that should trigger this skill:

Guardrails

When reporting back to the user

Use this shape:

Keep it short and verifiable.

Public-release notes

For public distribution, keep the positioning generic:

Ship examples, defaults, and guardrails; leave project-specific policy to the caller.

Before wiring any automation, confirm four things:

1. target sessionKey 2. supervision mode: fixed interval or ETA 3. definition of progress 4. escalation threshold

If any of these is missing, ask first.