English
What problem does this solve?
A blocking call is fine for a task that finishes in under a second. It is a poor experience for anything that takes real reasoning time — the user just sees a spinner with no signal that anything is happening, and no way to know if the agent needs more information before it can continue. This walkthrough continues studying the open-source theailanguage/a2a_samples reference implementation.
How the mechanism works
The hand-rolled server code from earlier parts is replaced with Google's official A2A SDK, combined with LangChain and LangGraph to build a ReAct-style reasoning agent. A component called AgentExecutor is the bridge — it plugs the LangChain agent into the official A2A server's request lifecycle correctly, instead of reimplementing that lifecycle by hand.
As the agent works, it emits one of three states — working, input_required, or completed — and each state is pushed immediately into an event queue that streams to the client. If the agent is missing information, it can pause mid-task, ask the user a clarifying question through input_required, and resume once it gets an answer — a real multi-turn conversation instead of one shot per call.
Trade-offs and alternatives
The benefit is a client experience that mirrors what a good chat product should feel like: live progress instead of silence, and the ability to interrupt for clarification. The trade-off is more implementation surface — event queues, streaming transport, and state machine logic that a simple blocking call never had to deal with.
The alternative — client-side polling of a status endpoint — gets partway there but adds latency (you only find out about a state change on the next poll) and unnecessary request volume compared to a proper push-based stream.
Conclusion
Streaming is not a cosmetic upgrade. It's the difference between an agent that looks broken during a slow operation and one that visibly shows its work — and it's also the mechanism that makes real clarifying questions possible mid-task.