At 2:47 in the morning, a phone lights up on a nightstand in Denver. It is a text from a scheduling assistant, cheerfully asking whether the recipient would like to confirm Thursday's appointment.
The assistant did nothing wrong, by its own lights. It had a task, a list, and a free afternoon. It was, from where it ran, mid-afternoon in Singapore. The recipient was asleep.
Agents ignore time unless someone tells them otherwise. They have no body clock, no sense of dinner, and no instinct that a call at 6 AM is different from one at noon. If your agent contacts people, politeness about time is something you have to build, and the right place to build it is not where most people put it.
*Note: this post is about engineering practice, not legal advice. Calling and texting rules vary by country, state, and message type, and you should check them with qualified counsel for your situation.*
Why the prompt is the wrong place
The first instinct is to write it into the instructions: "Never contact people before 9 AM or after 8 PM."
This feels like a rule. It is a suggestion.
A language model does not reliably know what time it is where the recipient lives. It may not know what time it is anywhere. It can be talked out of the instruction by a long conversation, a clever tool result, or a bug in the part of your code that fills in the date. And if you have many agents with many prompts, the rule exists in many slightly different wordings, which means it exists nowhere.
The same logic the whitepaper applies to consent applies here: a rule that matters should be enforced at the point of dispatch, in the infrastructure, before anything reaches a carrier. Not requested politely of the model, but checked every time, the same way, for every agent.
> A prompt that says "respect quiet hours" is a wish. A send queue that holds the message until morning is a policy.
What quiet hours as infrastructure looks like
Think of it as a gate between "agent decided to send" and "message leaves."
on send(message):
tz = resolve_local_timezone(recipient)
if inside_quiet_hours(now, tz, message.type):
schedule(message, next_allowed_time(tz))
return "scheduled"
deliver(message)Illustrative pseudocode, not a real API.
Three design points matter.
Hold, do not drop. The right default for a message sent at the wrong hour is to delay it to the next acceptable window. Silently discarding it means the agent believes it told someone something it did not.
Differ by message type. A promotional text and a flight-delay alert are not the same. A fraud warning or a code the user just requested may deserve to go out immediately; a reminder or a sales follow-up can wait. Your policy should distinguish them explicitly, and the distinction should not be left to the model's mood.
Expire the stale. A reminder held overnight for a 9 AM appointment is useless at 9:05. Messages queued for later need an expiry, or you will deliver yesterday's news politely.
The whitepaper's routing example makes a related point: at 23:45 in the recipient's time zone, the sensible choice is to not call and to send a text instead, and the channel decision should be made by data, not left as a developer concern.
Resolving the recipient's local time
This is where it gets harder than it sounds.
Area code is not a time zone. It is tempting to map +1 415 to Pacific time and be done. But people keep their phone numbers when they move. Someone with a Los Angeles number may live in New York. Mobile numbers have been portable for years, and some area codes cover territory that spans more than one time zone. An area code tells you where a number was first assigned, not where its owner is sleeping.
Country codes are better, but still coarse. Some countries span many time zones.
Better signals, roughly in order of reliability:
And when you are unsure, the polite default is to be conservative: apply the stricter window, or choose the channel that is least intrusive. A message that arrives a few hours late costs you a little. A call that wakes someone costs you their trust and possibly a complaint.
Two smaller traps worth naming: daylight saving transitions, which shift windows twice a year, and the difference between the time at the sender's server and the time at the recipient's phone. Store and compute in proper time zone identifiers, not fixed offsets.
Politeness has more dimensions than the clock
Quiet hours are the easy version. Once you have a dispatch gate, it is the natural place for the rest:
An agent does not feel the social cost of any of these. That is exactly why the cost has to be encoded for it.
What to check before you ship
The takeaway
An agent that never sleeps must be built to remember that its recipients do. Politeness at scale is not a tone of voice; it is a property of the send path.
This is the sort of policy Dial aims to keep at the infrastructure layer, so every agent inherits good manners instead of reinventing them.