Skip to content

ADR-0023: A2A as the agent-to-agent interoperability surface

Decision

This page records a decision and its status. A Proposed decision is not binding; an Accepted decision is binding on the Factory until amended or superseded.

  • Status: Accepted 2026-10-09 by the product owner (decision D44)
  • Date: 2026-10-09
  • Deciders: Dmitry Khaymov (product owner); proposed by the 2026-10 design plan
  • Tags: a2a, agents, interoperability, protocols

Context

The target architecture names agent-to-agent discovery and contracts as later-stage concepts without a protocol. The Agent-to-Agent protocol (A2A) now provides an open contract for one agent to delegate a task to another: a discoverable agent card (capabilities, skills, authentication, endpoints), a task with a lifecycle (submitted, working, input required, completed, failed, cancelled), messages and artifacts, and streaming updates. Factory runs already have a persisted lifecycle (ADR-0014); partner agents, customer agent platforms and IDE agents need a way to call Factory agents and to be called, without bypassing Run Control.

Decision

  1. A2A is the interoperability surface for agent-to-agent calls across trust boundaries: between tenants' agent deployments, with partner agents, and with external agent platforms. Inside one runtime worker, delegation stays an in-process workflow step.
  2. Agent cards are projections of published releases. AgentCardService (BC-04) publishes a card per Published agent release: skills, input and output descriptors, authentication requirements, the task endpoint behind GW-01, and the release hash. Cards never expose Draft or InReview assets.
  3. A2A tasks map onto runs. An inbound A2A task becomes a run submitted through Run Control with the caller's workload identity and delegated scope; task states map to run states (submitted → Accepted, working → Running, input-required → WaitingForApproval, completed → Completed, failed → Failed, cancelled → Cancelled). An outbound call to a partner agent is a tool invocation of side-effect class external with its own receipt.
  4. Authentication is workload identity: callers present tokens issued by the Authorization Server (ADR-0101) or federated partner credentials mapped to a connection (BC-16); the delegated user scope travels with the task and is narrowed per step (ADR-0015).
  5. MCP stays the tool protocol (ADR-0022); A2A never replaces tool calls, and an A2A agent cannot call tools of the receiving tenant except through its own governed run.
  6. Discovery across organizations (agent catalogs, marketplaces) is assess / later on the technology radar.

Consequences

  • Positive: Factory agents become callable by customer and partner agent systems without new bespoke APIs; inbound work stays governed because every task is a run; the Factory's own agents can delegate to specialist partner agents under policy.
  • Negative: card publication, task mapping and partner connections are new design (AgentCardService, Integration platform); the A2A specification evolves and the Factory pins a version per release.
  • Neutral: the Studio shows A2A tasks as runs with an "external caller" origin.

Alternatives considered

Alternative Why not chosen
Expose Factory agents only as MCP tools Loses task lifecycle, streaming updates and input-required semantics; conflates tools and agents
Proprietary agent API No interoperability with customer agent platforms; duplicate of what A2A standardizes