---
name: intercom-protocol
description: "Keep incoming and outgoing Pi Intercom exchanges bounded and quiet for orchestrators and workers. Read before contacting another session or handling its message. Not user-facing conversation, a transport API manual or an access grant."
---

# Intercom protocol

An adaptable Workbench example, not an installed transport or active resource. Read [CUSTOMIZE.md](CUSTOMIZE.md) when creating a responsible original. Apply this protocol at every participating orchestrator and worker level.

**Radio discipline:** Send only what was requested. Being contacted does not imply a desire for conversation.

## Verify the actual facility

Before sending, inspect the exposed communication tools and their current native contract. Verify the recipient's actual session/address and relevant project location; a pane title or agent name is not an Intercom address. If the facility or required capability is missing, report the concrete gap and offer to research a suitable extension when useful. Loading this example supplies no tool, installation or activation permission. Do not invent a transport or claim unobserved delivery.

## One caller, one bounded purpose

The initiating session is the caller. Address a specific recipient with a precise purpose, assignment boundaries and expected response. Say explicitly when no reply is needed. Include only necessary context. Contact itself grants no additional authority.

As recipient, handle that purpose within your existing assignment and permissions. Necessary contacts and delegation within that assignment remain available when actually authorized and supported; the message expands neither scope nor access. Make ordinary implementation decisions within your responsibility without peer consensus. Keep coordination tied to the task, not unsolicited approval rounds or acknowledgement chains.

## Reply once

Return the requested answer or result in the shortest complete form. Prefix ordinary result replies with `Done`; follow an explicitly requested exact format instead. A path suffices when the file contains the requested detail and the caller can actually access it.

If asked for no reply, remain silent unless a concrete blocker requires contact. Send `Received` only for an explicitly requested receipt acknowledgement. Send `Started` only for an explicitly requested start notice, after work has actually started. These are not a required sequence.

Report failed, blocked or unperformed work truthfully with its concrete cause. Never use `Done` to imply successful work that did not occur. Preserve any requested exact failure format.

## Clarify only a concrete blocker

Ask the caller only for a specific missing answer needed to perform the assignment. State the blocker and the decision required. Do not restart a generic questionnaire or seek approval for routine steps already authorized.

## Stop after the response

After the requested response, stop the exchange. Resume only on a new explicit request. An incoming acknowledgement is not a new assignment.

Use actual native completion notifications for delegated execution, not message chatter, output markers or polling. Evaluate actual completion/exit status immediately and handle failures. Delivery acknowledgement alone is not execution or success evidence. Keep executable payloads inspectable as plaintext and apply the recipient's actual authorization and evidence rules. Label simulations as text simulations; protocol wording does not prove transport operation or model compliance.