Quick answer: A2A can stream task progress and status over Server-Sent Events, which the desktop shows in the SSE viewer. The stream lets you watch the task move through states rather than poll blindly, and the final result is read when the task reaches a terminal state. Stopping the local view ends the stream, but it does not cancel the remote work, which still needs a CancelTask request.
Why streaming fits a long-running task
A task that takes time produces a poor experience when the only option is to wait and poll. The caller has no sense of progress, and a hung run looks identical to a slow one until a timeout decides. SSE changes that by pushing events as the task advances, so the status stays current without repeated requests.
The SSE viewer turns those events into a readable timeline of the task.
What the stream carries
| Element | What it tells you |
|---|---|
| Status events | The task's current state as it changes |
| Progress events | How the work is advancing |
| Artifacts | Outputs produced before the terminal state |
| Terminal event | The task completed, failed, or was cancelled |
The task moves through defined states, and the events preserve that order rather than collapsing it into a single final answer.
Take a task that processes a batch of records. The first event confirms the task started, progress events report the count as each batch completes, and a terminal event carries the summary when the work finishes. Watching the sequence, the caller can see the task advancing rather than guessing, and a stall where the count stops moving is visible long before a timeout. If the caller decides the work is no longer needed halfway through, closing the viewer leaves the batches running on the server, and a CancelTask request is the only step that stops them. The same events that make progress visible also make a hung run easy to spot, which is the practical reason to prefer the stream over a blind wait.
How to read the stream honestly
- Open the SSE viewer after the task is submitted.
- Read the events in order and note the state transitions.
- Distinguish progress from a terminal state.
- Read the final result or artifact when the task completes.
- Keep the stream separate from the question of cancellation.
A stream that stops producing events is not the same as a task that ended. The absence of an event can mean a quiet period or a hung run, and without a terminal event you should check the status rather than assume completion. Set an expected duration so a silent run gets investigated instead of left open.
The local and remote boundary
The viewer is a client of the stream, and the local Stop action ends what happens on the desktop, the connection and the displayed events. It does not send a cancellation to the remote agent, and the task can keep running and emitting on the server. To stop the work, send a CancelTask request and confirm the status, rather than assuming closing the viewer reached the agent.
This is the same boundary that keeps the desktop view from being mistaken for control over the remote process. The stream is a view into the task, not a handle that cancels it.
Powerduck keeps the SSE viewer and the separate cancellation path in the desktop, so progress and control stay distinct.
Frequently asked questions
Does SSE replace polling? It pushes status and progress as events, so you can watch the task without repeated polling, though you still wait for a terminal event.
What if the stream goes quiet? Without a terminal event, check the status rather than assuming completion, and set a duration threshold for investigation.
Does closing the viewer cancel the task? No. It ends the local stream, and remote work needs a CancelTask request.
The bottom line
SSE gives you a live, ordered view of an A2A task, streaming status, progress, and artifacts into the viewer until a terminal event arrives. Read the events in order, do not mistake a quiet stream for completion, and keep the viewer separate from cancellation. The local Stop ends the view rather than the remote work, which still needs a CancelTask request. The stream is a window into the task, not a control over it. Continue in the A2A guide.
Top comments (0)