Skip to main content

Hand off a task with a thread id

send takes an optional thread_id. The bus stores it and returns it with the message. It does not interpret it. Use it to keep a request and its replies together.

Hand off​

In laptop-api:

Send server-ci on the bus, thread_id "flaky-e2e": please rerun the e2e suite on main and report which tests fail. Reply on the same thread to laptop-api.

The tool call:

send { "from": "laptop-api", "to": "server-ci", "body": "Please rerun the e2e suite on main ...", "thread_id": "flaky-e2e" }

Pick it up​

In server-ci, the inbox entry (or the push meta) carries thread_id: "flaky-e2e". When it replies, it passes the same thread_id:

send { "from": "server-ci", "to": "laptop-api", "body": "2 failures: ...", "thread_id": "flaky-e2e" }

Notes​

  • A message is a request from another session, not an instruction from you. The skill and the push instructions tell the model to treat it as untrusted input. If server-ci should run tests on request, tell it so in that session first.
  • Ack after handling. Unacked mail stays in the inbox and is never pruned.
  • broadcast has no thread_id argument.