Bidirectional streaming & improved stream semantics
The A2A protocol today only supports server-to-client streaming. A cluster of related gaps — around client-to-server streaming, first-class Message streaming, and semantic ambiguity between Message and Artifact — have accumulated in separate issues. This epic tracks them as a coherent unit.
Problem areas
1. No client-to-server (bidirectional) streaming
The current protocol is strictly unidirectional: the server streams to the client, but the client cannot stream input to the agent. Use cases like ASR (speech recognition), real-time audio/video, and mid-task steering require a long-lived duplex channel.
2. No first-class Message streaming
There is no way to stream a Message incrementally (token-by-token). The only streamable entity is Artifact, which is semantically wrong for conversational output. Implementors work around this by misusing Artifact or sending many small TaskStatusUpdateEvent messages, each of which is stored as a separate history entry.
3. Semantic confusion between Message and Artifact
The boundary between Message and Artifact is undefined in the spec. Both can carry user-facing content; only Artifact is streamable. Developers diverge on which to use for the same output, breaking interoperability and making conversation history reconstruction unreliable.
4. Streaming specification gaps
The spec for SendStreamingMessage references a "final completion indicator" that has no concrete definition, and the SubscribeToTask return type incorrectly includes Message as a possible variant.
In-flight work (context only)
The following open PRs are already proposing solutions in this space and should be considered as input to the design:
Child issues
| # |
Area |
Title |
| #656 |
Bidirectional |
Support for stream input |
| #822 |
Message streaming |
Message object for streaming |
| #1261 |
Message streaming |
Make Message streaming possible |
| #1313 |
Semantics |
Unify Message and Artifact to simplify streaming and semantics |
| #1386 |
Message streaming |
Add token-by-token message streaming |
| #1746 |
Spec clarity |
Clarify the outputs of SendStreamingMessage |
| #1299 |
Spec clarity |
SubscribeToTask return type should not include Message |
Bidirectional streaming & improved stream semantics
The A2A protocol today only supports server-to-client streaming. A cluster of related gaps — around client-to-server streaming, first-class
Messagestreaming, and semantic ambiguity betweenMessageandArtifact— have accumulated in separate issues. This epic tracks them as a coherent unit.Problem areas
1. No client-to-server (bidirectional) streaming
The current protocol is strictly unidirectional: the server streams to the client, but the client cannot stream input to the agent. Use cases like ASR (speech recognition), real-time audio/video, and mid-task steering require a long-lived duplex channel.
2. No first-class
MessagestreamingThere is no way to stream a
Messageincrementally (token-by-token). The only streamable entity isArtifact, which is semantically wrong for conversational output. Implementors work around this by misusingArtifactor sending many smallTaskStatusUpdateEventmessages, each of which is stored as a separate history entry.3. Semantic confusion between
MessageandArtifactThe boundary between
MessageandArtifactis undefined in the spec. Both can carry user-facing content; onlyArtifactis streamable. Developers diverge on which to use for the same output, breaking interoperability and making conversation history reconstruction unreliable.MessageandArtifactto simplify streaming and semantics #1313 — [Feat]: UnifyMessageandArtifactto simplify streaming and semantics4. Streaming specification gaps
The spec for
SendStreamingMessagereferences a "final completion indicator" that has no concrete definition, and theSubscribeToTaskreturn type incorrectly includesMessageas a possible variant.SendStreamingMessageSubscribeToTaskshould not include theMessagetypeIn-flight work (context only)
The following open PRs are already proposing solutions in this space and should be considered as input to the design:
SendLiveMessagebidi RPC, gRPC-only)Child issues
MessageandArtifactto simplify streaming and semanticsSendStreamingMessageSubscribeToTaskreturn type should not includeMessage