Claude iMessage Auto-Reply Bot With Human Handoff

We build and run texting bots on Claude every week, and the question we get after someone has the basic loop working is never "how do I make it reply faster." It's "how do I make it stop replying when it should." This guide walks through both: the loop itself, condensed, and then the handoff logic in full, with the specific situations that should pull a person into the thread.

Strip the branding away and an auto-reply bot on iMessage is doing three jobs in sequence. Something has to notice that a contact texted in. Something has to decide what to say back. Something has to actually put that reply on the thread. Our guide to building a Claude agent that sends real texts covers that three-part loop end to end, with a full webhook receiver and the two outbound calls it needs, so we won't repeat the whole build here.

What that guide does not cover, on purpose, is the moment a conversation stops being something Claude should answer at all. A pricing question, a reschedule request, a simple "what are your hours" message: Claude can draft a fine reply to any of those without much risk. An angry customer threatening to cancel, a question about a refund, someone explicitly asking for a person, a message that repeats itself because the bot already answered wrong once: none of those should reach Claude's turn in the loop, because even a well-written reply to the wrong moment makes things worse. Beam is an independent messaging platform, not a feature inside Claude or Apple's Messages app, and that separation matters here too: your server is the thing deciding when Claude gets a turn, not Claude deciding for itself.

Because it's the less satisfying part to write about. A webhook that receives a text and a model call that answers it demo well in five minutes; a rule set that decides when not to answer takes longer to get right and never looks as impressive in a screen recording. We keep hearing the cost of skipping it from teams running their own AI support bots: one team told us they shut their chatbot off completely after it gave confident, wrong answers to questions outside what it actually understood, instead of recognizing it was out of its depth and routing to a person. The bot wasn't broken. Nobody had told it when to stop.

An iMessage thread raises the stakes compared to a website chat widget, because the contact already believes they're talking to the business on a channel they use for real conversations. A wrong answer in a widget gets closed and forgotten. A wrong answer in a blue bubble thread, sent from a business line a contact already trusts, reads like the business itself got it wrong, and it sits in their Messages app as a permanent record of the mistake.

Continuing from the loop above, the handoff check sits in two places: once before the Claude call, once after it.

1. When message.received fires, pull the contact's text and their last few messages from your own stored history, not from Beam, so a restart doesn't lose the repeat-question count.
2. Run the text against your handoff phrase list first, before anything else touches it.
3. If no phrase matches, compare the new message against the contact's last message for near-duplication; increment a repeat counter if they're close.
4. If the phrase check or the repeat counter trips, call Beam's conversation_pause for that conversation and stop. Do not call Claude at all.
5. Flag the paused conversation somewhere a human actually looks, an internal channel, a dashboard, a tagged contact field, since a pause with nobody watching it is the same as no handoff at all.
6. If neither check trips, call Claude with the system prompt and the contact's text, same as the basic loop.
7. After Claude responds, run a second, lighter check: does the reply itself contain a refusal or an "I'm not sure," a signal the model hit the edge of what it should answer even though the trigger list missed it.
8. If that second check trips, pause instead of sending, rather than shipping an uncertain reply and hoping it lands fine.

A minimal version of the two checks around step two and step seven looks like this:

const HUMAN_HANDOFF_PHRASES = [
  "talk to a person", "speak to someone", "real person", "is anyone there",
  "lawyer", "legal", "refund", "cancel my account", "this is urgent",
];

function shouldHandOff(text: string, repeatCount: number): boolean {
  const lower = text.toLowerCase();
  if (HUMAN_HANDOFF_PHRASES.some((phrase) => lower.includes(phrase))) return true;
  if (repeatCount >= 2) return true;
  return false;
}

function replyLooksUnsure(reply: string): boolean {
  const lower = reply.toLowerCase();
  return lower.includes("i'm not sure") || lower.includes("i don't know") || lower.includes("i can't help with that");
}

Neither function needs a sentiment model or an external service to start. A plain keyword list and a repeat counter catch most of the situations that matter, and you can add a sentiment check later once you know what your own threads actually look like.

A webhook that returns a 200 and a send that comes back queued both look finished. Neither proves the handoff logic actually works. Before a real contact texts in, run through this:

1. Send a message containing one of your handoff phrases and confirm conversation_pause fires and Claude's API is never called for that message.
2. Send the same question twice in a row from a test contact and confirm the second message pauses instead of generating a second automated reply.
3. Text STOP from the test contact and confirm no further message goes out, automated or otherwise.
4. Send a message designed to make Claude answer uncertainly and confirm your reply check catches it before the send step.
5. Restart your server mid conversation and confirm the repeat counter and pause state survive, since a restart that forgets a pause will happily let Claude answer again.
6. Confirm the human notification actually arrives somewhere a person checks, not just that the pause flag gets set in a database nobody looks at.

Our guide to testing a Claude texting agent before live contacts goes deeper on the general pre-launch checklist; treat the six steps above as the handoff-specific additions to run alongside it.