Add a new `A2A` call task

[cdavernas]

What would you like to be added?

Add a new call task for the Agent-to-Agent Protocol (A2A), enabling secure and structured communication between agentic systems within workflows. This task would make it possible to invoke A2A-compliant endpoints and pass structured messages following the A2A specification.

The task should support:

• Discovering agents using the A2A discovery endpoint
• Sending A2ARequest messages to a remote agent or service,
• Receiving and handling the corresponding A2AResponse,
• Optional streaming for multi-part or progressive responses,
• Support for headers, metadata, and error codes defined by A2A.

This addition would enable interoperable, agent-native operations within declarative workflows and facilitate integration with a growing ecosystem of A2A-aware systems.

Proposal(s):

Introduce a new task type, e.g. a2a, to handle outbound A2A messages. This task would be modeled around the A2A JSON-based protocol and support the following configuration:

• A server field specifying the target A2A server,
• A method field containing the name of the A2A request to perform
• A parameters field containing the request's parameters
• An optional protocol (version) to allow future-proofing.

On execution, the workflow runtime should:

• Format and send the message according to the A2A protocol over HTTP(S) (JSON RPC),
• Await and parse the A2AResponse,
• Handle errors (e.g., error.code, error.message) per A2A spec,
• Optionally process streaming responses if supported by the agent.

This proposal enables workflows to natively speak A2A, paving the way for standardized, composable agent orchestration across services.

Alternative(s):

No response

Additional info:

No response

Community Notes

• Please vote by adding a 👍 reaction to the feature to help us prioritize.
• If you are interested to work on this feature, please leave a comment.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[emmanuelallen]

@amin-nikanjam and I have been using HTTP call tasks to begin to work with A2A servers, but it leads to verbose task definitions even without comprehensive error handling. I think an A2A call task makes sense but some of the problems can be fixed with a catalog function.

A2A call task

This is an example of what the A2A call task could be

Name	Type	Required	Description
method	string	yes	The A2A rpc method. One of message/send, message/stream, tasks/get, or tasks/cancel.
agentCard	any|externalResource	yes	The resource that describes the agent.
params	any	no	Message params. Some params are automatically set: message.messageId and message.role.
protocol	string	no	A2A protocol version.

Pros:

• Can use the authentication mechanism inside the Agentcard
• Simpler to show how SWS supports A2A protocol

Cons

• Requires modifying the spec now and for every major change to the A2A protocol

Catalog function

Pros:

• Wouldn't require modifying the spec and therefore any of the engines
• Shows the power of catalog functions as an extension mechanism

Cons

• Wouldn't be able to support authentication from the Agentcard
• Wouldn't be able to support streaming without adding streaming support to HTTP call tasks
• Wouldn't be able to support agent registries supporting A2A since they relied on Agentcard

[ricardozanini]

+1 to add it as an A2A-specific task to the specification. It won't break the API, and we will have the possibility to expand it as needed based on any changes to the upstream standard (A2A). Additionally, I believe that we should navigate the AI buzz.

Having this new addition, as well as explained by @cdavernas in the issue description, plus the pros we already talked about in the weekly meeting, will put us on the correct path.

@emmanuelallen I have a few Qs:

1. Why can agentCard be any? Isn't it solely a valid URI? I believe we should also accept an expression, but this should be covered by externalResource already.

2. Were these method enumerations taken from the A2A standard?

3. In the params, can you clarify why "Some params are automatically set"? This should be well-detailed in the spec. Will it be the runtime implementation's responsibility to set it?

Thanks!

[emmanuelallen]

@ricardozanini

1. My thinking was that the agent card could be placed inline in the SWS document but since that is different from how OpenAPI and Async API tasks do it just supporting an external agent card makes sense

2. Yes, I got them from here https://a2a-protocol.org/latest/specification/#7-protocol-rpc-methods. I only included some of the most important methods but there is a good argument for including all of them.

3. For params the problem I was trying to solve is that every method takes in a slightly different parameters object. We could just add each of them to the spec, but then we are tightly bound to any changes to A2A. So what I was considering is that we take the parameters object in inline and then the runtime will have to set particular fields it can with default values (and randomly generated uuids). The final option is that the runtime could just make no modifications to the params object but this would lead to extra verbosity of the workflow document.

The fields that I believe should be set by the runtime if not already set in the params object are: message.messageId: /** A unique identifier for the message, typically a UUID, generated by the sender. */ messageId: string; https://a2a-protocol.org/latest/specification/#64-message-object

message.role: /** Identifies the sender of the message. `user` for the client, `agent` for the service. */ readonly role: "user" | "agent"; https://a2a-protocol.org/latest/specification/#64-message-object

[ricardozanini]

@emmanuelallen mind working on a PR? So we can move forward with this!

[yzhao244]

@emmanuelallen Hi Emmanuel, I agree with @ricardozanini . Lets further discuss any proposed changes to the spec and we can consolidate into a PR and have the community to review together :)

[emmanuelallen]

@ricardozanini @yzhao244 Yes, absolutely. I'll create a PR with the proposed changes to dsl.md and dsl-reference.md

[amin-nikanjam]

Sure, with Emmanuel, we will work on a PR.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cdavernas]

Closed by #1114