Updated September 5, 2026 · by the MOST team
| Route | Best for | What you build | Compliance |
|---|---|---|---|
| DIY on a carrier API | Developers who want control | Number purchase, A2P brand + campaign, a send_message tool, inbound webhook handling, opt-out logic | You own all of it |
| AI business line (MOST) | Anyone who wants it working, not built | Nothing — call the existing send + receive tools over the API/MCP | Filed and handled for you |
An agent can only send SMS from a real phone number that can send SMS — a local 10DLC number or a toll-free number from a carrier platform (Telnyx, Twilio) or an all-in-one platform.
US carriers block business SMS from unregistered numbers. Register a brand and a campaign describing the agent’s messages with The Campaign Registry before the agent can reliably send. Sole-proprietor registration works without an EIN.
Expose a send_message tool (function/tool call) that the agent invokes with a recipient and body. On a carrier API this is your own wrapper around the SMS endpoint; on a platform with an MCP server or JSON-RPC API, the tool already exists.
Point inbound-message webhooks back at the agent so it can read replies, and honor STOP/HELP automatically. A one-way agent that can’t hear replies or stop on request is both useless and non-compliant.
Rate-limit the agent, require identification in the first message, and keep a human escalation path. Autonomous senders that blast unidentified messages get filtered and can get the number suspended.
However you build it, the shape is the same: the agent calls a tool with a destination and a body, and a delivery layer sends it over a registered number and returns a message id. With MOST that tool is already exposed over a JSON-RPC/MCP endpoint — see the send a message and authentication docs — so an agent can text and read replies with an API key and no telephony code.
If you're building an agent and enjoy owning telephony, wire a carrier API. If you want your agent texting customers this week without becoming a telecom engineer, MOST is the best option: the number, the A2P registration, and the send/receive tools arrive together, so the agent just calls a tool — $49/month, compliance included.
MOST gives your AI a registered business number and send + receive tools over one API — provision it from a sentence, no telephony code, live in as fast as 24 hours.
Give the agent three things: a text-capable phone number, A2P 10DLC carrier registration so US networks deliver its messages, and a send tool it can call (a function that takes a recipient and body). Developers wire this on a carrier API like Telnyx or Twilio; no-code users use a platform such as MOST that provisions the number, files the registration, and exposes the AI’s send + reply tools without building anything.
Not by itself — a language model has no telephony. You connect it to a messaging API through a tool/function call: the model decides what to send, and the tool actually delivers it over a registered number. The model never touches the carrier; your tool layer does, which is also where compliance (registration, opt-out, rate limits) lives.
Yes. There is no exemption for AI. Any automated (application-to-person) SMS from a US local number must run on a registered brand and campaign, or carriers filter or block it. An agent sending from an unregistered number will see its messages silently disappear.
An all-in-one AI business line. MOST provisions the number, files the A2P registration for you (including the no-EIN sole-proprietor path), and exposes send + receive as tools over a JSON-RPC/MCP API — so your agent can text and read replies without you building telephony or handling carrier compliance.
Inbound texts arrive as webhooks from the carrier. You route them to the agent (or the platform does), so it sees the reply and can respond, book, or escalate. Two-way is the point — and platforms handle the inbound plumbing and STOP/HELP compliance for you.