You've built the agent. It works in testing. You ship to production.
Then, one by one, the same five failure modes appear. In roughly the same order. On roughly the same timeline.
Here's what they are and why they're not engineering mistakes.
1. Reputation decay
What it looks like: Connection rates drop gradually over 3–7 days. By day 10, the majority of outbound calls show "Spam Risk" on recipient caller ID. Email open rates collapse. A third of SMS messages are silently blocked.
Why it happens: Phone number and email domain reputation systems were calibrated on human behavior patterns. A human sales rep making 50 calls per day and a human marketing team sending 500 emails per day generate complaint rates within acceptable thresholds. An AI agent operating at 10× those rates generates complaint rates that spam detection algorithms classify as a malicious campaign.
The invisible part: Reputation decay is silent. No error codes. No alerts. Your agent logs "call made," but recipients never pick up because the call is pre-flagged at the network level. You only notice when someone compares actual outcomes to expected outcomes.
Why it's not fixable with code: The reputation systems are external. You cannot patch carrier spam detection or Gmail's ML models. You can only manage the underlying identity infrastructure to avoid triggering them.
2. Volume throttle
What it looks like: Your agent hits a hard wall. 200 SMS per day per number. 500 emails per hour per sending IP. The agent queues messages, delays accumulate, real-time workflows become batched workflows.
Why it happens: Every communication channel has rate limits set by regulators or platforms. These limits were set by humans imagining human-speed outreach. An A2P SMS long code's daily limit was set to prevent spam campaigns, not to constrain legitimate AI workflows.
The hidden compounding effect: Adding more numbers and domains doesn't solve the problem — it multiplies it. Now you have 10 phone numbers to manage, 10 domain reputations to monitor, 10 sets of A2P registrations to maintain. The operational burden grows linearly with your attempt to work around the throttle.
Why it's not fixable with code: The throttles are in the carrier and platform layers. The only solutions are either infrastructure-level (pre-registered high-throughput pools) or architectural (intelligent load distribution across identity pools managed by the infrastructure layer, not the agent code).
3. Identity ambiguity
What it looks like: Agents call from a number registered to the company. Recipients can't tell it's an agent. Some recipients feel deceived when they realize mid-call. Legal gets questions about AI disclosure requirements. Under the EU AI Act, you have an Article 52 compliance problem.
Why it happens: Agents borrow human identities — a company's phone number, a company's email domain. There's no mechanism in current communication infrastructure for an entity to declare itself as an agent rather than a human.
The legal exposure: Multiple jurisdictions are passing or considering AI disclosure requirements. An agent that passes itself off as a human caller — even if the intent was never deception — creates legal exposure that is growing, not shrinking.
Why it's not fixable with code: The disclosure problem requires identity infrastructure that signals "this is an agent" at the protocol level. A verbal disclosure in the agent's prompt is insufficient — it can be edited, forgotten, or not delivered. Protocol-level entity-type signaling is the only reliable solution.
4. Cross-channel fragmentation
What it looks like: A workflow that starts as a phone call needs to continue as an SMS, escalate to WhatsApp, and resolve with an email. Every channel switch is a cold start. The agent loses context, the contact is frustrated, the workflow breaks.
Why it happens: Each channel has a separate SDK, separate authentication, separate state management, separate identity. Building cross-channel context threading is custom engineering work — and most teams don't build it.
The user experience consequence: Every channel switch communicates to the contact that the system doesn't know who they are. This destroys the trust that makes AI agents valuable in the first place.
Why it's not fixable with code: You can build cross-channel session tracking, but it requires significant custom engineering and creates ongoing maintenance burden. The right fix is session management as a protocol feature — delivered with every inbound message, not reconstructed from multiple API calls.
5. Compliance exposure
What it looks like: The legal team asks questions. When was consent obtained for this call? Does the SMS include STOP keyword handling? Are opt-outs propagating across channels? Is the GDPR data handling for call recordings documented? Is there an AI disclosure in place?
Why it happens: TCPA, CAN-SPAM, GDPR, and the EU AI Act all apply simultaneously to agents communicating across channels. None of these frameworks were written with agents in mind. Compliance teams are making it up as they go.
The compounding problem: Getting each of these wrong is an individual risk. Getting all of them wrong simultaneously — as most teams do in early production — creates layered exposure. A TCPA violation discovered during a GDPR audit is not just two problems; it's a pattern that regulators treat as systemic noncompliance.
Why it's not fixable with code: Compliance logic belongs in the infrastructure layer, not the agent code. An agent that has to check consent in its own code before every message is both harder to build and less reliable than an infrastructure layer that enforces compliance before messages are dispatched.
The common thread
None of these failures are bugs. They're all the predictable consequence of running agentic workloads on infrastructure designed for human workloads.
The fix is not a better implementation of the same approach. It's a different layer — identity, rate, trust, session, and compliance infrastructure designed for agents rather than borrowed from the human-era communication stack.