"The telephone was invented in 1876 for humans to talk to humans. Email was designed in 1971 for humans to write to humans. WhatsApp launched in 2009 so humans could message humans. In 2025, we crossed a threshold: AI agents now outnumber the humans who created them. Nobody updated the infrastructure."
Part I: The Business Case
Chapter 1: The 100-to-1 World
There is a number that Jensen Huang, Sam Altman, and Marc Andreessen have all arrived at independently: one human knowledge worker, one hundred AI agents. Not one agent per person. Not ten. One hundred.
Most people hear this and think about compute. They should be thinking about communication.
There are approximately 1.3 billion knowledge workers globally. At 100 agents per worker, that is 130 billion agents. This is not science fiction — early enterprise deployments already show teams of 10 humans running hundreds of concurrent agents across sales, engineering, operations, and customer success. The math is starting now.
Now ask a different question: how much do agents communicate?
A human knowledge worker sends about 40 emails per day, makes 10 phone calls, exchanges 200 messages across channels. Call it 250 communication events per day. An AI agent has none of the constraints that limit a human — no attention fatigue, no timezone, no social friction, no calendar holding it back. A single agent orchestrating a multi-step workflow might initiate or receive hundreds of communication touchpoints in an hour.
Conservative estimates: 50–100× the human baseline per agent.
Run the full math:
130 billion agents × 50 communication events per day = 6.5 trillion agent communications per day.
>
All human communication on Earth — every SMS, email, WhatsApp message, and phone call — totals approximately 437 billion events per day.
>
Agents, at 1:100, will generate ~15× all human communication that exists today.
╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 1: THE SCALE MISMATCH ║
║ Projected Agent Communication Volume vs. Human Infrastructure ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ TODAY — Human Communication Infrastructure ║
║ ────────────────────────────────────────── ║
║ SMS (global) ████ ~5B/day ║
║ Email (global) ████████████ ~330B/day ║
║ WhatsApp ████████████████████ ~100B/day ║
║ Phone calls ██ ~2B/day ║
║ ║
║ TOTAL HUMAN COMMUNICATION: ~437 billion/day ║
║ ║
║ NEAR FUTURE — Projected Agent Demand (1:100 ratio) ║
║ ─────────────────────────────────────────────────── ║
║ 130B agents × 50 comm events/day = ║
║ ║
║ ████████████████████████████████████████████ 6.5 TRILLION/day ║
║ ████████████████████████████████████████████ ║
║ ║
║ That is ~15× all human communication combined. ║
║ The infrastructure does not exist. It has never been built. ║
╚══════════════════════════════════════════════════════════════════════════════╝This is not a scalability problem to be optimized. It is a category error. The existing infrastructure was not designed for this load because it was not designed for these users. You cannot scale your way through a category mismatch — any more than you could have scaled the fax machine to become the internet.
Chapter 2: We Built Everything for Humans
Here is the core problem, stated plainly: every assumption in our global communication infrastructure assumes the entity communicating is a human being. Not an approximation of one. Not a human-supervised process. A biological person with a SIM card, a timezone, a working-hours pattern, and a spam threshold.
This assumption is woven into the protocol, the rate limit, the identity model, and the regulation. To understand why agents are failing at communication, you have to see how thoroughly this assumption was baked in.
The Phone Number
The North American Numbering Plan allocates approximately 8 billion possible phone numbers — comfortable headroom for 1.3 billion humans. A single mid-size enterprise of 10,000 employees deploying 100 agents per employee needs 1 million agent identities from that same pool. The Fortune 500 completing its first full deployment would require hundreds of millions — a serious strain on a system with 8 billion total numbers.
But the number problem is only the surface. The deeper issue is what a phone number represents: physical possession. You have a number because you have a SIM card. You have a SIM card because you have a device. You have a device because you are a person in a location. An AI agent has none of these properties. It is a process running in a data center. It does not possess anything.
Email Address
The email address ([email protected]) is a human naming convention. Email authentication — SPF, DKIM, DMARC — was designed to verify that a message comes from the domain it claims. But it says nothing about whether a human or an agent is sending it, whether the sending pattern is legitimate, or whether the volume is appropriate.
Gmail's spam filters, Outlook's Defender, and every inbox provider's ML system was trained on human behavior: 40–200 emails per person per day, patterns that follow working hours, relationship histories that build over time. An agent sending 10,000 emails per hour does not look like a busy human. It looks exactly like a botnet — because the model has never seen a legitimate agent.
SMS
Standardized under GSM 03.40, assuming a human sender and a human receiver. The A2P (Application-to-Person) tier was a retrofit — added after the fact to accommodate businesses, not agents. Carriers today enforce A2P SMS rate limits of 200 messages per day per long code and 100,000 per day per short code. These limits were set by humans imagining human-speed sales outreach. An agent pipeline doing real-time notification, coordination, and verification can exceed the human daily limit in the first four minutes of a busy workflow.
WhatsApp and iMessage
Explicitly built around human identity — phone numbers tied to SIM cards, biometric authentication, contact books maintained by people. WhatsApp's Business API introduced programmatic access, but its policies require human oversight, manual template approval, and prohibit certain automated patterns. iMessage has no business API at all.
These platforms were designed to resist automation, because automation by humans meant spam. They succeeded. Now they resist legitimate agent communication along with the spam.
Twilio, SendGrid, Bandwidth — The "API Layer"
These companies are often cited as the solution. They are not. Twilio is an excellent abstraction over carrier infrastructure. SendGrid is a well-engineered wrapper around email delivery. They gave developers access to what the carriers and inbox providers offered.
But what was offered was designed for human communication. Every rate limit, reputation model, trust signal, and identity primitive in these platforms presupposes a human on at least one end of every communication. A faster API on top of a human-designed foundation does not change the foundation.
The wrong species problem: Our entire global communication stack was built with one unexamined assumption — that the entities communicating are human. That assumption is now wrong. And it is wrong in ways that compound at every layer simultaneously.
╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 2: TODAY'S FRAGMENTED AGENT COMMUNICATION STACK ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ [ Your AI Agent ] ║
║ │ ║
║ ┌───────────┬───────────┬───┴───────┬──────────────┬──────────────┐ ║
║ ▼ ▼ ▼ ▼ ▼ ▼ ║
║ ┌──────┐ ┌─────────┐ ┌────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ ║
║ │Voice │ │ SMS │ │ Email │ │WhatsApp │ │ iMessage │ │ Telegram │ ║
║ └──────┘ └─────────┘ └────────┘ └──────────┘ └──────────┘ └────────────┘ ║
║ │ │ │ │ │ │ ║
║ Twilio Bandwidth SendGrid Meta Biz Apple Biz Telegram ║
║ Vonage Twilio SMS Postmark API Register Bot API ║
║ WebRTC 10DLC Reg SES (approved?) (invite (separate) ║
║ STT/TTS (4-6 wks) DKIM/SPF only) ║
║ │ │ │ │ │ │ ║
║ Separate Separate Separate Separate Separate Separate ║
║ auth rate limits compliance approval compliance auth ║
║ billing consent warm-up process process billing ║
║ identity tracking (4 wks) templates ║
║ ║
║ ───────────────────────────────────────────────────────────────────────── ║
║ Result: 5+ vendors │ 5+ billing relationships │ 5+ compliance ║
║ 0 shared session state │ 0 unified identity │ weeks to deploy ║
╚══════════════════════════════════════════════════════════════════════════════╝Chapter 3: The Five Failure Modes
The engineers building agentic systems today are not hitting one wall. They are hitting five — each one a different expression of the same underlying category error. Understanding them is the prerequisite for understanding why the solution must be a new protocol, not a better workaround.
Every team building AI communication agents runs into these five failure modes, in roughly this order, on roughly this timeline.
1. Reputation decay. A phone number used by an AI agent for outbound calls accumulates spam complaints at 10–100× the rate of a human-operated number. Carriers and spam databases update within hours. A clean number on Monday is flagged by Wednesday. A domain used by an agent for high-volume email outreach sees its deliverability scores drop within days. The failure is silent — the agent logs "message sent" while recipients see nothing, or see "Spam Risk" on caller ID.
2. Volume throttle. A sales agent designed to follow up with 500 leads per day hits carrier SMS limits within the first hour of operation. An email agent processing 10,000 follow-ups exceeds Gmail's daily sending caps immediately. Adding more phone numbers and domains delays the problem — it does not solve it. Each new asset starts with no reputation, burns fast, and compounds the operational burden. You are running a number farm, not a communication system.
3. Identity ambiguity. Agents borrow human identities: a person's phone number, a company's email domain, a human's name in the "From" field. Recipients have no way to know they are communicating with an agent. This creates legal exposure under the EU AI Act Article 52 (mandatory AI disclosure for real-time conversational AI) and emerging US federal legislation — and it destroys the trust signal that makes communication valuable. Deception, even unintentional, is a reputation problem that compounds.
4. Cross-channel fragmentation. A workflow that starts as a phone call needs to continue as an SMS, escalate to WhatsApp, and resolve with an email confirmation. Each channel transition is a custom integration: different SDKs, different authentication, different state management, different identity. The agent loses conversational context at every boundary. From the recipient's perspective, every touchpoint is a cold start. The agent that called last Tuesday remembers nothing when the lead texts back on Saturday.
5. Compliance exposure. TCPA, CAN-SPAM, GDPR, and the EU AI Act apply simultaneously to agents communicating across channels. None of these frameworks were written with agents in mind. Compliance teams are writing policy for an entity type the regulations have never imagined. Violations are accumulating, mostly invisibly, in production deployments running right now.
These five failure modes share a common root: agents are running on infrastructure designed for humans, and the infrastructure is making the assumptions that human infrastructure makes — that the sender operates at human speed, with human volume, with human-possessed identity, in the context of human regulatory frameworks. Agents violate every one of these assumptions simultaneously.
The solution to a category error is not more of the same category. It is a new category.
╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 3: THE REGULATORY WALL ║
║ Time to Communicate vs. Time to Get Permission to Communicate ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ Time to deploy an AI agent: ██ (seconds) ║
║ ║
║ Time to register A2P 10DLC (SMS): ████████████████████████████ (4-6 wks) ║
║ Time for campaign approval (SMS): ██████████████████████ (2-5 wks) ║
║ Email domain warm-up to send scale: ████████████████ (4-6 wks) ║
║ WhatsApp Business API approval: ████████████████████ (2-4 wks) ║
║ Apple Business Chat access: ████████████████████████████████████░░ ║
║ (months — invite only) ║
║ ║
║ ───────────────────────────────────────────────────────────────────────── ║
║ DURING THIS WAIT: ║
║ → Agent cannot communicate. But it's deployed, running, and billing you. ║
║ → Competitors who shipped 3 weeks earlier own the market position. ║
║ → Every workaround (using personal numbers, shared pools) is a ║
║ compliance liability and a reputation timebomb. ║
║ ║
║ Agents have no time to wait. The market has no time for agents to wait. ║
╚══════════════════════════════════════════════════════════════════════════════╝╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 4: BEFORE vs. AFTER — Giving Your AI Agent a Phone Number ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ BEFORE: The Human Way (Twilio + Duct Tape) ║
║ ────────────────────────────────────────── ║
║ ║
║ Day 0 ► Sign up for Twilio. Business KYC review. ║
║ ⏱ 1–2 days ║
║ ║
║ Day 3 ► Purchase a phone number ($1–2/month). ║
║ ⚠ No agent identity attached — it's a human number ║
║ ║
║ Week 2 ► Register A2P 10DLC brand for SMS outbound. ║
║ $4/month brand fee. Carrier review. ║
║ ⏱ 1–3 weeks ║
║ ║
║ Week 5 ► Campaign approval (maybe). 1-in-3 rejected first pass. ║
║ ⏱ 1–5 more weeks if rejected ║
║ ║
║ Week 5+ ► Build WebSocket server for audio streaming (1 week) ║
║ Integrate STT: Google / Deepgram / AWS (3 days) ║
║ Integrate TTS: ElevenLabs / Polly (3 days) ║
║ Write call state machine (2 weeks) ║
║ Build separate SMS handler (different API) (1 week) ║
║ Implement TCPA consent tracking (manual) (1 week) ║
║ Set up number reputation monitoring (ongoing) ║
║ ║
║ ───────────────────────────────────────────────────────────────────────── ║
║ RESULT: 6–10 weeks │ 3–5 vendors │ ~1,000+ lines of infra code ║
║ Agent identity = borrowed human number = reputation timebomb ║
║ Zero session state. Zero cross-channel continuity. ║
║ One spam complaint cascade away from total communication loss. ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ AFTER: The Dial Way (ACES Native) ║
║ ──────────────────────────────── ║
║ ║
║ T + 0s ► pip install dial-sdk ║
║ ║
║ T + 3s ► acn = client.acn.provision( ║
║ capabilities=["voice", "sms", "email", "whatsapp"] ║
║ ) ║
║ → ACN provisioned: acn://getdial.ai/yourco/agent-001 ║
║ → Phone number purchased and live immediately ║
║ → Compliance policies applied automatically ║
║ ║
║ T + 5s ► Phone number purchased and live ║
║ → Agent makes its first call ✓ ║
║ → Agent sends its first SMS ✓ ║
║ → Agent receives its first SMS ✓ ║
║ All from the same identity. Same session. Same context. ║
║ ║
║ T + 10s ► Webhook handler live (normalized, all channels) ║
║ → Session state managed by protocol ║
║ → TCPA, CAN-SPAM, GDPR enforced at infrastructure layer ║
║ → Agent identity cryptographically verified ║
║ ║
║ ───────────────────────────────────────────────────────────────────────── ║
║ RESULT: 10 seconds │ 1 vendor │ ~10 lines of agent code ║
║ Agent identity = cryptographically verified ACN ║
║ Full cross-channel session continuity. Compliance by default. ║
╚══════════════════════════════════════════════════════════════════════════════╝Chapter 4: Beyond Phone — The Full Communication Stack Agents Need
Solving the phone number problem for agents is not enough. "AI agents with phone numbers" — the framing used by every existing player in this space — is the equivalent of solving the internet problem by giving every computer a better fax machine. It addresses one symptom while missing the underlying condition.
The problem is not that agents lack phone numbers. The problem is that agents lack a communication stack: a coherent, unified, identity-anchored infrastructure for communicating across every channel that matters, at the volume agents actually need, with the trust properties that make communication legitimate.
A complete agent communication stack must cover:
Human-outward channels — how agents reach the humans they serve:
- Voice (PSTN) — the highest-trust, highest-attention channel. Appointment reminders, urgent escalations, sales calls, customer support.
- SMS — ubiquitous, asynchronous, high open-rate. Follow-ups, notifications, two-factor verification.
- Email — the richest asynchronous channel. Contracts, detailed summaries, formal communications, structured data.
- WhatsApp — 2 billion users, dominant in international markets, supports rich media and structured messages.
- iMessage — Apple ecosystem, highest-value consumer segment in North America.
- Telegram / Signal — privacy-forward, dominant in specific verticals (crypto, finance, international).
Enterprise-inward channels — how agents reach humans inside organizations:
- Slack — the default human attention surface in tech companies. Agent notifications, escalations, approval requests.
- Microsoft Teams — enterprise-dominant, especially in financial services, healthcare, government.
Agent-to-agent channels — how agents coordinate with each other:
This is the channel nobody is building. Agent orchestration today happens through API calls and shared state stores — fragile, unverifiable, and invisible to the humans who should be overseeing it. ACES defines a communication primitive for agent-to-agent interaction that is auditable, authenticated, and session-persistent. It is the missing layer in every multi-agent system deployed today.
╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 5: THE FULL AGENT COMMUNICATION CHANNEL MAP ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ ┌─────────────────────────┐ ║
║ │ Your AI Agent │ ║
║ │ (acn://getdial.ai/co/007) │ ║
║ └───────────┬─────────────┘ ║
║ │ ║
║ ┌───────────▼─────────────┐ ║
║ │ DIAL / ACES ENGINE │ ║
║ │ Channel Abstraction │ ║
║ │ Identity │ Sessions │ ║
║ │ Consent │ Trust │ ║
║ └───────────┬─────────────┘ ║
║ │ ║
║ ┌──────────┬────────┬───────┼───────┬──────────┬──────────┐ ║
║ │ │ │ │ │ │ │ ║
║ ┌───▼──┐ ┌───▼──┐ ┌──▼──┐ ┌──▼──┐ ┌──▼──┐ ┌───▼──┐ ┌───▼──┐ ║
║ │Voice │ │ SMS │ │Email│ │ WA │ │iMsg │ │Slack │ │A2A │ ║
║ │PSTN │ │ A2P │ │SMTP │ │Meta │ │Apple│ │Teams │ │Agent │ ║
║ └──────┘ └──────┘ └─────┘ └─────┘ └─────┘ └──────┘ └──────┘ ║
║ ║
║ HUMAN-OUTWARD ◄──────────────────────► ENTERPRISE A2A ║
║ (Reach anyone) (Internal) (Agents) ║
╚══════════════════════════════════════════════════════════════════════════════╝Each of these channels presents the same underlying problem at different coordinates: the identity, rate, and trust assumptions embedded in each channel assume human usage. ACES solves this once, at the protocol layer, for every channel simultaneously.
Chapter 5: The Market
The CPaaS (Communications Platform as a Service) market was valued at approximately $18 billion in 2024, with Twilio, Bandwidth, Vonage, and similar players serving developer needs. This is the "human communication as a service" market — built over 15 years on the assumption that developers needed easier access to carrier infrastructure designed for humans.
The "agent communication as a service" market does not exist yet. But the historical pattern for how it will develop is legible.
Consider what happened in three prior infrastructure moments:
- TCP/IP did not optimize the telephone network. It replaced its assumptions entirely — circuit-switched became packet-switched, because the new use case (data, not voice) required different primitives. The companies that defined TCP/IP earned the right to participate in every application built on top of it.
- Stripe did not make it easier to use the existing payment infrastructure. It defined an abstraction layer —
charge.create()— that hid the complexity of acquiring relationships, fraud networks, and bank APIs behind a single interface. Every dollar processed through Stripe participates in Stripe's infrastructure revenue. - DNS did not improve the HOSTS file. It defined a distributed, resolvable naming layer that any node could query and any registrar could participate in. Once DNS became the standard, the naming layer earned compounding network effects from every domain registered anywhere.
The company that defines agent communication infrastructure earns the same position: participation in every agent communication event that runs on its protocol. Not just the events it processes directly — every event, because the identity resolution, the trust verification, and the session management all flow through the protocol layer.
If the 1:100 agent ratio materializes, even at a 90% volume discount for agent-scale traffic, the total addressable market exceeds $200 billion annually at meaningful deployment scale.
This is not a feature market. It is infrastructure. The company that establishes the protocol — the identity system, the channel abstraction layer, the session management standard, the trust framework — earns the right to participate in every agent communication event that runs on top of it. The question is not whether an agent channel exchange standard layer will exist. It is who defines it.
Part II: The Technical Architecture
Chapter 6: What Agents Actually Need
Before proposing a protocol, precision is required. Agents need different things from a communication system than humans do — not more of what humans have, but fundamentally different primitives.
Programmatic identity, not possession-based identity. Human identity in telephony and email is rooted in physical possession: you own a SIM, you have a corporate email address, you carry a device. Agents do not have hardware. They need identity rooted in cryptographic proof — persistent across deployments, portable across infrastructure providers, verifiable by counterparties without any physical object changing hands.
Volume elasticity. An agent may need to send 10 messages one minute and 10,000 the next, then drop to zero, then spike again. Human infrastructure assumes relatively stable volume and penalizes sudden spikes as suspicious behavior. An agent communication system must scale horizontally without per-identity reputation effects accumulating.
Channel-agnostic addressing. An agent should be addressable by a single identifier regardless of whether the communication arrives via voice, SMS, email, or WhatsApp. An agent should not manage separate identities across channels any more than a human manages separate phone numbers for calls versus texts.
Persistent session state. A conversation between an agent and a human may span days, involve multiple channels, and include multiple agent instances. The session must maintain context independent of which agent instance handles each turn and which channel it arrives on. Today, every channel switch is a cold start. It should not be.
Machine-readable trust signals. When an agent initiates a communication, the receiving party — whether human or another agent — needs to know: is this an agent? What is its identity? What has it been authorized to do? This cannot be left to ad-hoc convention; it needs to be a protocol-level primitive.
Compliance automation. TCPA consent, CAN-SPAM opt-out, GDPR data handling, EU AI Act disclosure requirements — these should be protocol features, not legal team fire drills. The right design makes compliance the default.
Speed. Agents operate in milliseconds. Waiting weeks for A2P registration is not an inconvenience — it is a categorical incompatibility with how agents work.
Chapter 7: The Agent Communication Number (ACN)
The phone number is the foundational identity primitive of human voice and SMS communication. The email address is the foundational identity primitive of asynchronous human messaging. Their agent-era equivalent is the Agent Communication Number (ACN).
An ACN is a persistent, cryptographically rooted identifier for an AI agent or class of agents — the difference between a SIM card and a key pair:
acn://<registry>/<namespace>/<agent-id>
Example:
acn://getdial.ai/genway/sales-agent-7f3a
acn://getdial.ai/genway/support-agent-prod
acn://getdial.ai/genway/orchestrator-v2╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 6: PHONE NUMBER vs. ACN — The Identity Gap ║
╠═══════════════════════════════════════╦══════════════════════════════════════╣
║ PHONE NUMBER (+14155551234) ║ AGENT COMMUNICATION NUMBER (ACN) ║
╠═══════════════════════════════════════╬══════════════════════════════════════╣
║ Assigned by carrier ║ Provisioned cryptographically ║
║ Tied to SIM card / physical device ║ Tied to key pair / agent runtime ║
║ NANP: ~8B possible numbers ║ Namespace: practically unbounded ║
║ Reputation: global, shared risk ║ Reputation: isolated per ACN ║
║ Single channel (voice + SMS only) ║ Multi-channel (all channels) ║
║ No capability metadata ║ Full capability manifest ║
║ No entity type signal ║ entity_type: agent (machine-readable)║
║ No consent record ║ Consent policy embedded ║
║ Rate-limited at human pace ║ Rate-configured at agent scale ║
║ Carrier-level identity only ║ Application-layer cryptographic ID ║
╚═══════════════════════════════════════╩══════════════════════════════════════╝The ACN record is stored in the Dial registry — designed as a federated open standard, analogous to DNS — and contains:
{
"acn": "acn://getdial.ai/genway/sales-agent-7f3a",
"version": "1.0",
"entity_type": "agent",
"owner": "did:web:genway.ai",
"created": "2026-05-25T00:00:00Z",
"capabilities": ["voice_inbound", "voice_outbound", "sms", "email", "whatsapp"],
"channels": {
"phone": "+14155551234",
"sms": "+14155551234",
"email": "[email protected]",
"whatsapp": "+14155551234"
},
"public_key": "ed25519:abc123...",
"policy": {
"disclosure": "required",
"consent_model": "tcpa_express_written",
"can_spam": "compliant",
"recording": "notify_before",
"gdpr_basis": "legitimate_interest"
},
"rate_config": {
"voice_calls_per_hour": 500,
"sms_per_day": 50000,
"email_per_hour": 2000
}
}The public_key enables cryptographic verification: any message sent by this agent is signed, and any counterparty can verify the signature against the registry, establishing proof of identity without relying on carrier-level attestation alone.
The ACN is to agents what DNS is to the internet: a named, resolvable, federated identity standard that any party can query, any agent can hold, and any protocol can verify. Once it is the standard, everything else is built on top of it.
Chapter 8: The Channel Abstraction Layer
The central technical contribution of ACES is the Channel Abstraction Layer (CAL) — a normalized protocol interface between agents and the fragmented landscape of carrier and messaging platform APIs.
The design goal, stated simply: an agent communicates through a single interface, regardless of whether the underlying channel is a phone call, an SMS, an email, a WhatsApp message, or an iMessage. Channel selection, encoding, platform compliance, and delivery confirmation are handled by the CAL — not the agent.
8.1 The ACES Message Format
All communications — inbound and outbound, across all channels — are represented as ACES Messages:
{
"acp_version": "1.0",
"message_id": "msg_01h9x7y3z4",
"session_id": "sess_genway_sales_7f3a_982",
"timestamp": "2026-05-25T14:32:11Z",
"from": {
"acn": "acn://getdial.ai/genway/sales-agent-7f3a",
"entity_type": "agent",
"display_name": "Genway Sales Assistant",
"signature": "ed25519:..."
},
"to": {
"address": "+14155559876",
"address_type": "e164",
"preferred_channel": "auto",
"fallback_channels": ["sms", "email", "whatsapp"]
},
"content": {
"type": "voice | text | html | structured",
"body": "Hi, following up on your trial signup...",
"media": [],
"tts_hint": "professional",
"language": "en-US"
},
"channel_meta": {
"resolved_channel": "phone",
"delivery_status": "delivered"
},
"context": {
"thread_id": "thread_lead_982",
"turn_index": 3,
"prior_turns_summary": "Lead confirmed interest in enterprise plan. Asked about pricing."
},
"policy": {
"disclosure_sent": true,
"consent_verified": true,
"recording_disclosed": false,
"tcpa_consent_timestamp": "2026-05-25T10:14:22Z",
"can_spam_compliant": true,
"unsubscribe_link_injected": false
}
}This single format handles voice calls, SMS, email, WhatsApp, and every future channel. The agent never encodes differently for different channels. The CAL translates.
╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 7: THE CHANNEL ABSTRACTION LAYER — INBOUND NORMALIZATION ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ INCOMING COMMUNICATIONS (raw, channel-specific): ║
║ ║
║ ┌─────────────────┐ PSTN call, WebRTC audio stream, DTMF tones ║
║ │ Phone Call ├──────────────────────────┐ ║
║ └─────────────────┘ │ ║
║ ┌─────────────────┐ GSM 03.40 PDU, carrier │ ║
║ │ SMS ├────── encoding, segments ─┤ ║
║ └─────────────────┘ │ ║
║ ┌─────────────────┐ MIME multipart, SMTP │ ┌────────────────────┐ ║
║ │ Email ├─── headers, HTML body ────┼─►│ CHANNEL │ ║
║ └─────────────────┘ │ │ ABSTRACTION │ ║
║ ┌─────────────────┐ Meta webhook, templates │ │ LAYER │ ║
║ │ WhatsApp ├────── JSON, media refs ───┤ │ │ ║
║ └─────────────────┘ │ │ • Normalize │ ║
║ ┌─────────────────┐ Apple Business Chat, │ │ • Transcribe │ ║
║ │ iMessage ├─── proprietary format ───┘ │ • Thread detect │ ║
║ └─────────────────┘ │ • Consent check │ ║
║ │ • Sign + verify │ ║
║ └────────┬───────────┘ ║
║ │ ║
║ ▼ ║
║ ┌─────────────────────────┐ ║
║ │ ACES Message (unified) │ ║
║ │ → agent webhook │ ║
║ │ → MCP tool call │ ║
║ │ → streaming connection │ ║
║ └─────────────────────────┘ ║
╚══════════════════════════════════════════════════════════════════════════════╝8.2 Intelligent Outbound Routing
When an agent sends an ACES message, the routing engine selects the optimal channel:
"to": {
"address": "+14155559876",
"preferred_channel": "auto",
"routing_hints": {
"urgency": "high",
"message_length": 340,
"contains_media": false,
"prior_channel": "sms",
"recipient_tz": "America/New_York",
"local_time": "23:45"
}
}At 23:45 in the recipient's timezone: don't call, send SMS. Message length 340 chars: segment across two SMS or switch to email. Urgency high: SMS, not email. The agent's intent is preserved. The channel decision is data-driven, not a developer concern.
8.3 Channel Translation Table
| Channel | Key complexities | CAL handling |
|---|---|---|
| Voice (PSTN) | Audio streaming, TTS synthesis, DTMF input, call state machine | Agent sends text; CAL speaks it. DTMF captured as structured input. |
| SMS (A2P) | 160-char segmentation, STOP/HELP keywords, 10DLC registration | CAL manages registration, segmentation, opt-out interception. |
| MIME encoding, HTML rendering, SPF/DKIM signing, bounce management | CAL manages sending infrastructure, domain reputation, deliverability. | |
| Template approval, 24hr session windows, media handling | Pre-approved template library; CAL enforces platform policies. | |
| iMessage | Apple Business Chat, proprietary rich UI | Registered Apple Business Register entities; rich cards rendered. |
Chapter 9: Email — The Second Frontier
Email is where the damage is quietest — and where it can be most catastrophic.
In 2024, approximately 330 billion emails were sent globally per day. The overwhelming majority of email infrastructure — sending servers, reputation scoring, inbox filtering — was calibrated on human sending behavior: 40–200 emails per person per day, patterns that follow working hours, relationship histories that build over time.
An AI agent has none of these characteristics. An agent doing sales outreach might send 10,000 emails in an hour. An agent processing support tickets might generate hundreds of email confirmations in a minute. Every one of these patterns looks like a botnet to every inbox provider's ML system.
The domain destruction problem: When an agent sends email through a company's primary domain and enough recipients mark it as spam — which will happen, because the sending pattern is anomalous — Google and Microsoft will blacklist the domain. Not just the agent's email. The entire domain. Every human in the company suddenly can't deliver email. This has happened to real teams in production. Recovery takes weeks and costs significantly more than the problem would have cost to prevent.
What ACES provides for email:
- Isolated agent sending domains: Each ACN maps to a dedicated sending domain (
agent-7f3a.agents.yourco.getdial.ai) that is reputation-isolated from human company email. Agent reputation damage cannot cascade to human email delivery. - Agent-specific email headers:
X-ACES-ACN,X-ACES-Entity-Type: agent,X-ACES-Signature— machine-readable signals that this email originated from an AI agent. - Managed warm-up and deliverability: New agent sending identities are warmed up on Dial's shared IP infrastructure before being used at scale. Bounce and complaint rates are monitored and throttled automatically.
- Unsubscribe at protocol level: An unsubscribe received on any channel (SMS STOP, email unsubscribe, WhatsApp block) propagates to all channels automatically. One opt-out stops all channels.
- DKIM signing per ACN: Each agent has its own DKIM key pair. Email authentication is per-agent, not per-company domain.
If you have deployed an email agent through your company's primary domain and have not audited its sending volume, you likely already have a deliverability problem. You just have not seen the CEO's email go to spam yet.
Chapter 10: Trust, Attestation, and the Consent Framework
The most consequential design decision in ACES is how agent identity and consent are handled at the protocol level. Get this wrong, and ACES becomes better spam infrastructure. Get it right, and it becomes the trust layer that makes the agentic era workable for everyone.
10.1 The STIR/SHAKEN Gap
STIR/SHAKEN assigns attestation grades to phone calls:
- A (Full): Carrier fully knows the identity of the caller
- B (Partial): Carrier knows the call is from a legitimate customer, number identity unconfirmed
- C (Gateway): Call passed through; origin unverified
STIR/SHAKEN addresses carrier-level authenticity. It tells the receiving carrier "this call legitimately originated from Carrier X." It says nothing about whether the caller is a human or an agent, whether the agent is authorized for this communication, or what the agent has been instructed to do.
╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 8: THE TRUST STACK — Today vs. ACES ║
╠═══════════════════════════════════════╦══════════════════════════════════════╣
║ TODAY (Human Infrastructure) ║ ACES (Agent-Native) ║
╠═══════════════════════════════════════╬══════════════════════════════════════╣
║ ║ ║
║ Carrier Layer ║ Carrier Layer ║
║ └─ STIR/SHAKEN ║ └─ STIR/SHAKEN (preserved) ║
║ "call from Verizon" ✓ ║ "call from Verizon" ✓ ║
║ ║ ║
║ Application Layer ║ ACN Layer ║
║ └─ Nothing ║ └─ Cryptographic signature ║
║ Caller identity: UNKNOWN ║ "This is agent 7f3a" ✓ ║
║ Entity type: UNKNOWN ║ entity_type: agent ✓ ║
║ Authorization: UNKNOWN ║ ║
║ Consent record: UNKNOWN ║ Policy Layer ║
║ ║ └─ Consent verified ✓ ║
║ ║ TCPA basis documented ✓ ║
║ ║ Rate limits checked ✓ ║
║ ║ ║
║ ║ Session Layer ║
║ ║ └─ Full conversation context ✓ ║
║ ║ Cross-channel continuity ✓ ║
║ ║ Audit trail ✓ ║
╚═══════════════════════════════════════╩══════════════════════════════════════╝10.2 The Agent Attestation Token (AAT)
Every ACES message carries an Agent Attestation Token — a signed, verifiable claim that the sender is the registered agent it claims to be. For voice calls, the AAT is injected into SIP/WebRTC signaling headers. For SMS, it appears in extended headers. For email, it appears in the X-ACES-* header block. For WhatsApp and iMessage, it is carried in message metadata.
Any ACES-compliant receiving system can verify the AAT against the Dial ACN registry in under 50ms.
10.3 Mandatory Disclosure
For human recipients, the ACES policy layer enforces mandatory disclosure. When policy.disclosure: required, the agent's first turn in any voice interaction must include a natural-language disclosure before any other content:
"Hi, this is an AI assistant calling on behalf of Genway. I'm calling to follow up on your trial signup. Is now a good time?"
This is not advisory. It is enforced at the protocol layer, before carrier transmission. The disclosure text is configurable; the requirement is not. This is how compliance at scale works — not as a policy document, but as an infrastructure constraint.
10.4 Consent as a Protocol Primitive
The policy.consent_verified field in every ACES message is not a self-reported claim. It is resolved by the CAL against the operator's registered consent store at dispatch time. If consent cannot be verified, the message is blocked at the CAL layer — before it reaches the carrier, before any potential TCPA violation.
This shifts compliance from the legal team (reactive, post-hoc, expensive) to the infrastructure layer (proactive, automatic, cheap at scale).
Chapter 11: Session Management — Solving the Cold Start Problem
Every time a lead texts back on a different channel than the one the agent used to reach them, the agent starts over. It has no memory of Tuesday's call. It greets a warm prospect like a stranger.
This is the cold start problem — and it is the defining failure mode of current agent communication. It exists because communication context is stored per-channel in today's infrastructure. Twilio tracks voice call records. Your email provider tracks email threads. Your SMS handler tracks message history. None of these systems talk to each other.
╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 9: THE ACES SESSION MODEL ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ THREAD: acn://getdial.ai/genway/sales-agent-7f3a ↔ [email protected] ║
║ (Persists for the lifetime of the agent-contact relationship) ║
║ ║
║ └── SESSION: Initial outreach (May 10) ║
║ ├── Turn 1: Agent → Phone call → "Hi, saw your trial signup..." ║
║ ├── Turn 2: Lead ← SMS reply → "Send me pricing info" ║
║ └── Turn 3: Agent → Email → [Pricing PDF attached] ║
║ ║
║ └── SESSION: Follow-up (May 15) ║
║ ├── Turn 1: Agent → Phone call → "Following up on the pricing..." ║
║ └── Turn 2: Lead ← WhatsApp → "Can we do a demo?" ║
║ ║
║ └── SESSION: Contract negotiation (May 25) ← CURRENT ║
║ ├── Turn 1: Agent → Phone call → [Picks up where May 15 left off] ║
║ └── Turn 2: Lead ← Email reply → "I need exec approval first" ║
║ ║
║ ───────────────────────────────────────────────────────────────────────── ║
║ In the current (no ACES) world: ║
║ Each of these 8 turns is a cold start. Zero context carries over. ║
║ Different channels require different integrations. Agent repeats itself. ║
║ ║
║ In the ACES world: ║
║ Every turn arrives with full prior context. Channel switches are invisible. ║
║ The agent continues the conversation. Not a new one. ║
╚══════════════════════════════════════════════════════════════════════════════╝The session model is not a database feature or an application-layer concern. It is a protocol primitive — delivered with every inbound message, maintained by the infrastructure, visible to the agent without a single additional API call. Every inbound ACES message carries:
"context": {
"thread_id": "thread_lead_982",
"turn_index": 4,
"prior_turns_summary": "Lead confirmed interest in enterprise plan after call on May 10. Pricing PDF sent. Follow-up call on May 15. Lead asked about demo. Currently in contract negotiation."
}The agent picks up the thread. The contact never has to repeat themselves.
Chapter 12: The Dial Architecture
Dial is the reference implementation of ACES. The complete stack, from agent runtime to carrier, is composed of five layers:
╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 10: THE DIAL FULL STACK ARCHITECTURE ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ ┌──────────────────────────────────────────────────────────────────────┐ ║
║ │ AGENT RUNTIME LAYER │ ║
║ │ LangGraph │ OpenAI Agents SDK │ Claude │ Custom Frameworks │ ║
║ └────────────────────────────┬─────────────────────────────────────────┘ ║
║ │ ACES messages (normalized, all channels) ║
║ ┌────────────────────────────▼─────────────────────────────────────────┐ ║
║ │ DIAL SDK LAYER │ ║
║ │ Python │ TypeScript │ REST API │ MCP Tools │ ║
║ │ dial_send() │ acn.provision() │ reply() │ dial_initiate_call() │ ║
║ └────────────────────────────┬─────────────────────────────────────────┘ ║
║ │ ║
║ ┌────────────────────────────▼─────────────────────────────────────────┐ ║
║ │ ACES CORE ENGINE (DIAL CLOUD) │ ║
║ │ ┌──────────────┐ ┌───────────────┐ ┌──────────────────────────┐ │ ║
║ │ │ ACN Registry │ │ Channel Abstr.│ │ Session Store │ │ ║
║ │ │ (federated) │ │ Layer (CAL) │ │ (thread + context) │ │ ║
║ │ └──────────────┘ └───────────────┘ └──────────────────────────┘ │ ║
║ │ ┌──────────────┐ ┌───────────────┐ ┌──────────────────────────┐ │ ║
║ │ │ Consent Eng. │ │ Trust/Attest. │ │ Routing Engine │ │ ║
║ │ │ (TCPA/GDPR) │ │ (AAT / ACN) │ │ (channel selection) │ │ ║
║ │ └──────────────┘ └───────────────┘ └──────────────────────────┘ │ ║
║ └────────────────────────────┬─────────────────────────────────────────┘ ║
║ │ ║
║ ┌────────────────────────────▼─────────────────────────────────────────┐ ║
║ │ CHANNEL GATEWAY LAYER │ ║
║ │ Voice SMS Email WhatsApp iMessage │ ║
║ │ WebRTC/SIP A2P Pool SMTP/IMAP Meta API Apple Biz │ ║
║ │ STT+TTS 10DLC DKIM/SPF Templates Chat API │ ║
║ └────────────────────────────┬─────────────────────────────────────────┘ ║
║ │ ║
║ ┌────────────────────────────▼─────────────────────────────────────────┐ ║
║ │ CARRIER / PLATFORM LAYER │ ║
║ │ Tier-1 Carriers │ Meta │ Apple │ Bandwidth │ Google/MSFT │ ║
║ └──────────────────────────────────────────────────────────────────────┘ ║
╚══════════════════════════════════════════════════════════════════════════════╝12.1 The Dial SDK in Three Operations
Provision an ACN:
from dial import DialClient
client = DialClient(api_key="dial_sk_...")
agent = client.acn.provision(
namespace="genway",
agent_id="sales-agent-prod",
capabilities=["voice", "sms", "email", "whatsapp"],
policy={
"disclosure": "required",
"consent_model": "tcpa_express_written",
"can_spam": "compliant"
}
)
# → acn://getdial.ai/genway/sales-agent-prod
# → agent.phone: +14155551234 (immediately active — number purchased, live)
# → agent.email: [email protected] (immediately active)Send a communication:
client.send(
from_acn="acn://getdial.ai/genway/sales-agent-prod",
to="+14155559876",
content={
"type": "voice",
"body": "Hi, this is an AI assistant from Genway following up on your trial.",
"tts_hint": "professional"
},
channel="auto", # CAL selects optimal channel
session_id="sess_lead_982"
)Receive communications (webhook):
@app.post("/dial/inbound")
def handle_inbound(message: ACESMessage):
# message.content.body — already transcribed if voice
# message.context.prior_turns_summary — full history, all channels
# message.policy.consent_verified — already checked
# message.channel_meta.resolved_channel — which channel this came from
response = my_agent.process(message)
return client.reply(message, response)12.2 MCP Native Integration
For agent frameworks using the Model Context Protocol, Dial exposes its full interface as MCP tools — no SDK installation required. Available tools: dial_send_message, dial_initiate_call, dial_send_email, dial_get_session_context, dial_check_consent, dial_provision_acn, dial_list_channels.
Part III: The Path Forward
Chapter 13: Phone First — Why Voice Is the Right Starting Point
ACES is designed as a channel-agnostic standard. It will eventually normalize every communication channel an agent needs. But it starts with phone — and this is deliberate.
Phone is the universal identity anchor. A phone number is still the most universally trusted identifier in human communication. More humans have a phone number than a verified email, a social media account, or a government-issued digital ID. It is where trust is highest and where agents are most visible.
Phone is the highest-trust channel. A phone call demands real-time attention in a way no other channel does. It carries voice, tone, presence — a level of human signal that text cannot replicate. For the conversations where stakes are high — financial decisions, healthcare follow-ups, sales calls — voice is the channel that closes.
Phone is the hardest channel to get right. Voice requires real-time processing, transcription, synthesis, call state management, carrier integration, and STIR/SHAKEN attestation. If ACES handles voice correctly, every other channel is easier. The protocol is battle-tested here first.
Phone is the largest immediate gap. Every team building with AI agents has hit the phone wall. The workarounds are painful and well-documented. The demand is immediate, and the cost of getting it wrong — burned numbers, reputation decay, TCPA violations — is compounding in production deployments right now.
Chapter 14: Email Second — The Quiet Infrastructure Crisis
Email is the channel where the damage is least visible until it is catastrophic. Teams build agents that send emails, those agents burn domain reputation quietly, and one day the CEO notices that the company's email isn't being delivered.
Builders who have not yet seen this problem should not mistake their luck for safety. The mechanism is the same for every team: high-volume agent sending triggers anomaly detection, complaint rates spike, domain is blacklisted. The only variable is timing.
ACES's email layer solves the domain destruction problem permanently — isolated sending domains, per-ACN DKIM keys, managed deliverability infrastructure, and suppression list propagation across channels. The fix is architectural; it cannot be patched into existing infrastructure after the fact.
After phone, email is the second largest communication surface for agents and the one with the most severe downside risk if handled incorrectly.
Chapter 15: The Expansion Roadmap
╔══════════════════════════════════════════════════════════════════════════════╗
║ FIGURE 11: DIAL ROADMAP — FROM PHONE TO THE FULL AGENT COMMUNICATION STACK ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ PHASE 1 — VOICE & TEXT FOUNDATION (2025–2026) [ LIVE NOW ] ║
║ ────────────────────────────────── ║
║ ✓ ACES v1.0 specification ║
║ ✓ ACN provisioning and registry ║
║ ✓ Voice (PSTN) — inbound + outbound ║
║ ✓ SMS (A2P) — managed 10DLC registration ║
║ ✓ Session management (cross-channel) ║
║ ✓ Consent engine (TCPA) ║
║ ✓ Python SDK, TypeScript SDK, REST API, MCP tools ║
║ ║
║ PHASE 2 — RICH MESSAGING (2026) ║
║ ───────────────────────── ║
║ ○ Email — isolated agent domains, DKIM per ACN, deliverability management ║
║ ○ WhatsApp Business — CAL integration, template management ║
║ ○ iMessage — Apple Business Chat gateway ║
║ ○ ACES v1.1: structured message types (cards, forms, actions) ║
║ ║
║ PHASE 3 — ENTERPRISE & AGENT-TO-AGENT (2027) ║
║ ──────────────────────────────────────────── ║
║ ○ Slack and Microsoft Teams channels ║
║ ○ A2A (agent-to-agent) authenticated messaging protocol ║
║ ○ Telegram, Signal, international channel support ║
║ ○ Open ACN registry federation — third-party registry providers ║
║ ║
║ PHASE 4 — THE AGENTIC PRESENCE PROTOCOL (2027+) ║
║ ──────────────────────────────────────────────── ║
║ ○ ACN becomes a permanent agent address across all channels ║
║ ○ Channel-independent reachability — future channels auto-onboard ║
║ ○ Cross-organization agent identity federation ║
║ ○ The ACN registry: as fundamental as DNS ║
╚══════════════════════════════════════════════════════════════════════════════╝Chapter 16: A Call to Builders
The teams that wait for better human-era infrastructure will not be waiting for something that is coming. They will be waiting for something that was never designed to arrive.
If you are building AI agents that communicate with humans, you have almost certainly hit the wall described in Chapter 3. Your agents are borrowing human phone numbers and burning their reputation. Your email-sending agents are quietly destroying your domain deliverability. Your compliance team is asking questions your engineers cannot answer. Your agents lose conversational context whenever a contact switches channels.
This is not a bug in your implementation. It is the predictable consequence of running agentic workloads on human-designed infrastructure. Builders who do not solve it at the infrastructure layer will spend the rest of their engineering budget solving it again and again at the application layer — until a competitor who solved it at the right layer wins.
For engineering teams: Dial is available now. Provision your first ACN in 10 seconds. Send your first ACES-native voice call. Have session state working across channels before you finish your coffee. The API is simple by design — not because the problem is simple, but because the complexity belongs in the infrastructure layer, not in your agent code. Start at [getdial.ai](https://getdial.ai).
For the standards community: ACES is being developed as an open specification. The ACN registry federation protocol, the message schema specification, and the trust framework documentation will be published under an open license. The goal is an ecosystem, not a monopoly. If you are building agent communication infrastructure, we want to work with you on the standard.
For CTOs evaluating lock-in risk: The ACN format is portable. Your agents' identities are not tied to Dial's infrastructure. The protocol is open. If a better ACES implementation emerges, you can migrate your ACNs without rebuilding your agent communication logic. We believe the right way to win in infrastructure is to make the protocol genuinely open — and then be the best at running it.
The builders who define the infrastructure layer do not just solve today's problem. They earn the right to participate in every solution built on top of it. TCP/IP did not just move data; it became the substrate for everything from email to video to the entire web economy. The agent channel exchange standard that becomes the standard will do the same for the agentic era.
Conclusion
The telephone was built for human voice. Email was built for human correspondence. SMS was built for human text. WhatsApp was built for human connection. Every communication system in existence was designed under the assumption that the entities communicating are humans — operating at human speed, with human identity anchors, in human-scale volumes, under regulations written for human behavior.
That assumption expires at the 1:100 threshold. We are crossing it now.
The five failure modes that appear in every production agent communication deployment — reputation decay, volume throttle, identity ambiguity, cross-channel fragmentation, and compliance exposure — are not engineering problems. They are infrastructure problems. They share a single root cause: agents are the wrong species for the infrastructure they are running on.
The Agent Channel Exchange Standard is the infrastructure for the right species. It is not a product feature or a developer convenience. It is the minimum viable substrate for a world where hundreds of billions of AI agents need to communicate reliably, verifiably, at scale, across every channel that matters — without burning the communication infrastructure of the humans they serve.
Phone is where we start, because it is where the gap is widest and the demand is sharpest. Email follows immediately, because it is where the damage is quietest and the risk is highest. WhatsApp, iMessage, Slack, and every channel yet to emerge will follow, because agents need to communicate wherever humans are reachable.
The era of agents borrowing human phone numbers and email addresses is ending.
The era of agents having their own communication stack is beginning.
The infrastructure is ready. The species the infrastructure was designed for has changed.
Appendix A: ACES v1.0 Message Schema Reference
Full JSON Schema specification — (coming soon)
Appendix B: ACN Registry Specification
Distributed registry design, resolution protocol, federation spec — (coming soon)
Appendix C: Regulatory Reference
| Regulation | Jurisdiction | ACES Handling |
|---|---|---|
| TCPA (47 U.S.C. § 227) | United States | Consent engine verifies express written consent before every automated call/SMS dispatch |
| CAN-SPAM Act | United States | Unsubscribe links injected for commercial email; suppression lists propagated cross-channel |
| GDPR (Regulation 2016/679) | European Union | Lawful basis documented per ACN policy; data minimization enforced in session store |
| STIR/SHAKEN (47 C.F.R. Part 64) | United States | ACES AAT layer complements, does not replace, carrier-level STIR/SHAKEN attestation |
| EU AI Act (Regulation 2024/1689) | European Union | Mandatory disclosure framework addresses Article 52 transparency obligations for AI-to-human interaction |
| PECR | United Kingdom | Consent and opt-out handling equivalent to GDPR consent engine |
Appendix D: Glossary
| Term | Definition |
|---|---|
| ACN | Agent Communication Number. Persistent, cryptographically rooted identifier for an AI agent. Format: acn://<registry>/<namespace>/<agent-id> |
| ACES | Agent Channel Exchange Standard. The channel-agnostic communication standard defined in this paper. |
| CAL | Channel Abstraction Layer. The ACES component responsible for normalizing inbound communications from all channels into ACES message format, and translating outbound ACES messages to channel-specific encoding. |
| AAT | Agent Attestation Token. A signed, verifiable claim embedded in every ACES message that proves the sender is the registered agent it claims to be. |
| Thread | The persistent ACES construct representing the full communication history between an agent (by ACN) and a contact (by address). |
| Session | A bounded conversational context within a thread, representing a specific interaction goal. |
| Wrong Species Problem | The foundational infrastructure mismatch: every layer of global communication infrastructure — protocols, rate limits, identity models, regulatory frameworks — was designed for human users. AI agents violate every one of its assumptions simultaneously. |
© 2026 Dial. This whitepaper is released under Creative Commons Attribution 4.0 International License. The Agent Channel Exchange Standard specification is developed as an open standard.
Dial is the reference implementation of ACES. Contact: [email protected]