/cao-supervisor-protocols

name: cao-supervisor-protocols
description: Supervisor-side orchestration patterns for assign, handoff, and idle inbox delivery in CAO

CAO Supervisor Protocols

Use this skill when supervising worker agents through CLI Agent Orchestrator.

This skill covers how supervisors should dispatch work, decide between `assign` and `handoff`, and receive worker results without blocking inbox delivery.

Core MCP Tools

From `cao-mcp-server`, supervisors orchestrate work with:

• `assign(agent_profile, message)` for asynchronous work that returns immediately
• `handoff(agent_profile, message)` for synchronous work that blocks until the worker finishes
• `send_message(message, receiver_id=None)` for direct messages — `receiver_id` defaults to the terminal that created yours via handoff/assign
• `answer_user_prompt(terminal_id, answer)` for answering a Hermes worker that reports `waiting_user_answer`

Your own terminal ID is available in the `CAO_TERMINAL_ID` environment variable. CAO appends it to assigned task messages and records it on worker terminals automatically, so you rarely need to handle it yourself.

Choosing Between Assign and Handoff

Use `assign` when the worker should continue independently and report back later. This is the normal pattern for fan-out work or parallel execution.

Use `handoff` when the next step is blocked on the worker result. The orchestrator waits for completion, captures the worker output, and returns it directly to the supervisor.

Typical pattern:

• Use `assign` for analysis, research, or code changes that can run in parallel.
• Use `handoff` for report generation, blocking review steps, or any task where you need the result before you can continue.

Idle-Based Message Delivery

Assigned workers usually return results through `send_message`. Those inbox messages are delivered to the supervisor automatically when the supervisor terminal becomes idle.

This means supervisors should:

• Dispatch all planned worker tasks first
• Finish the turn after dispatching work
• Avoid running placeholder shell commands just to wait

Do not keep the terminal busy with `sleep`, `echo`, or similar commands while waiting. A busy terminal delays inbox delivery.

If you need multiple worker results, dispatch them all first, then end the turn. Do not poll manually in a loop.

Callback Pattern

By default, CAO appends your terminal ID and callback instructions to every assigned message automatically, and records your terminal as the worker's caller — workers can reply with `send_message` without a `receiver_id`. You do not need to hand-write callback instructions.

You may still include an explicit callback ID in the task message for emphasis:

Analyze dataset A. Send results back to terminal abc123 using send_message.

If your deployment disables the automatic suffix (`CAO_ENABLE_SENDER_ID_INJECTION=false`), the explicit pattern above is required: the structural caller record still works, but the worker gets no in-message reminder.

Direct Supervisor Communication

Use `send_message` when you need to contact an existing terminal directly rather than spawning a new worker.

Examples:

• Relay follow-up instructions to a worker you already created.
• Forward a worker result to another coordinator terminal.
• Send a concise status update to a collaborating supervisor.

When sending direct messages, include enough context that the receiver can act without re-reading the full original task.

Interactive Worker Prompts

Hermes workers can stop on approval prompts or clarify pickers and report `waiting_user_answer`. When a Hermes worker is in that state, do not use `assign`, `handoff`, or `send_message` to answer it. Use `answer_user_prompt(terminal_id, answer)` with the exact selection or text to submit, such as `1`, `o`, or a custom answer.

Other providers may still emit prompts in their terminal output without reporting `waiting_user_answer`. For those providers, treat the prompt as ordinary terminal output and answer it with `send_message` or direct input according to the workflow you are running.

Practical Workflow

1. Dispatch asynchronous workers with `assign` — callback routing is automatic (your terminal ID is appended to the message and recorded as the worker's caller). 2. Use `handoff` only for steps that must finish before you can continue. 3. End the turn so asynchronous worker messages can be delivered. 4. When messages arrive, synthesize the results and continue the workflow.

Reliability Guidelines

• Tell workers exactly what deliverable they should return.
• When workers create files, ask them to return absolute paths in their callback message.
• Do not assume results will be delivered while your terminal is still busy.
• Keep orchestration instructions separate from domain requirements so workers can parse both cleanly.