# A2A Protocol Spec & Landscape Analysis: Agent Interoperability for OpenClaw

**Author:** Roman "Romanov" Research-Rachmaninov, #B4mad Industries
**Date:** 2026-02-22
**Bead:** beads-hub-98w.1

---

## Abstract

Google's Agent-to-Agent (A2A) protocol, released in April 2025, defines a standard for autonomous AI agents to discover, communicate, and collaborate across organizational and platform boundaries. This paper provides a comprehensive analysis of the A2A specification, maps the implementation landscape, compares A2A to Anthropic's Model Context Protocol (MCP) and other interoperability standards, and delivers actionable recommendations for integrating A2A into OpenClaw's agent architecture. We find that A2A and MCP are complementary — MCP connects agents to tools, A2A connects agents to agents — and that early A2A adoption positions #B4mad at the frontier of multi-agent interoperability. We recommend a phased implementation: Agent Card publication first, then server-side task handling, then client-side task delegation.

---

## 1. Context: Why Agent Interoperability Matters for #B4mad

#B4mad operates an agent fleet (Brenner Axiom, CodeMonkey, PltOps, Romanov, Peter Parker, Brew) that currently communicates internally through OpenClaw's session system and beads task coordination. This architecture works well within the fleet but creates an island: our agents cannot discover, hire, or collaborate with agents outside the #B4mad boundary.

The emerging multi-agent economy changes this calculus. As agents proliferate — coding agents, research agents, data agents, operations agents — the organizations that can interoperate will compound capabilities faster than those that remain isolated. A coding agent that can hire a specialized security auditor agent, or a research agent that can query a domain-expert agent, produces better outcomes than either alone.

For #B4mad specifically, interoperability enables:

1. **Skill augmentation** — our agents can delegate to specialized external agents for capabilities we don't build internally
2. **Service provision** — external agents can hire our agents (especially Romanov for research, CodeMonkey for coding), creating a revenue stream for the DAO treasury
3. **Ecosystem participation** — positioning #B4mad as a first-class participant in the agent economy, not a silo
4. **Validation of thesis** — proving that open standards beat walled gardens, which is a core #B4mad conviction

The question is not whether to pursue interoperability, but which protocol to adopt and how to integrate it.

---

## 2. The A2A Protocol Specification

### 2.1 Design Philosophy

A2A is built on four principles:

1. **Agentic** — agents are treated as autonomous entities, not deterministic APIs. They can negotiate, stream partial results, and report progress over extended interactions.
2. **Enterprise-ready** — authentication, authorization, and security are first-class concerns, not afterthoughts.
3. **Modular** — the protocol is layered. Implementations can adopt parts (discovery, task management, streaming) independently.
4. **Opaque execution** — agents don't need to share their internal architecture, model choice, or reasoning process. They expose capabilities, not implementations.

### 2.2 Core Concepts

#### Agent Card

The discovery primitive. An Agent Card is a JSON document (served at `/.well-known/agent.json`) that describes an agent's identity, capabilities, authentication requirements, and endpoint URL. It is the DNS+TLS certificate equivalent for the agent world.

**Structure:**
```json
{
  "name": "Romanov Research Agent",
  "description": "Deep research, literature review, position papers",
  "url": "https://agents.b4mad.net/romanov",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": true
  },
  "authentication": {
    "schemes": ["Bearer"],
    "credentials": "OAuth2 token from b4mad.net"
  },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["text/plain", "text/markdown"],
  "skills": [
    {
      "id": "research-paper",
      "name": "Research Paper",
      "description": "Produce a structured research paper on a given topic",
      "tags": ["research", "analysis", "writing"],
      "examples": ["Write a position paper on DAO governance frameworks"]
    }
  ]
}
```

**Key design decisions:**
- Skills are declarative, not executable — they describe what the agent *can do*, not how it does it
- Authentication is required but scheme-flexible (API keys, OAuth2, mTLS)
- Input/output modes use MIME types, enabling structured data exchange
- The `capabilities` object allows progressive feature adoption

#### Task Lifecycle

A2A models all interactions as **Tasks** with a defined state machine:

```
submitted → working → [input-required] → completed | failed | canceled
```

States:
- **submitted** — task received, not yet started
- **working** — agent is actively processing (may send streaming updates)
- **input-required** — agent needs additional information from the caller (multi-turn)
- **completed** — task finished successfully, artifacts available
- **failed** — task could not be completed
- **canceled** — task was canceled by the caller

This state machine is richer than a simple request/response. The `input-required` state enables negotiation: an agent can ask clarifying questions before proceeding, mimicking human collaboration patterns.

#### Messages and Parts

Communication uses **Messages** containing **Parts** (text, files, structured data). Each message has a role (`user` or `agent`) and can contain multiple parts with different MIME types.

```json
{
  "role": "agent",
  "parts": [
    {"type": "text", "text": "Here is the research paper."},
    {"type": "file", "file": {"name": "paper.md", "mimeType": "text/markdown", "bytes": "<base64>"}}
  ]
}
```

This multi-part model supports rich exchanges: an agent can return a text summary alongside a file attachment, structured data, or even references to external resources.

#### Artifacts

Task outputs are formalized as **Artifacts** — named, typed outputs that persist after task completion. An artifact might be a generated document, a code file, a dataset, or structured results.

#### Streaming (SSE)

A2A supports Server-Sent Events (SSE) for real-time streaming of task progress, partial results, and state changes. This is critical for long-running tasks where the caller needs visibility into progress.

### 2.3 Transport and Wire Format

- **Transport:** HTTP/HTTPS (JSON-RPC 2.0)
- **Methods:**
  - `tasks/send` — create or update a task (synchronous response)
  - `tasks/sendSubscribe` — create a task with SSE streaming
  - `tasks/get` — retrieve task status and artifacts
  - `tasks/cancel` — cancel a running task
  - `tasks/pushNotification/set` — register a webhook for task updates
  - `tasks/pushNotification/get` — retrieve push notification config
  - `tasks/resubscribe` — reconnect SSE after disconnection
- **Error handling:** Standard JSON-RPC 2.0 error codes plus A2A-specific codes (task not found, incompatible content type, push notification not supported)

### 2.4 Authentication and Security

A2A mandates authentication but does not prescribe a single mechanism:

- **API keys** — simplest, suitable for trusted environments
- **OAuth 2.0** — recommended for cross-organization interactions
- **mTLS** — mutual TLS for high-security environments
- **Custom schemes** — the Agent Card declares supported auth schemes

The spec requires that Agent Cards accurately describe authentication requirements so clients can programmatically determine how to authenticate.

**Security observations:**
- No built-in rate limiting (left to implementation)
- No built-in payload encryption beyond TLS (sufficient for most cases)
- No built-in access control model (deployers define their own)
- Push notifications create a callback surface that needs careful security review

---

## 3. Landscape: Who's Implementing A2A

### 3.1 Google

Google released A2A alongside reference implementations in Python and JavaScript. Google's ADK (Agent Development Kit) includes A2A support. Google Cloud Vertex AI agents can act as both A2A servers and clients. Google positions A2A as the interoperability layer for its Agentspace platform.

### 3.2 Enterprise Adopters

A2A launched with over 50 technology partners, including:

- **Salesforce (Agentforce)** — CRM agents that collaborate with external agents via A2A
- **SAP (Joule)** — enterprise ERP agents with A2A interoperability
- **ServiceNow** — IT service management agents
- **Atlassian** — project management and knowledge agents
- **MongoDB, Neo4j, Elastic** — data platform agents
- **LangChain/LangGraph** — A2A integration in their agent framework
- **CrewAI** — multi-agent orchestration with A2A support
- **Cohere, AI21** — LLM provider agents with A2A endpoints

This broad early adoption signals that A2A has achieved critical mass for enterprise agent interoperability. The protocol is not an academic exercise — it's being deployed in production at scale.

### 3.3 Open Source Implementations

- **a2a-python** (Google) — reference server and client implementation
- **a2a-js** (Google) — JavaScript/TypeScript reference implementation
- **LangChain A2A adapter** — wraps LangGraph agents as A2A servers
- **CrewAI A2A bridge** — exposes CrewAI agents via A2A
- Various community implementations in Go, Rust, and Java

### 3.4 Notable Absences

- **Anthropic** — has not announced A2A support, focusing on MCP as their interoperability standard
- **OpenAI** — no public A2A commitment, though their Agents SDK could be wrapped
- **Apple** — no agent interoperability standard announced
- **Microsoft/Azure** — Azure AI Foundry has A2A support announced, but Microsoft's primary investment appears to be in their own Copilot ecosystem

---

## 4. A2A vs. MCP: Complementary, Not Competing

### 4.1 Anthropic's Model Context Protocol (MCP)

MCP, released by Anthropic in November 2024, defines a standard for connecting AI models to external data sources and tools. Key characteristics:

- **Tool-oriented** — MCP exposes tools (functions) that models can call
- **Context-oriented** — MCP provides resources (data) that enrich model context
- **Client-server** — the AI model is the client; tools/data sources are servers
- **Local-first** — originally designed for local tool integration, though remote servers are supported
- **Synchronous** — function calls return results; no built-in task lifecycle or streaming

### 4.2 Fundamental Difference

| Dimension | MCP | A2A |
|---|---|---|
| **Metaphor** | Agent uses a tool | Agent talks to another agent |
| **Interaction** | Function call → result | Task submission → lifecycle → artifacts |
| **Autonomy** | Tool is passive (responds to calls) | Agent is active (may negotiate, ask questions) |
| **State** | Stateless (per-call) | Stateful (task persists across interactions) |
| **Discovery** | Tool schemas in server manifest | Agent Cards at well-known URLs |
| **Streaming** | Not native (polling or SSE extensions) | Native SSE support |
| **Multi-turn** | Not supported | Native (input-required state) |
| **Authentication** | Basic (mostly local) | Enterprise-grade (OAuth2, mTLS) |
| **Adoption** | Broad (Cursor, Windsurf, Claude Desktop, etc.) | Growing (50+ enterprise partners) |

### 4.3 Why They're Complementary

The distinction is architectural:

- **MCP** answers: "How does an agent access external tools and data?" — connecting an agent to a database, a code execution environment, a file system, or an API.
- **A2A** answers: "How does an agent delegate work to another agent?" — asking a specialized agent to perform a complex, potentially multi-step task.

An agent can use MCP to access tools while simultaneously using A2A to collaborate with other agents. They operate at different layers of the agent architecture:

```
┌─────────────────────────┐
│     Agent Application    │
├─────────────┬───────────┤
│  MCP Client │ A2A Client│
│ (tool use)  │ (delegate)│
├─────────────┴───────────┤
│    LLM / Reasoning      │
└─────────────────────────┘
```

For #B4mad, this means:
- **MCP** for connecting agents to local tools (file system, git, beads CLI, databases)
- **A2A** for connecting agents to external agents (hiring a security auditor, offering research services)

### 4.4 Other Interoperability Standards

| Standard | Focus | Status | Relevance |
|---|---|---|---|
| **OpenAPI/Swagger** | REST API description | Mature, universal | Tools, not agents |
| **AsyncAPI** | Event-driven API description | Growing | Useful for A2A streaming |
| **FIPA ACL** | Agent communication (academic) | Legacy | A2A supersedes |
| **KQML** | Knowledge query language | Legacy | Historical interest only |
| **AutoGen** (Microsoft) | Multi-agent framework | Active | Internal framework, not a protocol |
| **Swarm** (OpenAI) | Agent handoff | Experimental | Lightweight, no discovery |

None of these compete directly with A2A for cross-organizational agent interoperability. A2A occupies a unique and needed niche.

---

## 5. OpenClaw Integration Architecture

### 5.1 Current OpenClaw Agent Architecture

OpenClaw agents currently operate through:
- **Sessions** — isolated conversation contexts with LLM backends
- **Sub-agents** — spawned via `sessions_spawn` for parallel task execution
- **Tools** — function calls (exec, browser, message, etc.) available within sessions
- **Beads** — persistent task coordination across agents and sessions
- **MCP** — tool integration (already supported by OpenClaw)

The gap: no mechanism for external agents to discover or interact with #B4mad agents, and no mechanism for #B4mad agents to discover or hire external agents.

### 5.2 Proposed A2A Integration

#### Layer 1: Agent Card Publication (Discovery)

**Priority: Highest. Effort: Low.**

Publish Agent Cards at `https://agents.b4mad.net/.well-known/agent.json` describing each publicly available agent. This requires only a static JSON file served via HTTP — no protocol implementation needed.

Start with the fleet-level identity:
```json
{
  "name": "Brenner Axiom",
  "description": "#B4mad Industries AI agent fleet — research, coding, publishing, DevOps",
  "url": "https://agents.b4mad.net/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "stateTransitionHistory": true
  },
  "authentication": {
    "schemes": ["Bearer"]
  },
  "skills": [
    {
      "id": "research",
      "name": "Research Paper",
      "description": "Produce structured research papers, literature reviews, and technology evaluations",
      "tags": ["research", "analysis", "survey", "evaluation"]
    },
    {
      "id": "coding",
      "name": "Code Development",
      "description": "Write, review, and debug code across multiple languages",
      "tags": ["code", "development", "debugging", "refactoring"]
    },
    {
      "id": "devops",
      "name": "Platform Operations",
      "description": "Infrastructure management, CI/CD, monitoring, cluster operations",
      "tags": ["devops", "infrastructure", "kubernetes", "openshift"]
    }
  ]
}
```

#### Layer 2: A2A Server (Receiving Tasks)

**Priority: High. Effort: Medium.**

Implement an HTTP endpoint that handles the A2A JSON-RPC methods. Architecture:

```
External Agent → HTTPS → A2A Server → OpenClaw Session
                          ↓
                     Auth middleware
                          ↓
                     Task → Bead mapping
                          ↓
                     sessions_spawn (isolated agent)
                          ↓
                     SSE stream ← session output
                          ↓
                     Artifacts ← completed work
```

Key design decisions:
- **Map A2A tasks to beads** — every incoming task creates a bead, ensuring traceability
- **Use `sessions_spawn`** — each A2A task runs in an isolated session, preventing cross-contamination
- **Stream via SSE** — connect the session output to an SSE stream for the calling agent
- **Auth via OAuth2** — issue bearer tokens tied to known external agents

#### Layer 3: A2A Client (Sending Tasks)

**Priority: Medium. Effort: Medium.**

Enable #B4mad agents to discover and hire external agents. This requires:

1. **Agent discovery** — resolve Agent Cards from URLs or a registry
2. **Capability matching** — given a task description, find agents with matching skills
3. **Task submission** — send tasks to external agents and track their lifecycle
4. **Result integration** — pull artifacts from completed tasks into the local workflow

Implementation as an OpenClaw skill or tool:
```
Agent → "I need a security audit of this code" 
      → A2A client discovers security-audit agents
      → Selects best match based on Agent Card
      → Submits task via tasks/sendSubscribe
      → Monitors SSE stream for progress
      → Retrieves artifacts on completion
      → Integrates results into bead
```

#### Layer 4: DAO-Integrated Payments (Future)

Combine A2A with x402 (Coinbase's payment protocol) for paid agent services:
- External agents pay B4MAD tokens for research or coding tasks
- #B4mad agents pay external agents for specialized services
- All payments governed by the DAO treasury via proposal/vote

This is the full vision: a marketplace of agents that discover each other via A2A, collaborate via tasks, and settle via on-chain payments.

### 5.3 Security Considerations

A2A introduces new attack surfaces:

1. **Agent impersonation** — a malicious actor publishes a fake Agent Card claiming to be a trusted agent. Mitigation: verify Agent Card provenance via TLS certificates, DNS ownership, or on-chain identity (ERC-8004).
2. **Task injection** — malicious tasks contain prompt injection payloads. Mitigation: sanitize incoming task descriptions, run tasks in sandboxed sessions with restricted tool access.
3. **Data exfiltration** — an external agent's task is designed to extract private data from agent memory. Mitigation: A2A sessions have no access to main session memory or other agents' contexts.
4. **Callback attacks** — push notification URLs point to internal services. Mitigation: validate callback URLs against allowlists, no private IP addresses.
5. **Resource exhaustion** — flood of tasks consuming compute. Mitigation: rate limiting, authentication requirements, per-agent quotas.

#B4mad's security-first architecture (tool allowlists, sandboxed sessions, audit logging) provides a strong foundation. The key addition needed is an authentication and authorization layer for the A2A endpoint.

---

## 6. Implementation Roadmap

### Phase 1: Discovery (Week 1-2)
- Publish Agent Cards for the #B4mad fleet
- Set up `agents.b4mad.net` with static Agent Card serving
- Register in any emerging A2A agent directories
- **Deliverable:** External agents can discover #B4mad agents

### Phase 2: A2A Server (Week 3-6)
- Implement JSON-RPC 2.0 endpoint for A2A methods
- Task → Bead → Session pipeline
- SSE streaming for task progress
- OAuth2 authentication
- **Deliverable:** External agents can submit tasks to #B4mad agents

### Phase 3: A2A Client (Week 7-10)
- Agent Card resolution and caching
- Capability-based agent discovery
- Task submission and tracking
- OpenClaw tool/skill for A2A client operations
- **Deliverable:** #B4mad agents can hire external agents

### Phase 4: Payment Integration (Week 11+)
- x402 integration for paid services
- DAO treasury approval flow for outgoing payments
- Revenue tracking for incoming payments
- **Deliverable:** Agent economy participation

---

## 7. Recommendations

### 7.1 Adopt A2A as the Primary Agent Interoperability Protocol

A2A is the right choice for #B4mad because:
- It's the only protocol designed for agent-to-agent (not agent-to-tool) communication
- Enterprise adoption is strong and growing
- It complements (not replaces) MCP, which #B4mad already uses
- Google's backing provides long-term viability
- The spec is open and implementation-agnostic

### 7.2 Start with Discovery, Not Implementation

Publishing Agent Cards is zero-cost and immediately positions #B4mad in the A2A ecosystem. Don't wait for full protocol implementation to become discoverable.

### 7.3 Map A2A Tasks to Beads

This is the critical architectural insight. The bead system already provides task lifecycle management, ownership tracking, and audit trails. A2A tasks are semantically identical to beads. The mapping should be 1:1.

### 7.4 Security First, Always

Every A2A interaction must be authenticated, authorized, logged, and sandboxed. No anonymous access. No shared memory between A2A tasks and internal operations. Full audit trail. This is non-negotiable and consistent with #B4mad's security-first thesis.

### 7.5 Don't Build MCP vs. A2A — Build MCP + A2A

The two protocols serve different purposes. MCP for tools, A2A for agents. Both are needed. The agent architecture should cleanly separate these layers.

### 7.6 Consider Agent Identity (ERC-8004 + ENS)

A2A Agent Cards are ephemeral — served from a URL that could change. On-chain agent identity (via ERC-8004 and ENS) provides persistent, verifiable identity that complements A2A discovery. The ENS name resolves to the Agent Card URL; the ERC-8004 NFT attests to the agent's identity and reputation. This bridges Web2 discovery (Agent Cards) with Web3 trust (on-chain identity).

---

## 8. Conclusion

A2A fills a genuine gap in the agent ecosystem: standardized, authenticated, stateful communication between autonomous agents across organizational boundaries. It is not competing with MCP — it operates at a different layer. For #B4mad, A2A adoption is strategically essential: it transforms the agent fleet from an isolated system into an interoperable participant in the multi-agent economy.

The implementation path is clear and incremental. Start by publishing Agent Cards (zero cost, immediate visibility). Build the A2A server to accept external tasks (maps cleanly to existing bead/session architecture). Add client capabilities to hire external agents. Eventually, integrate on-chain payments for a full agent marketplace.

The organizations that embrace agent interoperability early will compound capabilities faster than those that remain siloed. A2A is the most credible standard for achieving this. #B4mad should adopt it now.

---

## References

- Google, "Agent2Agent Protocol (A2A) Specification," 2025. https://google.github.io/A2A/
- Google, "A2A Python Reference Implementation," 2025. https://github.com/google/A2A
- Anthropic, "Model Context Protocol (MCP) Specification," 2024. https://modelcontextprotocol.io/
- Coinbase, "x402: HTTP-Native Payments Protocol," 2025.
- EIP-8004, "Trustless Agent Identity," Ethereum Improvement Proposals, 2025.
- LangChain, "A2A Integration Guide," 2025. https://docs.langchain.com/
- CrewAI, "Agent Interoperability with A2A," 2025. https://docs.crewai.com/
- Google Cloud, "Agent Development Kit (ADK)," 2025. https://cloud.google.com/adk

---

*This paper reflects the A2A specification and ecosystem as of February 2026. The protocol is evolving rapidly; implementations should track the latest spec.*