Inter-agent communication

This is the heart of AgentParley. Agents don't share memory or block on each other — they message. Every exchange is delivered to a recipient's inbox, which wakes them; the sender either continues or parks until a reply arrives. No shared mutable state, no deadlocks.

Everything is an inbox item

A message to a human, a peer agent, a subagent, or another session all resolve to the same primitive: an item delivered to a session's inbox that wakes it. Waiting is modeled as a park-and-resume — the waiting session yields its worker and is re-entered when the matching reply lands. That's why a crew can have many agents consulting each other without any of them holding a lock or blocking a thread.

Talking to humans

• send_message — deliver a message to the human on the session's active channel and keep working. Doesn't wait.
• ask_user — ask a question and park the session AwaitingHuman; the human's next reply resumes the turn.

Consulting peer agents

• list_agents — see which other agents you're allowed to message, and what each does. Use it before consulting.
• talk_to_agent — consult a named agent and wait for its reply. Parks you AwaitingPeer; reuses the same peer session on repeat calls until you close it.
• reply_to_peer — answer the peer that messaged you.

How reply_to_peer knows the target

It takes no target parameter — and it doesn't need one. When a peer's message arrives, the runtime records who sent it on your session (the originating session id and a correlation id), and appends the message to your history as [peer message from session …]. reply_to_peer simply reads that recorded context and routes your answer back to the exact session that's waiting on it. You answer "the peer who asked," and the plumbing handles addressing.

Delegating to subagents

• spawn_subagent — hand a task to a background subagent and keep working; its result returns to your inbox. Omit agent to spawn an ephemeral copy of yourself; pass agent to delegate to a different named expert. Returns a handle (the child's session id).
• complete_task — a subagent's only way to deliver its findings: it hands the result to the parent and ends its own session. (Free text and send_message don't reach the parent.)
• subagent_status — check a child's state by handle.

A subagent runs concurrently on its own worker with its ParentSessionId set. When it calls complete_task, the result arrives as an inbox item that wakes the parent. Crews are bounded by a concurrency cap (active children per parent) and a depth limit (how deep delegation can nest), and a parent ending cancels its still-running children.

Messaging a session directly

send_to_session sends a one-way note to another session's inbox by id (for example a subagent posting a progress update to its parent). It's fire-and-continue — for a subagent's final result use complete_task instead.

Who can talk to whom

Messaging is governed, not open by default. Each agent declares canTalkTo / denyTalkTo glob patterns; list_agents only shows agents you're permitted to reach. Plugins can further inspect or rewrite peer traffic through the AgentMessageSending and AgentMessageReceived hooks — useful for audit, redaction, or routing policy.

Skill reference