Skip to content
ARCEDE

Communication and the Agent Internet

Published September 13, 2026, by Frans

An agent that can pay and prove who it is still can't do the thing humans spend most of their internet time doing: talk to other people.

The first two meta-capabilities of the agent internet — payment and identity — solve access. The agent can authenticate and transact. But the majority of what humans do online isn't transactional. It's communicative. Emails, messages, calendar invitations, document sharing, support tickets, negotiations, follow-ups. The utilitarian internet is, more than anything, a coordination machine — and coordination requires communication.

An agent that cannot communicate on behalf of its user is reduced to a research assistant that hands off a memo and waits. It finds the best contractor but can't send the inquiry. It identifies the scheduling conflict but can't propose an alternative. It drafts the perfect follow-up email but can't send it. At every step, the human must context-switch back into the loop to do the one thing the agent can't: talk to someone.

Communication is the third meta-capability. Like payment and identity, it doesn't unlock one service — it unlocks the coordination layer of the entire internet. And like payment and identity, it must be built as an open, competitive ecosystem — because the alternative is a communication monopoly that sees every message every agent sends on behalf of every user.

The Communication Bottleneck

What Agents Can Do Today

Current agent runtimes can navigate communication interfaces. They can open an email, draft an email, and present it for the user to review, or send autonomously. They can read incoming messages, extract information, and summarize it. They can fill out contact forms and submit support tickets.

What they cannot do:

Send as the user. Navigating a compose window and clicking "send" through UI automation is fragile, slow, and creates authentication headaches. Every email client, messaging platform, and calendar service has different UI patterns that break with updates. This is the communication equivalent of screen-scraping — it works until it doesn't.

Negotiate in real time. Multi-turn communication — where the agent sends a message, waits for a response, evaluates it, and replies — requires persistent session management across communication channels. Today's agents can handle a single turn or brittle multi-turn negotiation that often requires the human to check back repeatedly.

Coordinate across channels. A task might require sending an email to one party, a Slack message to another, and a calendar invitation to a third — coordinating across platforms with different protocols, different authentication, and different delivery guarantees. Agents have no unified abstraction for multi-channel coordination.

Communicate with other agents. As agents proliferate, the most efficient coordination is often agent-to-agent: your scheduling agent talks to their scheduling agent, and both humans receive a confirmed meeting time without either one touching a calendar. There's no protocol for this today.

Why Communication Is Different from Other Capabilities

Most agent capabilities are request-response: the agent sends a request, gets a result, moves on. Communication is conversational: it's asynchronous, multi-turn, stateful, and often unpredictable. The agent sends a message and might get a response in 30 seconds or 3 days. The response might require a follow-up, a clarification, a negotiation, or an escalation to the human.

This makes communication the hardest capability to automate — and the most valuable once solved. A provider that offers agent-native communication doesn't just handle message delivery. They handle the entire lifecycle: drafting, sending, receiving, threading, scheduling, and — critically — knowing when to escalate to the human because the conversation has moved beyond the agent's delegated authority.

What Communication Providers Can Offer

Tier 1: Programmatic Messaging

The foundational capability: send and receive messages through structured APIs, with proper sender authentication and delivery guarantees.

Mechanics:

  • Agent requests message delivery through the provider's API (not through UI automation)
  • Provider handles sender authentication (SPF, DKIM, DMARC for email; platform-specific auth for messaging)
  • Provider confirms delivery and reports read receipts where available
  • All messages are logged in the agent runtime's audit trail

Why this matters beyond "just use SMTP": Raw email sending is trivial. Authenticated, reputation-managed, deliverable email sending is hard. Emails sent from unknown infrastructure land in spam. Emails without proper DKIM signatures get rejected. Agents that send email through UI automation inherit the user's sending reputation — but this approach doesn't scale, and it couples the agent to a specific email client's UI.

A communication provider that offers agent-native email delivery handles reputation management, authentication standards, and deliverability — letting the agent focus on what to say, not how to get the message through.

agent.json declaration:

\{
  "capabilities": \{
    "email.send": \{
      "description": "Send an email on behalf of a verified user",
      "auth": "attestation",
      "params": \{
        "from_alias": "string",
        "to": "array",
        "subject": "string",
        "body": "string",
        "reply_to_thread": "string",
        "attachments": "array"
      \},
      "constraints": \{
        "requires_user_approval": "configurable",
        "daily_send_limit": "configurable",
        "approved_recipient_domains": "configurable"
      \},
      "cost_per_call": 0.002
    \},
    "email.receive": \{
      "description": "Retrieve new messages matching filter criteria",
      "auth": "attestation",
      "params": \{
        "filters": "object",
        "since": "string"
      \},
      "returns": \{
        "messages": "array"
      \},
      "cost_per_call": 0.001
    \}
  \}
\}

Tier 2: Calendar and Scheduling Coordination

The capability that eliminates the most wasted human time: programmatic scheduling that handles availability checking, timezone negotiation, conflict resolution, and multi-party coordination.

Mechanics:

  • Agent queries user's availability through the provider
  • Agent proposes meeting times to other parties (via their agents or directly)
  • Provider handles timezone conversion, conflict detection, and calendar writes
  • Multi-party scheduling resolves through constraint satisfaction (not the current "which of these three times works for you?" email chain)

Why this is transformative: Scheduling is the clearest example of a task where human involvement adds zero value. Every person involved in scheduling a meeting would prefer not to be involved. The entire process — checking availability, proposing times, waiting for responses, rescheduling conflicts — is pure coordination overhead. An agent with calendar access eliminates it entirely.

But calendar access is deeply sensitive. An agent that can read a user's calendar knows their location, their relationships, their health appointments, their job interviews. This is exactly the kind of capability where the open, competitive model matters most — the user should be able to choose a scheduling provider they trust, not be forced into whichever provider their agent runtime partnered with.

Tier 3: Agent-to-Agent Messaging

The most advanced communication capability: a structured protocol for agents to negotiate directly with each other, on behalf of their respective humans.

Mechanics:

  • Agent A needs to coordinate with Agent B (e.g., scheduling a meeting between their respective users)
  • Both agents discover each other's communication capabilities through agent.json
  • They exchange structured messages through a shared protocol
  • Each agent operates within its user's delegated authority
  • The result is presented to both humans for confirmation (if required by their delegation policies)

Example flow:

User A tells Agent A: "Schedule a meeting with Jordan next week to discuss the project proposal"

Agent A → Communication Provider → Agent B:
\{
  "type": "scheduling_request",
  "from_user": "pseudonym_A",
  "subject": "Project proposal discussion",
  "constraints": \{
    "date_range": "2026-03-16 to 2026-03-20",
    "duration_minutes": 30,
    "available_slots": ["Mon 10-12", "Tue 14-16", "Thu 9-11"]
  \}
\}

Agent B checks User B's calendar, responds:
\{
  "type": "scheduling_response",
  "accepted_slot": "Tue 14:30-15:00",
  "location_preference": "video_call"
\}

Agent A confirms → both calendars updated → both users notified

Total human involvement: one sentence from User A, one notification to each user. The coordination happened entirely between agents, through a structured protocol, mediated by communication providers that both agents trust.

The Open Communication Ecosystem

Why Monopoly Communication Fails

The history of internet communication is a history of failed monopolies producing fragmented, incompatible systems — and open standards eventually winning.

Email succeeded because SMTP is open. Anyone can run a mail server. Anyone can send email to anyone else. Gmail competes with Outlook competes with ProtonMail — all on the same protocol. The result: universal reachability.

Instant messaging failed at interoperability. AIM, MSN, Yahoo Messenger, WhatsApp, Telegram, Signal, Slack, Discord, iMessage — each is a walled garden. You can't send a WhatsApp message to a Telegram user. The result: fragmentation, lock-in, and users maintaining accounts on half a dozen platforms.

Agent communication will face the same fork. If a single provider controls the messaging layer — if agents can only communicate through one platform's API — the result is the messaging silo problem at machine scale. Agent A can't coordinate with Agent B because they use different communication providers. The user must manually bridge the gap, defeating the purpose of delegation.

The agent internet must learn from email, not from messaging apps. The communication protocol must be open, the providers must interoperate, and no single entity should be able to prevent two agents from communicating.

The Interoperability Architecture

Agent communication needs three layers, each of which must be standardized:

1. Message format. A structured schema for agent-to-agent and agent-to-service messages. This includes: message type (request, response, notification, escalation), content (structured payload, not free-text), authentication (sender attestation from the identity layer), and threading (conversation context for multi-turn exchanges).

2. Delivery protocol. How messages get from sender to recipient. This could be built on existing protocols (SMTP for email-like messages, WebSocket for real-time exchanges) or a new protocol purpose-built for agent communication. The key requirement: any provider that implements the protocol can exchange messages with any other provider.

3. Discovery. How an agent finds the communication endpoint for another agent or user. This ties into the agent.json standard: communication providers declare their capabilities, and agent runtimes discover them through the same mechanism used for any other capability.

What Competition Produces

In a competitive communication ecosystem:

Privacy innovation. Some providers will specialize in end-to-end encrypted agent communication — where even the communication provider can't read the message payload. Others will offer metadata-minimized delivery (the provider routes the message but doesn't log who's communicating with whom). Users choose based on their privacy requirements.

Reliability differentiation. Some providers will guarantee delivery within milliseconds (critical for real-time agent-to-agent negotiation). Others will optimize for cost efficiency on bulk messaging (agents sending hundreds of follow-up emails). Different use cases, different providers.

Compliance specialization. Financial services communication must be archived for regulatory compliance. Healthcare communication must meet HIPAA requirements. Legal communication may require delivery confirmation with legal standing. Each of these is a specialization that a focused provider can serve better than a generalist monopoly.

Pricing pressure. Email delivery costs approach zero because SMTP is open and anyone can run a mail server. Agent communication costs should follow the same trajectory — the open protocol ensures that providers compete on price, and free or near-free options emerge for basic messaging.

The Surveillance Risk

Communication is the most surveillance-sensitive capability in the agent ecosystem. A communication provider that handles all agent messaging sees:

  • Who is communicating with whom (social graph)
  • What they're communicating about (content)
  • When and how often (behavioral patterns)
  • Which services are involved (economic activity)

Aggregated across all users of an agent runtime, this is a comprehensive map of human economic and social activity as mediated by agents. A monopoly provider with this data has more visibility into human behavior than any surveillance system in history — because agents communicate more frequently, more specifically, and more transactionally than humans do directly.

This is the strongest argument against communication monopoly. Not antitrust theory, not market efficiency — surveillance risk. A single provider controlling agent communication is a single point of surveillance that would make current privacy concerns about email providers look trivial.

The mitigation is structural: multiple providers, encrypted channels, minimal metadata retention, and user choice. No single entity should see all agent communication. The architecture must make comprehensive surveillance structurally impossible, not just policy-prohibited.

The Compound Effect: Payment + Identity + Communication

The Fully Autonomous Agent

With all three meta-capabilities in place, an agent can complete the full cycle of economic activity:

Intent: "Hire a freelance designer to create a logo for my new project"

1. COMMUNICATION: Agent posts job description to freelance platforms,
   receives proposals, conducts initial screening conversations

2. IDENTITY: Agent verifies freelancer credentials, authenticates
   to project management platform, establishes shared workspace

3. COMMUNICATION: Agent negotiates scope, timeline, and price with
   freelancer's agent (agent-to-agent negotiation within both
   users' delegation parameters)

4. PAYMENT: Agent creates escrow payment for the agreed amount,
   releases milestone payments upon delivery

5. COMMUNICATION: Agent provides feedback, requests revisions,
   confirms final delivery, sends thank-you note

6. PAYMENT: Agent releases final payment, leaves a review

Total human involvement: approve the initial budget and delegation
parameters, review the final deliverable.

Every step of this workflow — which currently takes hours of human time across multiple platforms over days or weeks — is handled autonomously. The human sets the parameters and reviews the result. The agent handles everything in between.

This is only possible when all three meta-capabilities work together. Remove any one:

  • Without payment: The agent can find the freelancer and negotiate but can't pay.
  • Without identity: The agent can't verify the freelancer or authenticate to the workspace.
  • Without communication: The agent can't negotiate, provide feedback, or coordinate delivery.

Why All Three Must Be Open

The compound effect also means that monopoly in any one layer constrains the other two. A payment monopoly can demand exclusive communication partnerships. A communication monopoly can refuse to deliver messages that don't use a specific identity provider. An identity monopoly can require specific payment and communication providers as conditions of attestation.

This is the bundling play — and it's the most predictable strategy for any provider that achieves dominance in one layer. "Use our payment system, and we'll give you preferential rates on our identity and communication services." This is how platform monopolies form, and it's how they extract value from ecosystems.

The defense is the open standard. When payment, identity, and communication are all defined by open, interoperable protocols:

  • A user can use Provider A for payment, Provider B for identity, and Provider C for communication
  • Providers cannot bundle because the protocols ensure any combination works
  • Switching one provider doesn't require switching the others
  • Innovation in one layer doesn't require permission from providers in the other layers

This unbundled, interoperable model is less convenient for providers who want to build empires. It is dramatically better for users, for the ecosystem, and for the long-term health of the agent internet.

Integration Roadmap for Communication Providers

Phase 1: Publish an agent.json

If you operate email infrastructure (Mailgun, SendGrid, Postmark, Fastmail), a messaging platform (Slack, Discord, Telegram), or a calendar service (Google Calendar, Cal.com, Calendly), publish an agent.json that declares your existing API capabilities in the standard format.

This makes you discoverable. Agent runtimes evaluating communication providers will find you automatically.

Phase 2: Agent-Specific Messaging Product

Build the core product:

  • Authenticated send/receive with attestation-based identity (not just API keys)
  • Per-user delegation policies (daily limits, approved recipients, content constraints)
  • Threading and conversation state management
  • Webhook delivery to runtime audit systems
  • Multi-channel support (email + messaging from a single integration)

Phase 3: Interoperability

This is where competition becomes healthy:

  • Implement the open agent communication protocol
  • Exchange messages with agents using other communication providers
  • Federated delivery: if the recipient's agent uses a different provider, route through the interop layer rather than failing
  • Publish interoperability test suites

Phase 4: Agent-to-Agent Protocol

Build the advanced coordination layer:

  • Structured negotiation protocol (propose, counter, accept, reject)
  • Multi-party coordination (scheduling, consensus, group decisions)
  • Escalation routing (automatically escalate to human when the conversation exceeds the agent's delegation authority)
  • Real-time and asynchronous modes (some negotiations need milliseconds, some happen over days)

What This Means for the Ecosystem

For Agent Runtimes

Like payment and identity, communication should not be built into the runtime. The runtime manages supervision, delegation, and audit. Communication providers handle delivery, authentication, and deliverability. The separation is clean:

  • Runtime decides: what to say, when to say it, whether the agent has authority to say it
  • Provider handles: how to deliver it, how to authenticate the sender, how to guarantee receipt

For Existing Communication Platforms

Gmail, Outlook, Slack, and other dominant communication platforms face a strategic choice: participate in the open agent communication standard, or be routed around.

If they participate, they gain: a new source of API revenue (agents sending messages through their infrastructure), deeper user engagement (users whose agents use their platform are stickier), and relevance in the agent economy.

If they don't, agents will use alternative providers that do. The human will still have email for their personal email — but their agent will send messages through a provider that offers programmatic access, proper attestation support, and interoperability with other agents. The human's inbox receives the messages; it just isn't the one sending them.

The open standard creates space for both. Legacy human email providers can be an agent communication provider and compete with other providers. The standard doesn't exclude incumbents — it just prevents them from excluding everyone else.

For Users

The user's delegation policy for communication should be the most carefully configured of the three meta-capabilities. Payment has clear limits (dollar amounts). Identity has clear scopes (what the agent can access). Communication requires nuance: who the agent can contact, what it can say, and when it should escalate.

The best communication providers will offer intuitive delegation interfaces:

  • "My agent can send emails to people I've emailed before, but new contacts require my approval"
  • "My agent can schedule meetings during business hours but not on weekends"
  • "My agent can negotiate up to 15% off the listed price; beyond that, ask me"

These are not technical configurations — they're expressions of the user's preferences and boundaries. The communication provider that makes these easy to set and easy to modify will earn user trust and market share.

Conclusion

Communication is the capability that transforms agents from executors into representatives. An agent that can pay and authenticate but cannot communicate is still fundamentally limited — it can complete isolated transactions but cannot coordinate, negotiate, or maintain the ongoing relationships that define most economic activity.

The communication layer must be open for the same reasons the payment and identity layers must be open — and the risks of monopoly are even more acute. A payment monopoly sees your transactions. An identity monopoly sees your access patterns. A communication monopoly sees your conversations. The surveillance potential of a centralized agent communication provider is the strongest argument for a competitive, interoperable ecosystem.

The playbook is the same as for payment and identity: publish an agent.json, build an agent-specific product, invest in interoperability, and compete on the merits. The providers who build for the open standard will earn routing from every agent runtime. The providers who build walled gardens will find that agents — unlike humans — don't tolerate lock-in. They just route around it.

The third most valuable capability on the agent internet is the ability to speak on someone's behalf. The providers who offer it openly will define how the agent economy coordinates. The providers who try to control it will learn what every messaging silo has learned: in communication, interoperability eventually wins.

Identity
All papers