10DLC rules for AI-generated text messages

Carriers don't ask who wrote a text. They ask who sent it, what it is for, and whether that matches what was registered. An AI agent makes the last question harder, because a model writes a slightly different text every time and has no idea what you told the carriers.

Are AI-written texts A2P traffic?

Yes. The CTIA Messaging Principles separate consumer messaging, person to person, from everything else, and say that automation a business uses, in whole or in part, is not typical consumer operation (section 4.1.2). A text your agent writes and your system sends is a business message, whoever chose the words.

On a 10DLC number that means registration: a brand (your legal entity) and a campaign (the use case) with The Campaign Registry. TCR's overview says any business texting customers on 10DLC must register, including businesses that only send individual, non-marketing messages, and that all business messaging is A2P. Toll-free numbers go through toll-free verification instead, which asks for the same kind of information.

Neither process has an AI question. Both ask what you send.

What does the registration commit you to?

A campaign registration describes your traffic in a handful of fields that carriers review:

• the use case, such as account notifications, customer care or marketing
• a description of the program and of how people opt in
• sample messages
• the replies to HELP and STOP
• content attributes: whether texts carry links, phone numbers or age-gated content

In Unitpost these live in a messaging program (/sms/messaging-programs): message_type, sample_messages, help_message, stop_message, embedded_links, embedded_phones and age_gated, plus a recipe_id such as APPOINTMENT_REMINDERS that fills in carrier-ready copy. Before a 10DLC campaign goes to review, Unitpost checks what carriers most often send back: your brand name in the samples and replies, a contact in the HELP reply, a STOP reply that says messages end, links or phone numbers in samples when the campaign says it has none, and two to five sub-use cases on a mixed campaign.

The samples are a promise about future traffic. Unitpost's SMS Messaging Policy puts it plainly: what you send must look like the sample messages and use case you registered.

How do you keep an agent's texts matching the samples?

Don't ask the model to remember the registration. Make it hard to leave:

• Give the agent templates, not a blank body. It picks a template and fills the fields, and your code renders the text that goes to POST /sms.
• Start every text with your business name, as the samples do, and keep the opt-out line where the samples have it.
• Check the rendered text before sending: no links when the program says embedded_links: false, no phone numbers when it says embedded_phones: false, and a length cap so a reminder doesn't turn into a paragraph.
• Allow free text only where the registration covers it, such as answers inside a customer care conversation the person started, and keep those on topic too.

How to send appointment reminders by SMS from an AI agent walks through this for one use case.

How does an informational campaign drift into marketing?

One helpful sentence at a time. A reminder campaign is informational. Ask a model to make reminders friendlier and it may add "book your next visit this week and get 10% off". CTIA notes that adding a call to action such as a coupon code to an informational text may make it promotional. Now a text sent under a notification registration, to people who agreed to reminders, is marketing.

Know what Unitpost catches and what it doesn't:

• Every send has a type: transactional (the default) or marketing. Marketing needs express consent on record for the recipient and waits for the recipient's local quiet hours.
• A marketing campaign over a number registered for a non-marketing use case is refused with 422 use_case_mismatch. A marketing text over a sender pool set up for transactional or verification traffic fails with sender_use_case_mismatch.
• A single text sent through the API is not compared with the registration, and a promotional text sent as transactional skips the consent and quiet-hours checks. The API trusts the type you send.

So the last guard is yours. Don't let the agent choose type: fix it per tool. A reminder tool sends transactional with template text. Anything promotional goes through a marketing campaign, over a marketing registration, to contacts with marketing consent on record.

What about links and content filtering?

Links are where agent texts most often get filtered. Carriers filter public link shorteners because they hide the destination, and CTIA asks that a shortener use a web address dedicated to the sender and that a linked site identify its owner (section 5.3.2).

• Declare links in the registration (embedded_links and a sample link) before the agent sends any.
• Give the agent the exact URL. A model asked for "the booking link" will produce something plausible, and plausible isn't yours.
• Link to your own domain. Unitpost flags public shorteners such as bit.ly with a link_shortener warning. It doesn't block them, but carriers may.

Content is screened as well. Every outbound text is checked against carrier-restricted categories (sex, hate, alcohol, firearms and tobacco, plus neighbors such as gambling, cannabis and high-risk loans) before it is billed, and a blocked one is refused with 422 validation_error. A sample of unique content sent through the API may also be reviewed by an automated model. Neither check is a permission: a text the screen didn't catch can still break your registration.

What do you do when the agent's use case changes?

Register a new campaign. A 10DLC campaign's use case can't be edited after registration, so a different use case means a new campaign with its own samples. Common triggers with agents:

• reminders that should start carrying offers, which is marketing
• a support agent that starts sending order updates or one-time codes
• texts that will now carry links or phone numbers the old registration said they wouldn't

In Unitpost, create or duplicate a messaging program for the new use case. Writing a program never changes an existing registration, so the old campaign keeps working while the new one is reviewed. Then register it from the dashboard, or with a quote (POST /sms/quotes with product ten_dlc_campaign, a brand_id and the messaging_program_id) and its confirm. Confirming charges the workspace and needs the sms:purchase scope, which no key preset includes. Keep that scope off the agent's key and let a person approve the purchase.

TCR puts campaign review at one to four weeks. Until the new campaign is approved, the agent stays on the old use case. Consent may need to change too. CTIA treats an opt-in as belonging to the campaign it was collected for, and reminder consent isn't the express written consent that marketing needs.