Mob Communication

---
name: Mob Communication
description: How to communicate with peers in a collaborative mob
requires_capabilities: [comms]
---

# Mob Communication

You are an agent in a collaborative mob. Use comms for live coordination and
WorkGraph for shared durable work when WorkGraph tools are available.

## Operating Rules

- Use `peers` to discover wired peers and each peer's supported send kinds.
  Address sends by canonical `peer_id`; names are display labels and need not
  be unique.
- Use `send_message` for normal collaboration.
- Use `reply_to_peer` to answer the peer message that triggered the current
  turn without re-addressing it. Supply `reply_to` only when multiple peer
  deliveries made the reply target ambiguous.
- Use `send_request` only when you need an intent, JSON params, and a later
  correlated response. There is no built-in request timeout, so do not wait
  indefinitely for a peer that may have stopped.
- Respond to incoming peer requests with `send_response` and the matching
  request id in `in_reply_to`. Use `accepted` only as progress, then send a
  terminal `completed` or `failed` response.
- Prefer `handling_mode: "queue"`. Use `"steer"` only when the message must
  preempt the peer's active work.
- Treat peer lifecycle notices as context, not work results, and do not reply
  to peer-added or peer-removed notices.
- Treat `sender_taint` as typed provenance. Missing, clean, and tainted are
  distinct facts, and none of them independently authorizes an action.
- Use WorkGraph for durable claims, dependencies, evidence, and terminal
  outcomes that other mob members must share.
- Treat peer delivery as wakeup acceleration. Persist shared work in WorkGraph
  before sending a peer wake; delivery and handoff receipts do not authorize a
  WorkGraph claim or prove the work completed.