W-20130488 add context to a2a protocol flow #545
Conversation
…to A2A protocol details for agents, improving clarity and providing additional context for users.
…a server" for improved clarity.
|
|
||
| == A2A Protocol | ||
|
|
||
| Agent networks use the A2A specification 0.3.0. Brokers use the A2A protocol to accept requests to reach other agents. |
There was a problem hiding this comment.
I would rephrase this entire statement. It's not the agent network that uses A2A, as the network also contain other components such as MCP servers and LLMs.
It's also not just the brokers that use A2A, all the agents (broker or not) must be A2A enabled not only to be orchestrated but also to be observed and governed
|
|
||
| === Context and Task ID Scoping in Agent Networks | ||
|
|
||
| In the A2A protocol, the server (the agent receiving the request) always generates the `contextId` and `taskId`. These IDs define the state and scope of a specific conversation between two agents. |
There was a problem hiding this comment.
In the A2A protocol, the server (the agent receiving the request) always generates the
contextIdandtaskId.
Not true. Those IDs are always generated by the server, but the server is not required to always generate them. Our brokers DO always generate them, but that's a property of the broker, not the A2A protocol
|
|
||
| In the A2A protocol, the server (the agent receiving the request) always generates the `contextId` and `taskId`. These IDs define the state and scope of a specific conversation between two agents. | ||
|
|
||
| When an agent acts as a broker, IDs do not pass through from the upstream client. Each "hop" in a multi-agent network establishes its own unique session. |
There was a problem hiding this comment.
When an agent acts as a broker, IDs do not pass through from the upstream client.
Several things here:
- I get what you're trying to say here, but I don't think this will be clear to customers. Maybe an example between 3 agents with a picture would be helpful.
- This is not true just for brokers but any three-party A2A communication.
- We should unifiy the language. The terms conversation, context and session are being used interchengeably and they not necessarilly represent the same thing (e.g: session could be understood as authenticated session). I would stick to the proper A2A term (contextId) or at most conversation
| === Non-Supported Features | ||
|
|
||
| Agent network doesn't support the following features in the A2A protocol. | ||
| * Task History |
|
|
||
| Agent network doesn't support the following features in the A2A protocol. | ||
| * Task History | ||
| * Push Notifications Config |
|
|
||
| Consider a network with a client and two agents (A and B). | ||
|
|
||
| * The IDs used between the client and Agent A are independent of the IDs used between Agent A and Agent B. |
There was a problem hiding this comment.
in this example, we should use the term broker instead of agent
No description provided.