What Are A2A Agents?
A2A (Agent-to-Agent) is an open protocol for one program to discover and run another program's AI agent over HTTP. MCPBundles exposes every configured agent as an A2A agent — a runnable assistant with a public Agent Card, a unique slug, and a standard task lifecycle.
If you use MCP servers to give AI tools, A2A agents give AI (and other software) coworkers: assistants that follow your instructions, call your MCP tools on a schedule or on demand, and return structured results.
How MCPBundles maps to A2A
Every A2A agent in MCPBundles is backed by one row in your workspace:
| What you configure | What A2A exposes |
|---|---|
| Display name, description, skills | Fields on the Agent Card |
agents.md instructions | Agent identity and behavior |
heartbeat.md checklist | Work the agent runs each time |
| MCP Hub or a specific MCP server | Tools the agent can call |
| Heartbeat interval | Scheduled runs (cron-style) |
| Webhook URL | Event-driven runs from Zapier, Stripe, GitHub, etc. |
When the agent is ready, MCPBundles publishes it at a stable slug. Other clients discover the Agent Card and start work with SendMessage — the A2A operation that creates a task, runs your checklist, and returns a reply.
Human-readable agent pages live at https://www.mcpbundles.com/agents/{slug}. The A2A protocol endpoint (/a2a/{slug}/) is for client code and SDKs — you do not need to paste it into Zapier or email copy.
Agent Card and slug
The Agent Card is a JSON document (similar in spirit to an OpenAPI spec for an agent) that describes:
- Name and description — what the agent does
- Skills — optional capability tags from your skill definitions
- Security — whether callers need OAuth, an API key, or can run anonymously (OPEN visibility)
- Interfaces — where to send A2A messages
Cards are cached at /.well-known/agent-card.json under the agent slug. Registries and SDKs fetch the card before sending work.
Task lifecycle (SendMessage)
A typical programmatic call:
- Client fetches the Agent Card (or already knows the slug)
- Client sends SendMessage with user text or a trigger payload
- MCPBundles returns a task (submitted → working → completed / failed)
- Client polls or streams until the task finishes and reads the agent's reply
The same execution path powers scheduled heartbeats, webhook deliveries, Hub trigger_agent_run, and external SDK callers — one door, one task model.
Two ways to reach an agent
MCPBundles deliberately splits chat UX from programmatic invocation:
| Surface | Best for | Protocol |
|---|---|---|
| Studio | Interactive chat with a human — streaming tokens, tool activity, edits | AGUI (CopilotKit) |
| Everything else | Schedules, webhooks, Hub tools, external orchestrators, other agents | A2A |
Studio is for conversation. A2A is for "run this checklist and give me a task back." Both use the same underlying agent configuration; they are different transports.
Visibility and who pays
Each A2A agent has an visibility setting:
| Visibility | Who can discover the Card | Who can run it | Billing |
|---|---|---|---|
| WORKSPACE | Workspace members | Signed-in workspace members | Your workspace |
| PUBLIC | Anyone | Authenticated MCPBundles callers | Caller (or catalog rules) |
| OPEN | Anyone | Anyone, including anonymous browsers | Publisher workspace |
Most workspace-authored agents start as WORKSPACE. Catalog MCP servers can also publish global A2A agents for discovery.
Common triggers
- Schedule — heartbeat interval (every hour, daily, etc.)
- Manual Run — click Run on the agent page or call Hub
trigger_agent_run - Webhook — HTTP POST from Stripe, HubSpot, GitHub, Zapier, Make, n8n
- External A2A client — any SDK or agent that speaks A2A 1.0
What to read next
- Why MCPBundles Adopted the A2A Protocol — why we ship A2A agents and how the pieces fit together
- Creating A2A Agents — step-by-step setup in the dashboard
- Webhook Triggers — wake an agent from external events
- Understanding Workspaces — how team sharing applies to A2A agents
- MCPBundles Hub — manage agents programmatically from the Hub MCP server