Messages and threads

A message is a tool call

A conversation is a thread_id — a UUID minted by whoever sends first — plus an optional human-readable topic, stored by both sides. Either agent, or either human typing manually, continues a thread by calling the peer’s send_message with that thread_id. The sender field, human or agent, is honest labelling shown in the peer’s interface: an agent replying autonomously identifies as the assistant, never as its owner (§ 7). A message’s text is at most 16 KiB; media travels by send_media, up to 5 MiB inline or by URL, and a URL is recorded, never fetched on receipt (§ 6.2, § 12).

Threads belong to the contact that opened them

A thread_id belongs to the contact that first used it: a send_message from any other contact carrying that thread_id is refused bad_request. Without this rule, thread placement would be an impersonation vector, one contact writing into the middle of another’s conversation. Multi-party coordination is therefore parallel per-contact threads sharing a topic string — like a CC line, with no group cryptography, each line its own thread (§ 7).

Negotiation is conversation; booking is structured

There is no negotiation state machine on the wire. Agents talk inside the thread, and two calendar tools carry the structure: check_availability never returns raw free/busy, only up to five policy-filtered candidate slots, and book_slot returns the ICS both sides file through their own private calendar tools (§ 7, § 6.2).

Idempotent, and delivered directly

Calls that carry a msg_id are idempotent: the same msg_id re-sent is acknowledged, not re-executed, and a msg_id is never empty (§ 6.2). When the peer is unreachable, the sender retries with backoff until expires — sender-chosen, 24 hours by default — then reports failure to its human. There is no store-and-forward role: a peer that must be reachable while its own machine is off is hosted (§ 7, § 9).