Imagine an agent named Juno. Juno works for a chain of physical therapy clinics, and her job is simple: confirm tomorrow's appointments by text, answer the replies, and rebook anyone who cancels.
This is a made-up story. Every failure in it is real, though, and every one of them shows up in production deployments in roughly this order. Here is Juno's first day with a phone number.
Hour 0: the launch
The engineer, call him Dev, provisions a number on a Tuesday morning. It works. A test text to his own phone arrives in under a second. He pushes the job queue live and goes to get coffee.
Juno starts sending. Four hundred reminders, each one friendly, each one personalized with a name and a time slot. It is a good message. Dev read it three times.
From the agent's point of view, nothing could be going better. The logs say sent over and over.
Hour 1: the log lies
Here is the first quiet problem. "Sent" means the message left your system. It does not mean it arrived, and it certainly does not mean anyone saw it.
Behind the scenes, the number is brand new. It has no history, no relationship with any of the 400 recipients, and a sudden burst of identical-shaped messages. To a carrier filter trained on human behavior, that pattern looks a lot like the start of a spam campaign.
Nobody tells Juno this. Carriers do not send you a note. The first sign of trouble is silence.
Hour 3: the spam flags
Around mid-morning, a few recipients do something understandable. A man named Marcus gets a text from an unknown number about an appointment he does not remember booking (his wife booked it). He taps the report-spam option.
One report is nothing. But the whitepaper behind this blog makes a point worth repeating: numbers used by agents tend to collect complaints at a far higher rate than human-operated numbers, because the volume is higher and the recipients have no relationship with the sender. A handful of complaints on a number with no reputation to absorb them is a lot.
By hour three, the number's standing has started to slide. Juno does not know. Her next batch goes out exactly like the last.
Hour 5: the first inbound reply
Then something lovely happens. A woman named Priya replies: "Thursday doesn't work, can I do Friday at 4?"
This is the moment the whole system is for. A real person, a real need, an agent that can solve it.
But now Juno needs three things at once:
If any of these is missing, Juno guesses. A guess on a medical appointment is not a cute bug.
This is why the whitepaper treats inbound as a first-class citizen and not an afterthought. Replies have to arrive normalized, with the thread attached, so the agent starts every turn knowing what came before.
Hour 9: the wrong number
Mid-afternoon. A reply comes in: "Who is this? I think you have the wrong number."
Of course it happened. Phone numbers get recycled. The contact list was a few years old. Somewhere, a person named Elena has a number that used to belong to a patient.
Now Juno faces a small ethical and practical puzzle. She has been texting a stranger about a medical appointment. The right behavior is clear:
1. Apologize briefly.
2. Stop. Do not text this number again.
3. Flag the record so no other workflow picks it up.
Step two is the one teams forget. If "stop contacting this person" lives in one agent's memory, the email agent and the voice agent will cheerfully contact Elena tomorrow. An opt-out has to be a fact about the contact that every channel can see, not a note one process wrote to itself. (More on that in a later post on consent.)
Hour 14: the carrier filter
Evening. Dev checks the dashboard and sees something odd. Delivery confirmations, which were arriving steadily, have thinned out. Juno is still sending, still logging sent, and fewer people are replying.
What happened is the failure the whitepaper calls reputation decay, with its close cousin, the volume throttle. The carrier has quietly started filtering the number. Some messages are delayed. Some are dropped. Some land with no warning and no error, because that is how carrier filtering works: it is silent by design, so spammers cannot learn the rules.
Juno has no way to feel any of this. For an agent, a dropped message and a delivered message look identical in the logs. She has been optimizing a conversation that half the audience cannot hear.
Dev makes the usual choice. He buys a second number.
This is the beginning of the treadmill. Number two starts with no reputation, burns in its own way, and now the replies are split across two inboxes. Priya texts back to number one on Thursday and gets a stranger's answer from number two. Juno has met her, and Juno has also never heard of her.
Hour 20: what a good morning looks like
Overnight, Juno rests. Dev does not. He pieces together what happened by reading logs and a stack of carrier documentation, none of which was written with him in mind.
In the morning he lists what he learned. Not one item on the list is about his agent's intelligence. Juno's messages were fine. The failures were all in the layer underneath:
| What broke | What it looks like | Whitepaper failure mode |
|---|---|---|
| New number, burst of messages | Spam labels, silent filtering | Reputation decay |
| 400 sends in a short window | Throttling, dropped messages | Volume throttle |
| Replies with no thread | Agent guesses who is writing | Cross-channel fragmentation |
| Recycled number | Texting a stranger about a medical visit | Compliance exposure |
| Texts from an unknown sender | Recipients cannot tell it is an agent | Identity ambiguity |
The five failure modes did not arrive one at a time. They arrived in a single afternoon.
Hour 24: the lesson
Here is the part worth taking away. Juno was not a bad agent. Dev was not a bad engineer. They did what teams do: they wired a number to a model and shipped.
What they were missing was everything around the message:
None of that is glamorous. All of it decides whether your agent has a good day or a quietly terrible one.
The first 24 hours of an agent's life with a phone number are not a test of the model. They are a test of the plumbing. This is the kind of thing Dial handles at the infrastructure layer, so the engineer can spend hour zero on Juno's behavior instead of hour fourteen on carrier forensics.