Skip to main content
Skip to article

#A2A Protocol: AI Agent Communication Over WhatsApp

8 min read

Your AI Agents Can't Talk to Each Other

You've got an AI support agent handling basic inquiries. Works great. But when a customer asks about inventory levels, your support agent needs to talk to your inventory agent. When they want to schedule a demo, you need to reach your calendar agent. When they're ready to buy, payment processing kicks in.

One agent isn't enough anymore. You need agents that can coordinate with other agents—but there's no standard way to make them talk.

Custom integrations don't scale. Building a one-off connection between every agent pair becomes a maintenance nightmare. You need a protocol—like HTTP for web services, but designed for AI agent coordination.

The A2A (Agent-to-Agent) protocol solves this. It's MoltFlow's standardized way for AI agents to discover each other, verify identities, and exchange structured messages—all over WhatsApp. Think of it as the missing infrastructure layer for multi-agent systems.

By the end of this guide, you'll understand how A2A works and how to build agent systems that can coordinate complex workflows without human intervention.

What Exactly is A2A?

A2A is a JSON-RPC 2.0 based protocol that standardizes three critical things:

  1. Discovery — How agents find and identify each other
  2. Authentication — How agents verify they're talking to who they think they're talking to
  3. Messaging — How agents send structured requests and responses

The genius is building this on top of WhatsApp. Here's why that matters:

Why WhatsApp as Transport?

You might be thinking: "Why not just use HTTP APIs directly?" Good question. Here's what WhatsApp gives you that raw HTTP doesn't:

  • Universal identity — Every agent gets a phone number. No DNS, no IP addresses, no complicated service discovery.
  • End-to-end encryption — Built-in security for agent communications. No TLS certificates to manage.
  • Push delivery — Messages arrive instantly via WhatsApp's infrastructure. No polling, no websockets to maintain.
  • Delivery receipts — You know when the other agent received your message.
  • Persistent connections — WhatsApp handles reconnection, message queuing, and delivery retries automatically.

In my experience working with multi-agent systems, the infrastructure overhead kills most projects before they launch. A2A leverages WhatsApp to handle all of that for you.

Agent Discovery: The Well-Known Standard

Before agents can communicate, they need to discover each other's capabilities. A2A uses the .well-known pattern for this — the same approach used by OAuth, ACME (Let's Encrypt), and other internet standards.

Every A2A-enabled agent exposes a JSON document at /.well-known/agent.json. Here's what it looks like:

bash
curl https://apiv2.waiflow.app/.well-known/agent.json

Response:

json
{
  "name": "MoltFlow Agent",
  "version": "1.0.0",
  "description": "WhatsApp automation and AI agent orchestration",
  "capabilities": [
    "message.send",
    "message.receive",
    "group.list",
    "group.monitor",
    "contact.search",
    "webhook.create"
  ],
  "authentication": {
    "type": "bearer",
    "endpoint": "/api/v2/a2a"
  },
  "rpc_endpoint": "/api/v2/a2a",
  "rate_limits": {
    "requests_per_hour": 1000,
    "burst_limit": 50
  }
}

Let's break down what each field tells you:

  • name & version — Agent identity. Useful for logging and debugging.
  • capabilities — Array of JSON-RPC methods this agent supports. Before calling a method, check if it's listed here.
  • authentication — How to authenticate with this agent. Most use bearer tokens.
  • rpc_endpoint — Where to send JSON-RPC requests.
  • rate_limits — How many requests you can make before hitting throttling.

Resolving Agents by Phone Number

You can also discover an agent by their WhatsApp phone number:

bash
curl https://apiv2.waiflow.app/api/v2/agents/resolve/16505551234 \
  -H "Authorization: Bearer YOUR_API_TOKEN"

This returns the same agent card plus additional metadata about trust level, interaction history, and whether this agent is on your trusted peer list.

The discovery pattern makes A2A networks self-documenting. You don't need a central registry or service mesh. Just query the agent directly.

Sending Agent Messages: JSON-RPC 2.0

Once you've discovered an agent's capabilities, you can send it structured requests using JSON-RPC 2.0.

Here's the format:

json
{
  "jsonrpc": "2.0",
  "id": "req-12345",
  "method": "message.send",
  "params": {
    "chatId": "[email protected]",
    "text": "Order #5432 has shipped. Tracking: 1Z999AA10123456784"
  }
}

Breaking this down:

  • jsonrpc: "2.0" — Protocol version. Always "2.0".
  • id — Unique request identifier. Use this to match responses to requests. Can be a string or number.
  • method — The capability you're invoking. Must be one of the methods listed in the agent's capabilities array.
  • params — Method-specific parameters. Structure depends on the method.

Send this via HTTP POST to the agent's RPC endpoint:

bash
curl -X POST https://apiv2.waiflow.app/api/v2/a2a \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": "req-12345",
    "method": "message.send",
    "params": {
      "chatId": "[email protected]",
      "text": "Order #5432 has shipped."
    }
  }'

Response:

json
{
  "jsonrpc": "2.0",
  "id": "req-12345",
  "result": {
    "messageId": "3EB0F2A4B5C6D7E8F9",
    "timestamp": "2026-01-20T14:22:00Z",
    "status": "sent"
  }
}

The response includes the same id so you can match it to your request. The result field contains the method's return value.

Error Handling

If something goes wrong, you'll get a JSON-RPC error response:

json
{
  "jsonrpc": "2.0",
  "id": "req-12345",
  "error": {
    "code": -32602,
    "message": "Invalid params: chatId format incorrect",
    "data": {
      "expected": "{phone}@c.us or {groupId}@g.us",
      "received": "invalid-format"
    }
  }
}

Standard JSON-RPC error codes:

CodeMeaning
-32700Parse error (invalid JSON)
-32600Invalid request (missing required fields)
-32601Method not found (agent doesn't support this capability)
-32602Invalid params (wrong parameter format)
-32603Internal error (agent-side failure)

This standardization makes error handling consistent across all agents.

Building a Multi-Agent Workflow

Let's walk through a real-world example: a customer support system with three specialized agents.

Agents:

  1. Support Agent — Handles customer inquiries, triages issues
  2. Inventory Agent — Checks product availability, stock levels
  3. Notification Agent — Sends order updates, shipping notifications

Workflow: Customer asks about product availability → Support Agent queries Inventory Agent → if available, Support Agent creates order → Notification Agent sends confirmation.

Step 1: Support Agent receives customer message

Customer sends: "Do you have the blue widget in stock?"

Support Agent receives this via webhook, identifies it as an inventory question, and needs to consult the Inventory Agent.

Step 2: Support Agent calls Inventory Agent

bash
curl -X POST https://inventory-agent.example.com/api/v2/a2a \
  -H "Authorization: Bearer INVENTORY_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": "check-123",
    "method": "inventory.check",
    "params": {
      "sku": "WIDGET-BLUE-001",
      "quantity": 1
    }
  }'

Inventory Agent response:

json
{
  "jsonrpc": "2.0",
  "id": "check-123",
  "result": {
    "sku": "WIDGET-BLUE-001",
    "available": true,
    "quantity": 47,
    "price": 29.99
  }
}

Step 3: Support Agent responds to customer

Support Agent now has the data it needs:

bash
curl -X POST https://apiv2.waiflow.app/api/v2/a2a \
  -H "Authorization: Bearer SUPPORT_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": "msg-456",
    "method": "message.send",
    "params": {
      "chatId": "[email protected]",
      "text": "Yes! We have 47 blue widgets in stock at $29.99 each. Would you like to order?"
    }
  }'

Step 4: Notification Agent sends confirmation

Once the customer confirms, Support Agent triggers the Notification Agent:

bash
curl -X POST https://notification-agent.example.com/api/v2/a2a \
  -H "Authorization: Bearer NOTIFICATION_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": "notify-789",
    "method": "notification.send",
    "params": {
      "template": "order_confirmation",
      "recipient": "[email protected]",
      "data": {
        "order_id": "ORD-12345",
        "item": "Blue Widget",
        "total": 29.99
      }
    }
  }'

All three agents coordinated without human intervention. The Support Agent orchestrated the workflow by calling the appropriate agents at each step.

Security and Trust Management

Here's the thing: not all agents should trust each other. You need granular control over which agents can invoke which capabilities on your agent.

MoltFlow's A2A implementation includes a trust management system:

Trust Levels

LevelAccess
blockedAll requests rejected
untrustedLimited capabilities only (read-only)
trustedFull access to all capabilities

You can set trust levels per agent:

bash
curl -X PATCH https://apiv2.waiflow.app/api/v2/agents/peers/{peer_id}/trust \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "trust_level": "trusted"
  }'

Rate Limiting

Every agent has rate limits to prevent abuse. MoltFlow enforces these automatically:

PlanRequests/HourBurst
Free10010
Starter1,00050
Business10,000200
EnterpriseCustomCustom

When you hit a rate limit, you'll get a 429 response with a Retry-After header telling you when to try again.

Authentication Tokens

Agent-to-agent authentication uses bearer tokens. Each agent generates its own API keys which other agents use to authenticate.

Best practice: Rotate agent API keys every 90 days. Store them in a secrets manager, never commit them to version control.

What's Next?

You now understand the core of A2A:

  • Agent discovery via .well-known/agent.json
  • JSON-RPC 2.0 message format
  • Multi-agent workflow orchestration
  • Security and trust management

MoltFlow is the only WhatsApp platform with native A2A support, giving you a competitive edge in building autonomous agent networks.

Continue learning:

Ready to implement A2A? Follow our step-by-step guide: Enable Agent-to-Agent (A2A) Communication

Create your free account and start building agent networks today. A2A protocol included on all plans.

> Try MoltFlow Free — 100 messages/month

$ curl https://molt.waiflow.app/pricing

bash-5.2$ echo "End of post."_