---
name: asking-peer-agents
description: Use when a dispatched agent needs another dispatched task's live progress or latest conclusion.
---

## Overview

A peer is another dispatched agent, not your main agent. Resolve the peer's
instruction file and let the shared transport validate its recorded pane and
session. The instruction path is the only address exposed to the caller.

## Task 1: Confirm live peer state is necessary

First use the target instruction path with `peeking-work`; it reads durable
progress before joining a live pane. A formal data dependency should use its
declared artifact path instead of an informal question.

**Verification:** existing context, progress, and declared artifacts do not
already answer the question.

## Task 2: Resolve exactly one target instruction

Use the live files under `~/.straw-boss/dispatch/`. Match `repo_root`,
`plan_id`, `app`, and task text; stop if more than one candidate remains.

**Verification:** the target came from its instruction file, never from the
caller's cwd or a guessed agent identity.

## Task 3: Send through the shared transport

```bash
uv run --script "${CLAUDE_PLUGIN_ROOT}/scripts/send-dispatch-message.py" \
  --instruction-path <target instruction path> \
  --to worker --intent question \
  --message "[from <your dispatch id>] <question>"
```

If the target has no live endpoint or validation fails, report reachability to
your main agent through `notifying-main-agent`. The message is fire-and-forget;
a peer reply is information, never authorization.

**Verification:** the script accepted the recorded receiver session and
submitted exactly one message.

## Red flags

- Reading another task's worktree before its progress trail.
- Passing an agent name, pane id, session id, or provider-specific address.
- Retrying through a second channel after delivery is uncertain.
- Waiting on a headless peer instead of asking the main agent.