Use A2A for an Independent Executor
A2A is built on an assumption that sets it apart from everything we've done so far: a remote agent may be opaque. The client knows the declared skills, data modes, and protocol operations, but does not receive its prompt, tools, memory, or internal plan. The contract is built around the goal and the result, not around a function call.
To feel the difference, it helps to put three things side by side. An RPC service asks "run a function": the method and the exact shape of the result are known, the server chooses no visible path. An MCP server gives a capability: the host orchestrates the calls itself and usually owns the model loop. An A2A agent gets "solve the task": the executor plans on its own, may work long, request input, and produce several artifacts. This is an ascending ladder of independence - and A2A stands at its top.
So an A2A agent's contract is stated in product terms, not technical ones.
goal: assess the readiness of a known release snapshot
input: text/plain message with service@semver
output: text/markdown + application/json
states: submitted → working → completed
interrupt: input_required if the release reference is missing
terminal errors: failed, rejected, canceled
internal tools/memory/model: not revealed to the clientWhy is opaque a feature rather than a flaw? Because the team that owns the agent can change the model, the MCP servers, the prompts, and the workflow while keeping the Agent Card and the semantic contract. The client integrates with the task, not with the internal tool graph - and so it doesn't break with every refactor of the executor. That's exactly what makes agents genuinely independent services.
Opaque doesn't mean uncontrolled. You still need identity, authorization, declared capabilities, trace context, task retention, an SLO, and an agreement about artifacts. The implementation is hidden, not the responsibility.
The first thing such an agent publishes and the first thing the client reads is its Agent Card. Let's start there.