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
There was a problem hiding this comment.
@marianogonzalez I simplified the sentence.
|
|
||
| === 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
There was a problem hiding this comment.
@marianogonzalez I changed it to read: In MuleSoft agent networks, the server (the agent receiving the request) always generates the contextId and taskId.
But should we say In MuleSoft agent networks, the broker (the agent receiving the request) always generates the contextId and taskId.:
|
|
||
| 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
There was a problem hiding this comment.
@marianogonzalez In the interest of not having a diagram right away, I tried to simplify the explanation here. Does this work?
| === Non-Supported Features | ||
|
|
||
| Agent network doesn't support the following features in the A2A protocol. | ||
| * Task History |
There was a problem hiding this comment.
OK, I removed it, but in the docs, it's listed as not available. Assumed that meant not supported. https://docs.mulesoft.com/anypoint-code-builder/af-agent-networks#considerations
|
|
||
| Agent network doesn't support the following features in the A2A protocol. | ||
| * Task History | ||
| * Push Notifications Config |
There was a problem hiding this comment.
Also listed as unavailable https://docs.mulesoft.com/anypoint-code-builder/af-agent-networks#considerations
…ing "agents" with "brokers" and enhancing the explanation of context and task ID scoping in multi-agent networks.
|
|
||
| In MuleSoft agent networks, the server (the agent or broker receiving the request) always generates the `contextId` and `taskId`. These IDs define the state and scope of a specific conversation between two agents. | ||
|
|
||
| In a multi-agent network, a client sends a request to a broker and the broker generates the necessary IDs. When the broker sends a request to the next broker in line, the broker doesn't send these same IDs. Instead, the broker establishes a unique `contextID` and `taskID` for the request to the next broker. |
There was a problem hiding this comment.
This is still not clear and potentially misleading:
Instead, the broker establishes a uniquecontextIDandtaskIDfor the request to the next broker.-> The termthe brokeris being used to refer to both broker, making it unclear which broker generates what- This can also be the case with non-broker agents. If a broker calls a specialized agent, although it is not forced to generate a context or task id, it very well might, in which case the behavior is the same. Also notice that a taskId is always matched with a contextId, but a contextId can exist without any taskId
| Consider a network with a client and two brokers (1 and 2). | ||
|
|
||
| * The IDs used between the client and Broker_1 are independent of the IDs used between Broker_1 and Broker_2. | ||
| * When Broker_1 delegates a task to Broker_2, Broker B (acting as a server) generates its own `contextId` and `taskId`. |
There was a problem hiding this comment.
When Broker_1 delegates a task to Broker_2, Broker B -> Should Broker B be replaced with Broker 2?
|
|
||
| == 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.
@marianogonzalez I simplified the sentence.
| === Non-Supported Features | ||
|
|
||
| Agent network doesn't support the following features in the A2A protocol. | ||
| * Task History |
There was a problem hiding this comment.
OK, I removed it, but in the docs, it's listed as not available. Assumed that meant not supported. https://docs.mulesoft.com/anypoint-code-builder/af-agent-networks#considerations
|
|
||
| Agent network doesn't support the following features in the A2A protocol. | ||
| * Task History | ||
| * Push Notifications Config |
There was a problem hiding this comment.
Also listed as unavailable https://docs.mulesoft.com/anypoint-code-builder/af-agent-networks#considerations
|
|
||
| === 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.
@marianogonzalez I changed it to read: In MuleSoft agent networks, the server (the agent receiving the request) always generates the contextId and taskId.
But should we say In MuleSoft agent networks, the broker (the agent receiving the request) always generates the contextId and taskId.:
|
|
||
| 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.
@marianogonzalez In the interest of not having a diagram right away, I tried to simplify the explanation here. Does this work?
|
|
||
| In MuleSoft agent networks, the server (the agent or broker receiving the request) always generates the `contextId` and `taskId`. These IDs define the state and scope of a specific conversation between two agents. | ||
|
|
||
| In a multi-agent network, a client sends a request to a broker and the broker generates the necessary IDs. When the broker sends a request to the next broker in line, the broker doesn't send these same IDs. Instead, the broker establishes a unique `contextID` and `taskID` for the request to the next broker. |
There was a problem hiding this comment.
@marianogonzalez In the interest of not having a diagram right away, does this work? I tried to simplify it.
…in multi-agent networks for improved clarity and consistency.
…e the documentation and focus on key considerations for agent networks.
|
|
||
| In MuleSoft agent networks, the brokers receiving a request always generate a `contextId` and `taskId`. These IDs define the state and scope of a specific conversation between two agents. A `taskId` is always matched to a `contextId`, but a `contextId` can exist without a `taskId`. | ||
|
|
||
| In a multi-agent network, a client sends a request to Broker_1 and Broker_1 generates the necessary IDs for that request. When Broker_1 sends a new request to the next broker or non-broker agent in line, that broker or non-broker agent establishes a unique `contextID` and `taskID` for the new request. (Note that it's not mandatory for non-broker agents to generate a `contextId` and `taskId` when receiving requests from a client.) |
There was a problem hiding this comment.
I would either do away with the "Note" in the parenthesis or make it an actual note. And also remove the parenthesis.
|
|
||
| === Context and Task ID Scoping in Agent Networks | ||
|
|
||
| In MuleSoft agent networks, the servers (the brokers receiving a request) always generate a `contextId` and `taskId`. These IDs define the state and scope of a specific conversation between two agents. A `taskId` is always matched to a `contextId`, but a `contextId` can exist without a `taskId`. |
Co-authored-by: Valkyrie Hunter <[email protected]>
No description provided.