Add new a2a call task to the specification and schema - #1114
Conversation
Signed-off-by: Emmanuel Allen <emmanuelallensoftware@gmail.com>
|
@ricardozanini @cdavernas Our first PR which covers some of our discussions about A2A lol , please review and if necessary, we can even discuss further on our Thursday meeting :) |
ricardozanini
left a comment
ricardozanini
left a comment
There was a problem hiding this comment.
Many thanks!! Just a few comments so we can start the conversation.
| > The `security` and `securitySchemes` fields of the AgentCard contain authentication requirements and schemes for when communicating with the agent. | ||
|
|
||
| > [!NOTE] | ||
| > On success the output is the JSON-RPC result. On failure runtimes must raise an error. |
There was a problem hiding this comment.
We have error definitions. I believe we should indicate which errors.
There was a problem hiding this comment.
@ricardozanini Totally agree. I think a runtime error should be used, and should carry/document the A2A error code.
There was a problem hiding this comment.
@cdavernas So you think that it should be an error of type https://serverlessworkflow.io/spec/1.0.0/errors/runtime. Where do you think the A2A error code should go because I don't think it should be the status code since they are in the range -32700 to -32000?
An example error conversion for a task not found a2a error could be:
type: https://serverlessworkflow.io/spec/1.0.0/errors/runtime
status: 500
title: Task not found, A2A Code: -32001
description: The specified task id does not correspond to an existing or active task. It might be invalid, expired, or already completed and purged.
instance: /do/0/callA2AThere was a problem hiding this comment.
@emmanuelallen we could put it as status code, because even if it is logically related to http status codes, it is not restricted to them.
I however think your proposal is cleaner. The title could be the code and or a high level description like you proposed, that decision is purely esthetic and should therefore be up to runtimes.
| > The `security` and `securitySchemes` fields of the AgentCard contain authentication requirements and schemes for when communicating with the agent. | ||
|
|
||
| > [!NOTE] | ||
| > On success the output is the JSON-RPC result. On failure runtimes must raise an error. |
There was a problem hiding this comment.
@ricardozanini Totally agree. I think a runtime error should be used, and should carry/document the A2A error code.
Signed-off-by: Emmanuel Allen <emmanuelallensoftware@gmail.com>
Signed-off-by: Emmanuel Allen <emmanuelallensoftware@gmail.com>
Signed-off-by: Emmanuel Allen <emmanuelallensoftware@gmail.com>
Signed-off-by: Emmanuel Allen <emmanuelallensoftware@gmail.com>
|
@emmanuelallen can you take a look on the red CI? |
The failing CI check is because the a2a example I added to dsl-reference.md doesn't match the 1.0.0 schema (it's checking against https://serverlessworkflow.io/schemas/1.0.0/workflow.yaml). Possible solutions to fix this are:
Do you have a suggestion for how I should resolve it? |
|
@emmanuelallen I think the CI must be fixed to match the schema accordingly to the current branch. |
|
I'll take a look later. |
Signed-off-by: Emmanuel Allen <emmanuelallensoftware@gmail.com>
|
I was wrong yesterday the ci validation is working as it should. The problem was the with the example, I have now fixed it. If you approve the workflow it should succeed, I have run it locally and all the tests pass. |
|
Speak of examples, lol — it would definitely be super helpful to include solid DSL examples later on to showcase A2A using our Serverless Workflow. This could highlight multi-agent use cases like: Multi-agent customer service system: @emmanuelallen something you'd be up for helping with in a separate PR 😄? :) New A2A examples: |
|
I'd say we can push these examples in a separate PR with a follow up issue linked to this one. Can you do it @emmanuelallen ? |
|
Yeah, I'm happy to add a few a2a examples as a separate PR tomorrow. |
|
@ricardozanini @cdavernas @emmanuelallen Thanks guys for the review and valuable comments. Now we have A2A in our spec 👍 |
|
Let's finish MCP and wrap up to release 1.1.0. |
Yes, lets do it. 😄 Btw, quick question. Any tentative date for 1.1.0 release date lol |
|
@yzhao244 it depends if we can do MCP one. I believe we can set a date after merging MCP. @cdavernas wdyt? |
4 participants
Please specify parts of this PR update:
Discussion or Issue link:
#1102
What this PR does:
Adds A2A call task to the specification and schema
Additional information:
Push Notifications
A2A push notification currently only support webhooks as a way to send task update notifications. That said external services can convert those webhook invocations into cloud events that the workflow can listen for. Hopefully at some point A2A can support natively or through an extension sending out push notifications as cloud events directly.
Streaming
I am suggesting streaming be handled by collecting up all the objects until the stream is complete and returning them as an ordered array. In the future we can add a
foreachargument similar to AsyncAPI that when set will run a set of tasks for each object received.