The original A2A experiment built a travel-planning workflow from separate services. One agent fetched weather information, another searched for activities, and a local language model turned the gathered material into a readable plan.
The implementation used the community python-a2a library. Its purpose was to make agent communication tangible through a small example that could be run and inspected, rather than hide every step inside a single prompt.
Separate discovery from orchestration
An Agent Card describes a service’s capabilities and connection information. A client still needs to decide which service to call, send an appropriate request, and handle the result. Publishing a card does not automatically create a reliable planning workflow.
The article also introduced task states and messages. These give the caller a way to represent work in progress, completion, failure, or a request for more input. The exact schema and discovery path belong to the protocol version used by the implementation.
Follow one trip request
The example’s coordinator queried the weather service, used the result to shape a search for indoor or outdoor activities, and sent the gathered information to the local model for summarization.
Destination → weather agent
Weather context + destination → search agent
Weather + search results → local model → proposed itineraryWeather and search used OpenWeather and Brave APIs. Those calls were remote; local summarization did not make the whole workflow offline. The weather endpoint also needs to match the question: current conditions cannot establish the forecast for a future holiday.
Make partial failure understandable
A useful planner should distinguish a missing weather response from a completed search with no relevant results. Preserve service errors and timestamps rather than letting the final model present incomplete data as a fully supported itinerary.
The historical weather example logged request details. When adapting it, redact credentials from URLs and logs. Authentication support in a protocol does not configure or secure the deployed services on its own.
Keep tools and agents in perspective
MCP and A2A address different integration boundaries: accessing exposed capabilities and communicating with agent services. Neither removes the application’s responsibility to coordinate work or validate results.
The author’s tutorial code preserves the example. Credit also belongs to python-a2a and its contributors. This is an edited account of the 2025 implementation, not a claim of conformance with a newer protocol release.