Agent-to-Agent (A2A) communication distinguishes a message from a trackable task. That distinction matters when an agent asks another service to produce a report, wait for authorization or return multiple artifacts. A caller must own the task’s authorization and completion criteria instead of trusting any text that claims the remote work is done.
Service discovery and identification
An A2A server advertises identity and supported capabilities through an Agent Card. The card provides routing and authentication hints, not carte blanche access. A client should verify the server hostname, TLS identity, advertised methods and expected skill against an approved registry. It should also bind the remote task to the local actor and tenant, so a successful call cannot retrieve someone else’s task history merely because the identifier is known.
Stateful tasks versus quick answers
A stateless message is appropriate for an immediate response with no need to resume work. A task is appropriate when the remote agent performs a longer operation, emits progress, creates artifacts or pauses for input. Model interruption and terminal states explicitly. For example, an authorized research request may move through working, input-required and completed; the caller should not treat input-required or an artifact-progress event as a finished deliverable. Verify the final artifact against the original question.
Worked example: division of labor
A procurement assistant requests a vendor-risk report from a specialist agent. It supplies a scoped vendor identifier and target deadline but not a broad credential. The specialist returns a task ID, status and evidence references. The requester stores a mapping between its local job and that task, waits through a permitted channel, and confirms the report actually belongs to the requested vendor. Any request to contact the supplier or modify an approved-vendor status becomes a new gated action.
Security and error recovery
Authenticate both the caller and server, limit task visibility to the owning principal, and bind push notifications to the correct expected task. Treat callback URLs and artifact URLs as untrusted until validated. Duplicated notifications, delayed events and out-of-order updates should be handled idempotently. If the task cannot be found, do not initiate a second high-impact action until the remote system confirms whether the first action executed.
When this architecture is unnecessary
If an application already knows the narrow API needed to retrieve a value, a direct function call can be simpler than remote agent delegation. A2A adds discovery, lifecycle, artifacts and a broader trust surface. The April 2025 announcement was not proof that every partner integration shipped at launch, and specification capabilities are not a guarantee of any particular platform tier or regional service deployment.
Choose an appropriate delegation unit
Use an A2A task when the receiver must manage its own work over time or deliver several artifacts; use a simple API for an immediate deterministic lookup. Budget for an extra security perimeter and the risk that two agents interpret a task differently. Design the task description with specific permissible operations, evidence requirements and an outcome state so the receiver cannot casually expand the work to sending emails or changing account data.
Production acceptance and review test
For acceptance testing, create a remote task, interrupt the client connection, resume status polling and deliberately deliver notifications twice. Assert that no second side effect occurs and the authenticated requestor alone can access the task. The final acceptance check should inspect the returned artifact, its source provenance and any requested authorization steps; messages from the remote agent are never themselves proof of authorization.
Scope, version and availability
Features documented by a current vendor page are not assumed to have existed in earlier releases. Where a historical launch date is provided, it is supported by a dated first-party publication. Exact subscription tier, market availability, quotas, API billing, licensing permissions and deployment regions are not asserted without a directly applicable record. This is researched editorial guidance rather than a claim of independent hands-on testing, deployed operation or statutory certification.
Sources and Further Reading
- A2A Protocol Project — A2A specification (source reviewed 2026-10-25)
- Google — Announcing the Agent2Agent Protocol (source reviewed 2026-10-25)