Teams building agents that communicate with humans keep rediscovering the same lessons, in roughly the same order, at roughly the same expense. This is an attempt to write the lessons down so you can skip some of the expensive ones.
The principles draw on what the ACES whitepaper describes as the things agents actually need from a communication system, and on the five failure modes it says production teams hit: reputation decay, volume throttle, identity ambiguity, cross-channel fragmentation, and compliance exposure.
Ten principles, each with a short why.
1. Tell people they are talking to an agent
Say it at the start. Say who the agent represents. Say it again if asked.
Why: Trust is the product. Deception, even accidental, is a reputation problem that compounds, and disclosure rules are spreading, including in the EU. An agent that is honest from the first sentence loses very little and gains a lot.
2. Give your agent its own identity
Do not borrow a person's phone number, a founder's name in the From field, or the company's main email domain.
Why: Borrowed identity means borrowed risk. If the agent's behavior tanks a number's reputation, the damage lands on a human. The whitepaper's worst example is domain destruction: agent email through a primary domain, enough spam complaints, and the whole company's email stops delivering.
3. Isolate reputation
Keep each agent's sending identity separate, so one agent's mistakes cannot spread to another or to your human staff.
Why: Reputation systems were calibrated on human behavior, and agent patterns often look like abuse to them. Isolation turns a company-wide outage into a single contained problem.
4. Design for bursts, not averages
Plan for an agent that sends ten messages one minute and ten thousand the next, then nothing.
Why: Human infrastructure assumes steady volume and treats spikes as suspicious. If your design only works at the average, it will fail exactly when your agent is busiest, which is when failure costs the most.
5. Treat consent as a gate, not a footnote
Check consent before the message goes out, not in an audit afterward. Honor opt-outs on every channel at once.
Why: Rules like TCPA, CAN-SPAM, GDPR, and similar apply to agents without having been written for them. Fixing a violation after the fact is slow and costly. A gate at dispatch time is cheap. An opt-out that works on SMS but is ignored on email is a violation waiting to happen.
6. Keep one conversation, not one per channel
When a contact moves from a call to a text to an email, the agent should know it is the same person and the same story.
Why: Every channel switch that loses context is a cold start. The prospect who spoke to your agent on Tuesday and gets greeted like a stranger on Saturday does not think "a technical limitation." They think "this company is careless."
7. Choose channels by task, not by habit
Match the channel to urgency, length, and the recipient's context, and plan the escalation path in advance.
Why: The cheapest channel per message is often not the cheapest per completed outcome. Voice for urgency and nuance, text for short and timely, email for structure and records. The sequence matters more than any single choice.
8. Make failure loud
If a message may not have arrived, your system should know that, and your agent should not act as though it did.
Why: The nastiest failures in agent communication are silent. The log says "sent," the carrier quietly filtered it, and the agent proceeds on a false belief. Delivery status, bounces, and non-responses should be inputs to decisions, not afterthoughts.
9. Test the conversation, not just the code
Run scripted callers, adversarial testers, replays of past failures, and latency checks, in a sandbox, before real customers see anything.
Why: Conversational failures, like hanging up on a pause or answering a prompt injection, do not appear in unit tests. They appear in front of customers unless you find them first. And keep test traffic away from production identities, because tests can burn reputation as effectively as spam can.
10. Put the hard parts below your agent
Identity, consent enforcement, channel handling, session memory, and registration belong in infrastructure, not rewritten inside every agent.
Why: The whitepaper's closing argument for builders is that teams who do not solve these problems at the infrastructure layer will solve them again and again at the application layer, until a competitor who solved them at the right layer wins. Your engineering budget is finite. Spend it on what makes your agent distinctive.
How to use the list
Do not try to adopt all ten on Monday. Use it as an audit.
The pattern underneath
Look at the list and notice what the principles have in common: they all assume the agent is a first-class participant in communication, not a human in disguise. Identity, volume, trust, consent, and memory were designed around humans, and the principles are mostly about closing that gap.
The whitepaper calls this the wrong species problem: infrastructure built on the assumption that whoever is communicating is a person. You can patch around it at the application level, and many teams do. Or you can let infrastructure carry it. This is the layer Dial is built for, and the principles above are a reasonable checklist for judging any infrastructure you evaluate, ours included.
The takeaway
Be honest about what you are. Own your identity. Contain your blast radius. Respect consent by construction. Keep the thread. Pick the right channel. Notice failure. Test conversations. And do not rebuild the plumbing in every agent you ship.