A2A Protocol

An A2A service publishes an Agent Card describing its identity, endpoint, capabilities and access requirements. A client sends messages and may receive an immediate reply or a task that continues over time. Task state, streamed updates and artifacts distinguish progress from the final deliverable. The protocol is concerned with requesting work from another agent, whereas MCP primarily exposes tools and context to an AI application. Neither protocol supplies task-specific competence or a universal trust model. A client still needs to decide whether a remote agent is appropriate and whether returned outputs satisfy the requested contract.

The practitioner defines the agent's advertised capabilities, task inputs and artifact formats, then selects supported interaction mechanisms. Long-running tasks require handling cancellation, reconnection and status changes. Authentication should be verified separately from assertions in capability descriptions. Useful outputs include a tested client-server contract and lifecycle traces. Evaluation checks duplicate requests, lost connections and failures after partial work, ensuring that the client can distinguish an incomplete task from a completed answer and recover the associated artifacts.

Protocol conformance does not prove competence, privacy protection or faithful completion. Advertised skills may be too broad, and task states can be misused unless both sides agree on their meaning. Implementations can differ in optional features and protocol versions. Quality requires compatible lifecycle handling, verified access and inspection of actual outputs. Exchanging a task with another agent also crosses a trust boundary; returned text cannot grant additional authority or silently redefine the client's objective.