Send SMS: the carrier delivers the bytes, you own the consent

Sending a text message looks like the easiest capability on this whole list. You sign up for Twilio, buy a number, post a recipient and a body to one endpoint, and a phone buzzes a second later. The send genuinely is that small. But "we can send a text" and "we can run an SMS product" are different claims, and the gap between them is not the API — it's a record you have to keep on your own side of it. Of all the rented capabilities in the foundation, this is the one where getting that record wrong has the sharpest consequences, because here the missing record is one the law can hold you to.

What the capability gives you

A carrier SMS API — Twilio, or one of its peers — does a job that is genuinely hard and genuinely not yours. It holds the relationships with the mobile carriers, routes a message across networks that each have their own rules, manages the pool of numbers and short codes you send from, registers your traffic so it isn't filtered as spam, and tells you whether a given message was delivered, queued, or rejected by the network. Rebuilding any of that would be a mistake — it's specialist telecom work, well-solved, and not the thing a stranger pays you for. This is the clearest kind of capability to rent: high stakes, owned by people who do only this, and not your product.

So the delivery is settled. The carrier takes the message and works to land it on the handset. The question, as with every rented capability, is what you keep on your side of it — and here the answer has teeth the others don't.

What stays yours: the consent ledger, the log, the rate state

Three things stay local, and a carrier is the wrong home for all three.

The first is the consent ledger — a record of who agreed to receive texts from you, when they agreed, and to what. Someone ticking a box to get appointment reminders has not agreed to receive marketing offers; those are different consents, and the difference is a fact about your product that you have to be able to prove. The other half of the same ledger is opt-out: the moment a recipient replies STOP, that has to be written down on your side, immediately, and honoured on every send after it. The carrier can tell you a message went out. It cannot tell you whether the person on the other end ever agreed to hear from you, or asked you to stop — those are facts about your relationship with that person, and they live with you.

The second is the delivery and reply log — a local row for every message you tried to send: who it went to, which kind of message, when it was queued, whether the carrier accepted it, and what came back. Inbound replies belong in the same place, because a reply is often the most important event in the whole exchange: it might be the word STOP. The carrier keeps its own version of some of this, reachable through its API on its schedule, shaped its way. The copy your product reads from — and the copy you reach for when a regulator or an annoyed recipient asks what happened — should be yours.

The third is the per-recipient rate state — how many messages a given number has been sent recently, so a bug or a bad loop can't text one person forty times in an hour. That's a property of your relationship with each recipient, not of the carrier's network, so it's yours to track and yours to cap.

What you leave with the provider is everything telecom: the carrier routing, the deliverability, the number pool, the per-network rules. Rent that and never rebuild it. Own the consent, the log, and the rate state, because those are the parts that say what your product did and whether it was allowed to.

What breaks when it's hacked in

The failure mode has one shape, and it is worse here than anywhere else on this list: the provider becomes the only record of who agreed to what.

If there is no local opt-out record, the sequence writes itself. A recipient replies STOP. That reply lands in the carrier's logs, or in an inbound webhook your code logged but didn't act on, and nothing in your own system marks that number as off-limits. The next scheduled batch runs. It texts them again. Now you have sent a message to someone who explicitly asked you to stop — and in many markets that can be a violation, with penalties that can run per message and that land on you, the sender, not the carrier. Where those rules apply, honouring opt-out is the sender's obligation, and you are the sender. A provider's dashboard showing the STOP reply is not a defence, because the obligation was to act on it, and your product didn't, because your product never knew.

Every quieter version of this is a consequence of the same root. Support can't answer "did I unsubscribe?" without spelunking the carrier's API. You can't prove a given recipient consented, because the proof lives in a checkout flow that wrote nothing durable. A retry loop with no per-recipient cap turns one stuck message into a barrage. None of it shows up in the demo, where you text your own phone once and it works. It shows up the first week you're sending to real people who have real opinions about being texted — and one of them replies STOP.

Where the shape already runs

This isn't theoretical for the foundation. CompanyGraph runs an email-service in production today that already has the exact discipline SMS needs: every message goes through a send queue, every attempt is logged with its outcome, retries happen on a bounded schedule rather than in a tight loop, and a suppressed address stays suppressed. An operator opens the admin Emails page and reads what was sent to whom, instead of guessing. The same background-job runner, the same logger, and the same admin would carry SMS — the send-once-and-write-down-what-happened machinery is the part that's lived and proven.

What is not yet wired is an SMS sender on top of it, and the honest reason to say so is that SMS adds the one thing email mostly doesn't: in many markets, a regulator who can fine you for getting consent wrong. The plumbing is the same; the stakes are higher. So the consent ledger isn't a nice-to-have bolted on after the carrier works — it's the first thing to build, because it's the part the law actually cares about. The capability note beside this one — why a delivered email still needs a record on your side — makes the gentler version of the same argument, and the two read as one rule with the volume turned up: rent the carrier, own the consent.

Where it shows up in a build idea

Anything that texts a person at scale rides on this — a reminder service, an alerting tool, a two-way survey. The consent ledger earns its keep hardest on the reply side, where an inbound message can be an answer you want or the word STOP you're legally bound to honour, and the same log has to catch both. That's the case worked all the way through in the SMS survey idea, where every reply has to be read before it's acted on — the build where owning the consent and reply state stops being a precaution and becomes the product.

---

SMS wired this way would ride on the foundation — the queue, the bounded retry, the suppression discipline, and the searchable log already run in CompanyGraph's email-service today. The next sensible step is to bring a build idea that texts real people and let the consent ledger be the first thing we design, not the last.