reply_message
Send a threaded Markdown reply to an existing Swarmail message; it defaults to the original sender, inherits subject and importance, and returns the stored reply.
Instructions
Reply in a message's thread, returning the stored message with reply_to. message_id selects the original in this project. Omit to to address its sender; cc and bcc are added only when supplied. The original's topic and importance are inherited, with a 'Re:' subject; importance can be overridden. ack_required defaults to false; set it explicitly to request acknowledgement of this reply. For retries within 7 days, reuse a nonempty idempotency_key with identical arguments. To start a new thread, use send_message. Send only when the recipient needs to act or know: a handoff, requested result, blocker or shared-resource change. Make clear to the human and receiver whether the message informs or requests work; for requests, name the action, repository and owner. Distinguish implementing source, installing an update and adding guidance. Write coordination messages in Markdown. Open with the action, decision or changed result. Add up to three short facts the receiver needs, then a Next action line naming the requested action or stating No action requested. Link supporting records on an Evidence line; omit that line when no record exists. Keep the requested action, authority, scope and essential holds inline. Put logs, metrics, hashes, execution details and authorization history in the linked records. When a decision depends on those details, ask the receiver to inspect the record. Preserve exact identifiers, paths and commands. Use spaces between words and numbers. Under T3 Code, refer to another agent by its thread link, title, not its registered name; use the name only if the user asks, no thread id is known or T3 fails. Elsewhere include its verified session title or repository beside its name; use this session for the current receiver only after matching session identity. For relayed authorization, preserve the source, exact selected action and target owner; a relayed bare approval such as "B" or "go" is ambiguous. Contact only still-dependent resource owners, sending release or cancellation before dropping waiting recipients. For resource coordination, name only the resource, finite phase boundary and receiver action; omit unrelated progress and errors. Use resource_notice for typed release/cancellation mail; it generates readable text and derives quiet or actionable delivery. Use one supported transport per recipient and purpose; uncertain delivery is not a reason to resend by another route. Keep routine progress in your own conversation; do not send courtesy acknowledgements or reply to thanks.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | Recipients copied, visible to everyone. | |
| to | No | Recipients; default the original sender. | |
| bcc | No | Recipients the others do not see. | |
| body_md | Yes | The reply body, in Markdown. | |
| importance | No | low, normal, high or urgent. | |
| message_id | Yes | The message to reply to. | |
| project_key | Yes | Absolute path of the repository's primary checkout. | |
| sender_name | Yes | Your registered agent name. | |
| ack_required | No | Ask recipients to call acknowledge_message. | |
| subject_prefix | No | Default 'Re:'; not added twice. | |
| delivery_policy | No | checked (default) or durable. Both currently admit and store mail the same way. Neither bypasses closed T3 or unavailable bound sources. Unqualified standalone state remains unknown and is returned with warnings; storage does not transfer task ownership. | |
| idempotency_key | No | Nonempty key for this tool and agent. Identical arguments replay with idempotent_replay:true; different arguments fail with IDEMPOTENCY_KEY_CONFLICT. Cleanup runs at server startup and hourly, removing keys older than 7 days. Retries can replay until removal; afterward a retry may perform the operation again. | |
| notification_policy | No | wake permits automatic inbox hints. quiet stores normal/low mail for inbox/search without waking the recipient; high/urgent importance or ack_required:true rejects. Omitted policy defaults to quiet only for normal/low, acknowledgement-free mail when every recipient has a valid registered T3 thread ID; otherwise wake. Ping probes keep wake by default. Replies use this same rule, not the original policy. Set wake explicitly for actionable handoffs, requested results and blockers. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cc | Yes | ||
| id | Yes | ||
| to | Yes | ||
| bcc | Yes | ||
| from | Yes | ||
| topic | Yes | ||
| body_md | Yes | ||
| subject | Yes | ||
| delivery | No | ||
| reply_to | Yes | ||
| revision | No | ||
| sender_id | Yes | ||
| thread_id | Yes | ||
| created_ts | Yes | ||
| importance | Yes | ||
| project_id | Yes | ||
| ack_required | Yes | ||
| sender_location | Yes | ||
| idempotent_replay | No | ||
| notification_policy | No |