feat: integrate A2A (Agent2Agent) protocol

[weiyong1024]

Motivation

ClawFleet's whole story is running many isolated agents on one box, but today the agents only talk to humans (via Discord/Telegram/Slack/Lark) — there's no standard, framework-neutral way for them to talk to each other, or to agents running outside the fleet.

A2A (Agent2Agent) is an open protocol (originally from Google, now under the Linux Foundation, currently at v1.2, with 150+ orgs in production) that defines exactly this layer: agents advertise capabilities via an Agent Card, and exchange Tasks / Messages with a well-defined lifecycle. It's intentionally complementary to MCP — MCP is agent ↔ tools, A2A is agent ↔ agent.

For ClawFleet specifically:

• Every instance is already a long-running addressable agent with its own SOUL, channels, and skills — a natural A2A endpoint.
• Both runtimes we support (OpenClaw, Hermes) would benefit from a shared inter-agent surface; today inter-instance collaboration is ad-hoc per runtime.
• Pitching ClawFleet as "an A2A-native fleet host" sharpens the positioning vs. UI-wrapper competitors that don't own the runtime.

Possible scope (to be refined)

• Per-instance A2A endpoint — each instance exposes an Agent Card (capabilities, skills, channels it speaks on) plus the standard task/message endpoints, behind the existing port allocator.
• Dashboard surface — show each instance's Agent Card URL on the card, with a "Test" affordance similar to the channel/model validation flow; optionally a "talk to this agent" panel that fires a sample A2A message and renders the streamed response.
• Cross-runtime parity — define one A2A surface that both OpenClaw and Hermes runtimes implement (or shim), so a remote A2A client can't tell which runtime it's talking to.
• Discovery — fleet-level Agent Card index (e.g. `/.well-known/a2a/agents`) so external A2A clients can enumerate the fleet's agents.

Open questions

• Adapter vs. native — does the agent runtime emit A2A natively (preferred upstream change in OpenClaw/Hermes), or does ClawFleet ship an in-container adapter that bridges A2A ↔ the agent's existing API?
• Auth model — A2A 1.2 supports signed Agent Cards. Do we want to default to signed Cards even on `localhost`-only fleets, or only when the dashboard is exposed remotely?
• Channel parity — is "A2A" a peer of Discord/Slack/etc. in our channel abstraction (one more transport), or a separate first-class concept?
• MCP coexistence — once an instance speaks A2A, do we also expose a per-instance MCP server for tool access? They're complementary; worth deciding the order.

References

• Protocol site
• Specification
• GitHub: a2aproject/A2A
• Google announcement