Follow up when nobody replies
Schedule a follow-up on the same thread when you send, and cancel it the moment the person answers, over MCP or REST.
At the end of this recipe an agent will send a message, schedule its own follow-up on the same thread in case nobody answers, and withdraw that follow-up when the reply arrives first. Nobody gets "just checking in" after they already answered.
The follow-up is scheduled up front rather than decided later, so it goes out on time even if the agent is not running on day three. The agent's only job afterwards is to cancel it when a reply lands.
Before you start
- A verified sending domain with its optional MX record published, as in Send an email from your agent and read the reply.
1. Send the first message
Email me@example.org from hello@mail.example.com asking for the signed contract.
send_email answers with the message id (call it FIRST_ID) and its thread_id.
2. Schedule the follow-up on the same thread
Schedule a follow-up to that message in 3 days: "Just checking whether the contract is ready." Keep it on the same thread and remember its id.
The agent calls reply_to_message with reply_to_message_id set to FIRST_ID and scheduled_at: "in 3 days". It answers status: "scheduled" with the follow-up's own id (FOLLOW_UP_ID) and the same thread_id. A scheduled message does not count on the thread until it goes out, so the thread is not marked as answered in the meantime.
3. When the reply arrives, cancel the follow-up
Reply from me@example.org. The thread now shows awaiting_reply: true with your reply as its latest inbound entry.
Check for replies. If the contract thread has one, cancel the scheduled follow-up and answer the reply.
The agent calls list_threads with awaiting_reply: true, finds the thread, calls cancel_scheduled_email with FOLLOW_UP_ID and gets status: "canceled". A 200 means the follow-up will not go out, even if its time had already come. It then answers with reply_to_message as usual.
If nobody replies, do nothing: the follow-up goes out on day three on the same thread, and step 2 can be repeated for a second one.
The same flow over REST
An application that already receives the inbound webhook can cancel from its handler instead of polling: the event carries the thread_id, which is enough to look up the follow-up it scheduled. See Webhooks.
Edge cases
| Situation | What happens |
|---|---|
| The reply arrives while the follow-up is being sent | cancel_scheduled_email answers 409 invalid_state and names the status. The follow-up went out; acknowledge it in your answer rather than pretending it did not. |
| The reply is an out-of-office | Automatic replies do not set awaiting_reply, so the follow-up stays scheduled, which is usually right. |
| The key holds sends for approval | The follow-up is drafted as pending_approval rather than scheduled, and keeps its schedule when a person approves it. A held draft is withdrawn by rejecting its approval, not with cancel_scheduled_email. |
Sequences for many people
For a fixed series of emails to everyone who signs up or starts a trial, use an automation instead. It sends from your marketing domain, and ends a person's enrolment on its own when they reply (by default), unsubscribe, bounce or opt out of its topic, with nothing to cancel by hand.