SMS

AI SMS and telephony: inbound and outbound, on your own gateway

SMS and voice are the channels agents struggle to reach — carrier rules, webhooks, realtime audio. The pattern: host your own telephony gateway on a Pocket machine.

WhatsApp and email have clean APIs and forgiving latencies. SMS and telephony do not: carrier filters, number reputation, per-country rules, and — for voice — the brutal realtime constraint that a phone call cannot buffer. This is the pattern that works, built the way Pocket's channel model is designed: native channels where the industry allows it, and your own gateway on your own machine for everything else.

Why a gateway on a machine, not a SaaS checkbox

Every telephony provider (Twilio, Telnyx, Vonage, Plivo) sells the same primitives — numbers, webhooks, media streams — and every AI-telephony product is those primitives plus glue. When the glue runs on *your* machine, three things change:

• Your logic sits next to your data. The service answering calls can query your orders, your calendar, your CRM directly on the box — no third party in the middle of the payload.
• The approval loop is native. Outbound campaigns dial through the same draft-and-approve pattern as every other Pocket channel: the agent queues the calls, you approve the list and the script from your phone.
• You can see it. Gateway logs, agent timelines, and volume dashboards live beside each other. 'Why did this call fail?' has an answer on your machine.

Inbound SMS

The simplest flow, and the right first week: buy a number, point its webhook at a small service your agent writes on the machine, and let a bot answer. Keyword handling first (STOP, YES, package tracking), then free-text with intent classification, then drafts for anything money-adjacent. SMS's 160 characters make it the cheapest channel to get right and the most visible one to get wrong — start narrower than feels necessary.

Inbound voice

A phone call is a stream, and agents are not — so the architecture bridges the two:

caller dials your number
  → provider streams audio to your machine (Media Streams / WebSocket)
  → transcribe (streaming STT) → agent decides per turn
  → spoken reply (TTS back into the stream)
  → after hangup: recording + transcript + summary land in the timeline
  → follow-up SMS drafted for your approval if anything needs committing

The trick is scope: an inbound line that does *one job* — 'schedule an appointment', 'check order status', 'reset my booking' — works beautifully with today's models. A line that attempts general reception still hands off to humans mid-call, which is fine: the transfer is a tool call, the human gets the transcript so far, and the caller never hears silence.

Outbound, with a hand on the switch

Outbound is where reputations die — numbers get filtered, regulators get interested. The pattern that keeps it sane: the agent builds the campaign (who, what script, when), and nothing dials until you approve the list from your phone. Then the machine runs it at carrier-friendly rates, retries on failure, logs every outcome, and the dashboard shows delivered/failed/listened in real time next to the campaign conversation that spawned it. Consent records before volume, always; the machine makes compliance auditable, not optional.

The one-week version

• Day 1-2: machine up (yelves or ours), a Twilio/Telnyx account, one number, webhook service written by the agent and reviewed as a diff.
• Day 3-4: inbound SMS bot in draft-everything mode; find its edge.
• Day 5: one scoped inbound voice line with a clean hand-off.
• Day 6-7: a small approved outbound test — ten numbers you own — then read the logs and the dashboard before going further.

SMS and voice reward the same discipline as every other channel: small envelopes, visible decisions, approvals on your phone. The difference is the gateway — and on Pocket, the gateway is just another thing your agents built for you, running on a box you can point at. Start on the free tier and let the agent write the first webhook while you watch.