Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 34 additions & 5 deletions modules/ROOT/pages/af-agent-networks.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,40 @@ These servers will be published to Exchange.
The asset might also be published to Exchange.
. An asset that has been added to this agent network project from Exchange.

== A2A Protocol

Agent networks use the A2A specification 0.3.0. Brokers use the A2A protocol to accept requests to reach other agents.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the A2A protocol, the server (the agent receiving the request) always generates the contextId and taskId.

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


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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When an agent acts as a broker, IDs do not pass through from the upstream client.

Several things here:

  1. 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.
  2. This is not true just for brokers but any three-party A2A communication.
  3. 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


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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in this example, we should use the term broker instead of agent

* When Agent A delegates a task to Agent B, Agent B (acting as a server) generates its own `contextId` and `taskId`.
* Agent A is responsible for maintaining a mapping between its own upstream `taskId` (used to respond to its client) and the downstream `taskId` it is tracking with Agent B.
* If Agent B requires more information (if it returns `status: input-required`), Agent B provides a `contextId` and `taskId` to Agent A. Agent A uses these IDs to provide the requested input to Agent B. The client never sees Agent B's internal IDs.

[cols="1,1,1", options="header"]
|===
| Relationship | Role | Logic
| Client -> Agent A | Agent A is server | Generates `contextID_1` and `taskID_1` for the client.
| Agent A -> Agent B | Agent B is server | Generates `contextID_2` and `taskID_2` for Agent A.
| Network broker | Agent A | Agent A maps `contextID_1` and `taskID_1` to `contextID_2` and `taskID_2`.
|===

For more information, see https://a2a-protocol.org/v0.3.0/topics/life-of-a-task/#group-related-interactions[Life of a Task - Group Related Interactions].

=== Non-Supported Features

Agent network doesn't support the following features in the A2A protocol.
* Task History

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not true, this is supported

* Push Notifications Config

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not true, supported

* Streaming

== Considerations

Agent networks have these considerations.
Expand All @@ -69,11 +103,6 @@ Agent networks have these considerations.
** Basic
** Client Credentials
** Anypoint Client Credentials
* A2A specification 0.3.0 is supported. Brokers use the A2A protocol to accept requests to reach other agents.
* These A2A features aren't available.
** Task History
** Push Notifications Config
** Streaming
* Text-based prompts and responses are supported. Image and binary message/artifact types aren't supported.
* All LLM models in your agent network project must support structured responses in JSON format. For example, a `gpt4.1` model is supported; a `gpt4` model isn't.
* These LLMs are supported.
Expand Down
2 changes: 1 addition & 1 deletion modules/ROOT/pages/af-project-files.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -494,7 +494,7 @@ Use these properties to handle error scenarios. Define these properties within t

`agents`

Reference agents defined in a different agent network, or another agent used in your company. Any agent is valid, as long as it supports A2A as its communication protocol.
Reference agents defined in a different agent network, or another agent used in your company. Any agent is valid, as long as it supports A2A as its communication protocol. For more information, see xref:af-agent-networks.adoc#a2a-protocol[]

Example

Expand Down