The hard part of an SMS AI agent is not the model

The short version

• An SMS AI agent reads inbound texts, decides, and replies without a human drafting each message.
• In the United States, application-to-person texting from an ordinary ten-digit number requires sender registration before carriers will deliver it reliably.
• Opt-out belongs in deterministic code in front of the model, because 'take me off this list' is not the keyword STOP.
• SMS conversations pause for days, so history has to be stored durably and keyed to the phone number.
• Messages are billed per segment, so a long chatty reply costs several times what a short one costs.

What is an SMS AI agent actually doing?

It sits behind a phone number and answers it. An inbound text arrives at your messaging provider, the provider posts it to a webhook, your code loads the history for that number, the model decides on a reply or a tool call, and one or more outbound messages go back through the same number. That loop is the whole agent. Everything else is scaffolding that keeps the loop honest.

The useful ones have tools. Check availability and hold a slot, look up an order, resend a tracking link, take a reschedule, write the outcome back to the CRM, escalate to a person with the thread attached. An agent with no tools is a frequently asked questions page that costs money per message.

Identity is the first thing to get right, because a phone number is weaker proof than a logged-in session. Numbers are shared within families, reassigned by carriers, ported between providers, and typed in wrong. Treat the number as a hint about who is texting, enough to load context, not enough to disclose anything you would not say out loud in a waiting room. Anything sensitive moves to a link that makes the person sign in.

Why is SMS harder than a chat widget?

Because the conversation has no beginning and no end. A chat widget gives you a session: it opens when the page loads, it closes when the tab does, and you can reasonably assume somebody is sitting there. A phone thread is permanent and mostly dormant. The reply to your question might come in forty seconds or in four days, and it might be the single word 'yes'.

There is also no interface to lean on. No buttons, no date picker, no file upload with a validated type, no layout the agent controls. Everything is plain text in both directions, so every constraint you would normally express in a form has to be expressed in a sentence and then checked again when the answer comes back wrong. People send one thought as three messages, reply to something from last week, attach a photo with no caption, and say 'the other one' about an item they never named.

Delivery is not reading. A carrier receipt tells you a handset accepted the message. It does not tell you a person read it, and filtering can drop a message with no useful signal at all. Design so no step depends on the previous message having been seen. In practice that means short self-contained messages, and a debounce window before you call the model, so three fragments arriving in two seconds produce one reply instead of three.

What changes when the channel is a phone number?

What do carriers and regulators expect before you send a single message?

Consent you can produce on request, a registered sender, and an opt-out that works. In the United States, application-to-person traffic on an ordinary ten-digit number goes through 10DLC brand and campaign registration, and toll-free senders have their own verification path. Skipping it does not produce an error. It produces filtering, which looks exactly like customers ignoring you. Rules elsewhere differ, and consent law in particular is jurisdiction specific, so that part is a question for your own counsel rather than a blog post.

Opt-out is where agents quietly fail. Platform keyword handling catches STOP. It does not catch 'stop texting me', 'unsubscribe me please', 'take me off this list', or 'leave me alone'. Those are the ones a model is asked to interpret, and a model that interprets correctly most of the time is not good enough for a request with legal weight behind it. Put a deterministic opt-out check in front of the model, log every match, and apply the result to every system that can send to that number, including the marketing platform nobody mentioned at kick-off.

Then decide whether the agent may start conversations or only reply to them. Reply-only is a much smaller problem: the person texted you, the consent question is simpler, and timing takes care of itself. Once the agent initiates, you have inherited quiet hours, frequency limits and the consent record for every number on the list. An agent that answers at 03:00 because the model never sleeps is behaving correctly and still doing damage.

Small detail, large effect: send links on a domain you control. Shared public shorteners are heavily filtered because spammers use them, so the one message in your flow carrying the booking link is the message most likely to disappear.

How do you keep state when the conversation pauses for days?

Store it. The conversation has to live in a durable record keyed to the number, with an explicit rule for when a dormant thread counts as a new conversation rather than a continuation. Anything held in a request-scoped object is gone before the reply arrives. That sounds obvious, and it is still the most common reason an SMS agent feels stupid: the history was always there in testing, because everyone replied within a minute.

Durable history forces a retention decision you cannot defer. Text threads accumulate addresses, order details, complaints and occasionally things about somebody's health that they volunteered. 'We keep everything' is an awkward answer the first time a customer asks what you hold about them. Separate what the agent needs for continuity, which is usually recent and short, from what the business wants for analysis, and set a deletion policy for message bodies before launch rather than after the first request.

Expect duplicates and reordering. Webhooks retry, providers resend, and two messages sent a second apart can arrive the wrong way round. Deduplicate on the provider's message identifier, and make every tool call idempotent so a retried webhook does not create a second booking. A double reply is embarrassing. A double appointment is a phone call from a receptionist asking what happened.

Re-ground on resume. When 'yes' arrives four days after the question, the agent needs to know what it is agreeing to and whether that still holds. If the slot has gone, the right message says so and offers the next one. Guessing is how an agent confirms an appointment that does not exist.

What should an SMS AI agent not try to do?

Anything that needs more than a couple of short messages, anything that needs sensitive data, and anything expensive to undo. Text is a good channel for a narrow exchange with a clear end. It is a poor channel for depth, and the common failure is not a hallucination, it is an agent dragging somebody through six questions they would have answered in one web form.

Regulated work deserves a harder line. Clinical detail, payment data and identity documents do not belong in a channel that sits unencrypted in a notifications pane on a handset other people pick up. The agent can confirm an appointment and send an authenticated link. It should not take a card number by text, and it should not discuss a diagnosis just because the person raised it first.

Where should the agent stop and do something else?

• •Long explanations. If the honest answer runs to several hundred words, send one line and a link.
• •Card numbers, passwords, ID documents and clinical specifics. Move to an authenticated page.
• •Multi-field forms. Four questions by text is four chances to be abandoned.
• •Anything irreversible without an explicit confirmation step, such as cancelling a policy or a booking somebody else made.
• •Arguing. If a person repeats themselves, the next message should contain a human.

What does an SMS AI agent cost to run?

Three things: carrier fees per message, model tokens per turn, and the registration and number rental underneath. Carrier fees are the line people underestimate, because messages are billed per segment rather than per reply. A segment is 160 characters of the standard GSM encoding, or 70 characters once any character forces the Unicode encoding, so a single emoji in a long message can more than double what that message costs to send.

That changes how you write the agent. A chatty model that sends four paragraphs where one line would do is not only worse to read, it is several times the price at volume, on every conversation. Cap the reply length in the system prompt, then cap it again in code, because a prompt is a preference and a truncation is a rule. Short replies also survive the channel better: people read them, and they fit on a lock screen.

Model cost is usually the smaller line, and the pricing model is worth watching. Some vendors now price agents per resolved conversation rather than per seat, which makes forecasting a different exercise from licensing a support desk. Either way, the number to track is cost per resolved conversation, not cost per message. An agent that trims a few tokens and adds two turns has lost money.

How do you tell whether it is working?

Read the transcripts, and watch the opt-out rate. Opt-outs are the most honest quality signal available, because leaving takes deliberate effort and people only make it when the experience is bad enough. If opt-outs climb in the weeks after the agent goes live, nothing else on the dashboard matters.

Past that, measure the few things that describe this channel. How many conversations ended without a human. How often the agent handed off, and whether the handoff landed with somebody who actually replied. Messages per resolved conversation, where lower is better and a rising number usually means the agent is asking instead of acting. Delivery failure rate per sending number, which is how you spot carrier filtering before your customers tell you. And the share of conversations where the agent repeated itself, which is the cheapest proxy for a stuck loop.

Build a replay harness early. Take real transcripts, strip the identifiers, and run them through every prompt change before it ships, because what makes an agent worse is almost never visible in the one conversation you tried by hand. Nobody enjoys building this. It is the whole difference between changing a prompt and guessing at one.