A2A protocol tutorial: agents handing work to agents

The direct answer

MCP connects an AI host to tools and context; A2A is for communication and task exchange between agents; ACP is another agent communication protocol whose stewardship has moved into the broader A2A ecosystem. Choose the protocol by the boundary you need, not by the label on the product.

For a2a protocol tutorial, choose one question that a reviewer can answer from the record. Name the tool or source, the exact action, and the expected output before doing the work. This makes it easier to see whether the result actually answers the question or merely sounds plausible.

A practical way to apply this

1. Write the user's intended outcome in one sentence.
2. Identify which source, MCP tool, platform log, or human review can answer the question.
3. Run the smallest safe action and preserve its returned status, timestamp, and receipt link.
4. Check the receipt independently and label any evidence that is missing or outside the captured boundary.

A disciplined review separates the request, the tool execution, the saved result, and any later outcome. Ask what the system actually observed, then inspect the public receipt and its verifier. If the work changed another service, query that service directly or follow its confirmation reference. If that evidence is absent, report the outcome as unknown rather than filling the gap with an assumption.

A concrete example

A real example is this public read-only BTC lookup receipt: https://zambo.dev/run/83ae4fd7-b9f8-497c-b842-72381c8ee6a8. Its verifier is https://zambo.dev/api/v2/receipt/83ae4fd7-b9f8-497c-b842-72381c8ee6a8/verify. The example shows one observed tool result; it is not evidence about a2a protocol tutorial in your own system.

For a work-specific review, replace the sample with the receipt generated by your own call. Match the tool name and receipt ID exactly. If the output is a proposal, a blocked action, or an unavailable response, retain that state instead of describing it as completed work.

What the record can and cannot tell you

A client-to-tool protocol and an agent-to-agent protocol can coexist. An agent may use MCP to call a service, then use A2A to ask another agent to continue the work. The handoff should carry a bounded task summary and receipt links, not assume the receiving agent saw the source chat.

A checkable receipt records what the connected execution service saved. It does not establish that a model's complete answer is accurate, that every possible input was tested, or that an outside service changed state. When an outside effect matters, look for a confirmation from the system that owns that state, such as a read-back, callback, or provider reference.

For sensitive work, publish only the fields needed for review. Keep access tokens, private credentials, customer data, and unrelated chat context out of a public handoff. Explain what the receipt covers and what remains outside its scope.

Review checklist

• Does the record identify the specific request and tool?
• Does the receipt ID match the result being discussed?
• Can a reviewer reach the verifier without the original chat?
• Are failures, retries, and pending steps represented honestly?
• Is outside confirmation linked to its actual source?
• Are private values excluded from the public copy?

Use this checklist for a2a protocol tutorial: agents handing work to agents and save only the evidence relevant to the decision. A short, well-scoped record is easier to review than a large transcript with no clear boundary.