Support A2A agents as a portable plugin component

[wskr00]

Agent Plugins already provides a portable way to package Skills and MCP servers. I'm wondering if it would make sense to extend the same approach to remote A2A agents.

The use case is fairly straightforward: say a plugin includes a Skill, an MCP server, and a remote agent that handles a particular kind of task. If the host already supports A2A, it should ideally be able to discover that agent from the plugin without requiring a separate, host-specific configuration.

There's already an official A2A Agent Plugins repository that provides a Skill for interacting with A2A agents through the CLI. That works, but it's a different integration model. The host is following instructions to invoke an external tool rather than discovering an A2A agent as a component it can interact with directly.

Possible approach

One option would be an optional a2a.json at the plugin root, similar to how mcp.json works today.

Something along these lines:

{
  "$schema": "https://agent-plugins.org/schemas/X.Y.Z/a2a.schema.json",
  "agents": {
    "researcher": {
      "agentCardUrl": "https://research.example.com/.well-known/agent-card.json"
    },
    "reviewer": {
      "agentCardUrl": "https://review.example.com/.well-known/agent-card.json"
    },
    "data-analyst": {
      "agentCardUrl": "https://analytics.example.com/agents/analyst/card"
    }
  }
}

This is just a sketch of the configuration, not a proposed final schema. The actual format would follow the spec's versioned $schema convention.

I think the configuration should be limited to referencing existing Agent Cards rather than introducing another way to describe agents.

A2A already defines discovery, supported interfaces, capabilities, authentication requirements, messaging, and task lifecycle. An A2A-capable host could fetch the Agent Card and use that information to establish communication, following the protocol's existing rules.

Agent Plugins would only need to standardize how those references are packaged and discovered.

I'd also expect this to follow the existing component-loading rules: clients without A2A support could ignore the component, and a failure to load one agent shouldn't affect other agents, Skills, or MCP servers. Credentials and authorization decisions would remain with the host, not the plugin configuration.

Scope

I noticed the discussions around portable subagents and agent profiles, but I think this is a separate concern.

Those proposals focus on defining agents that a host can load or execute. Here, the agent already exists and runs independently. The plugin would only provide a portable reference to it.

I'm not suggesting that Agent Plugins define delegation behavior, orchestration, or any additional A2A protocol semantics.

Questions

The main question is whether this belongs in the portable specification at all, or whether it would be better handled through client-specific extensions until native A2A support becomes more common.

I'd also be interested in hearing from client implementers: if your host already supports A2A, would a declarative component like this be useful? And would referencing Agent Card URLs be enough, or are there practical cases where the plugin would need to bundle the Agent Card itself?

If there's interest, I think a small interoperability example across two A2A-capable clients would be a good next step before working on a formal schema.

References:

• Agent Plugins Specification
• A2A Protocol v1.0.1
• Official A2A Agent Plugins