Build AI text agents that convert

Start with a customer outcome

Choose one job before you tune a prompt. An appointment agent might help a customer select an available time. An order-support agent might resolve a delivery question or hand it to the right person. A lead-qualification agent might arrange an explicitly requested follow-up.

Define what counts as completion in your application. A booking is complete when your scheduling system confirms it—not when the model says it booked something. A delivered text and a friendly reply are useful signals, but neither automatically means the customer reached the intended outcome.

Give the agent bounded tools for that job. Your server should validate recipients, permissions, availability and proposed actions before executing them. The model can propose the next step; it should not invent inventory, discounts or authority to contact somebody new.

Make permission and delivery the foundation

An AI-generated text is still a business message. Match your actual traffic to the appropriate sender registration or verification, record the recipient's opt-in context, and use a sending pattern that respects account and carrier limits.

For US local 10DLC traffic, prepare the relevant brand and campaign registration. Toll-free and short-code senders have different requirements. Do not treat every SMS number as interchangeable, or assume campaign approval removes the need for consent.

Keep submission and delivery separate in your application. An accepted send request is not proof that a phone received it. Follow the documented delivery events and investigate errors instead of repeatedly sending the same message. SMS delivery status is also not a read receipt.

• Choose between 10DLC, toll-free and short codes
• Registration, quiet hours and carrier limits
• Blocx API and webhook reference

Make the next reply easy

Write for a conversation, not a brochure. Identify the business, explain why you are texting and ask one useful question. Be clear about the assistant's role rather than pretending an automated conversation is a particular human employee.

After checking real availability, a booking assistant could say: "Hi Maya—Acme's booking assistant here. For the appointment you requested, we have Tuesday at 2 or Wednesday at 10. Which works better?" That gives the customer a concrete choice without making them parse a long explanation.

Use only the context needed for the task. A relevant appointment or order reference can help; unnecessary personal details can feel intrusive. Keep sensitive information out of SMS unless your use case, controls and applicable requirements support it.

Shorter messages are not just a style preference: encoding and length affect SMS segmentation and cost. Review the actual templates you will send, including generated text, instead of assuming every visible message is one billable segment.

Keep the conversation state intact

A reply may arrive seconds later or the next morning. Load the relevant thread, customer identity, current workflow stage and consent state before asking the model what to do. Do not make customers repeat information your application already has.

Verify signed inbound callbacks using the documented webhook contract, distinguish replies from delivery events, and make repeated events safe to process. Persist a confirmed action before scheduling another message, and cancel follow-ups that have become obsolete.

Blocx Contacts can hold customer and opt-in context alongside channel information and delivery learning. Your application still owns the conversation history, booking state and business permissions. A contact profile is not a replacement for that workflow state.

Treat inbound text as untrusted input. A customer message must not be able to change credentials, expose internal instructions or authorize a send to a different recipient. Keep those checks in application code, not just in a system prompt.

• How Blocx Contacts builds customer profiles
• Prevent duplicate SMS and MMS during retries

Measure delay across the whole workflow

A slow conversation can come from several places: an inbound event waiting in a queue, a model request, a business-system lookup, an outbound send or the delivery path. Measure those stages separately before deciding which part needs attention.

Record when your application receives a reply, starts processing, finishes tool calls, submits its response and receives the relevant delivery events. Where a documented event provides a delivery timestamp, distinguish it from the time your server received the callback.

Look at typical performance and slower cases, not just the fastest example. Separate active conversations from scheduled campaigns so a campaign queue does not unnecessarily delay a customer's current reply. Use the provider's documented limits and error handling rather than retrying aggressively.

There is no universal response-time threshold that guarantees a conversion. Measure the experience for your audience and workflow, and make uncertainty or a handoff clear instead of sending a confident but incorrect answer quickly.

Know when to stop or hand off

An opt-out must change the workflow, not just the wording of the next response. Honor STOP and the suppression rules appropriate to your traffic, prevent additional sends, and cancel queued follow-ups. A clear refusal should also end the relevant sales sequence rather than trigger more persuasion.

Set limits on repeated unanswered follow-ups and define when a human should take over. A disputed charge, an ambiguous request or an action outside the agent's permissions should follow an escalation path, not a fabricated resolution.

When handing off, preserve the conversation and explain the next step. Do not promise a human response time, refund or appointment unless your systems and team can actually support that promise.

Measure outcomes, not message volume

For an outbound campaign, measure unique conversations in a defined cohort and time window. Counting raw messages can make a chatty agent look successful even when it has not helped more people.

• Eligible conversations: customers your application is permitted to contact for this workflow.
• Delivered conversations: conversations with at least one confirmed SMS delivery.
• Replying conversations: conversations with a customer reply in the measurement window.
• Completed outcomes: conversations with an application-confirmed target action.
• Guardrails: opt-outs, complaints, failed deliveries, repeated contacts and human escalations.

A conversation-to-outcome rate is completed-outcome conversations divided by eligible conversations. A delivered-to-reply rate uses delivered conversations as its denominator instead. Keep those definitions explicit, attribute outcomes in your application and use an appropriate comparison or holdout when evaluating changes. More replies alone do not establish that an agent caused more completed bookings or better customer outcomes.

Build and test with Blocx's resources

Use the official JavaScript/TypeScript SDK and current API reference for the messaging integration. The AI-readable resources can help your coding assistant find the right documentation, but the request schemas and webhook contract remain the source of truth.

Before production, test an unanswered message, a late reply, an opt-out, duplicate callbacks, a failed delivery and a human handoff—not only the successful first send. Use the documented sandbox before moving to authorized, opted-in recipients with an approved sender.

Start with one useful conversation, make it safe and observable, and improve the step where customers actually get stuck. The most valuable agent is not the one that sends the most messages. It is the one that reliably helps customers finish the right task.

• Official SDK, download and setup example
• Blocx API reference
• AI-agent resources
• AI-readable overview
• Expanded AI-readable resources
• Give your AI agent a phone number
• Blocx test-phone sandbox guide

Brand identity

Blocx is the programmable messaging product from OtterBlocx, LLC, headquartered in Cheyenne, Wyoming, United States.

Channels

• Live today: SMS, MMS, RCS, Email, Telegram.
• Blocx also offers separate Voice services: VoIP, voicemail, call routing, 2FA via AI caller, and a voice dialer. These are not channels on the messaging or Verify API.

Plans

• Starter — self-serve with $25 in welcome credit for new accounts. Credit covers your first brand, campaign, phone numbers and messages. Paid Starter is $49/month credited toward usage. SMS $0.0065/segment, email $0.001/email (1 sending domain), 1 API key. No MMS, RCS, Telegram, SHAFT or restricted verticals.
• Scale — $1,000/month minimum platform spend (starts on day 31; no minimum for the first 30 days), on an annual contract. Every channel and route type at the published rate card — all rates listed on this site are Scale rates. Signup starts with a call. Required tier for SHAFT and other restricted verticals.
• Volume — custom volume-based pricing negotiated on your traffic profile. Contact sales.

Published rate card (+ carrier passthrough on SMS/MMS)

• SMS: 10DLC $0.0045, toll-free $0.0055, short code $0.007.
• MMS: 10DLC $0.0135, toll-free $0.016, short code $0.018.
• RCS: $0.0135/msg + one-time $1,000 setup fee.
• Email: $0.0002 per email, flat.
• Verify: $0.035 per successful verify, flat.
• Telegram: $0.0045/msg, flat.