Add A2A server #1537
Add A2A server #1537
Conversation
Docs Preview
|
PR Change SummaryImplemented the FastA2A library to facilitate the development of A2A servers, enhancing interoperability between AI agents.
Added Files
How can I customize these reviews?Check out the Hyperlint AI Reviewer docs for more information on how to customize the review. If you just want to ignore it on this PR, you can add the Note specifically for link checks, we only check the first 30 links in a file and we cache the results for several hours (for instance, if you just added a page, you might experience this). Our recommendation is to add |
| self.description = description | ||
| self.provider = provider | ||
| self.skills = skills or [] | ||
| # NOTE: For now, I don't think there's any reason to support any other input/output modes. |
There was a problem hiding this comment.
Would other input/output modes be necessary for multi-modal inputs/outputs? If so, you might want to not emphasize that as a value prop in the docs (it currently lists "- Rich Communication: Support for multimodal content exchange (text, structured data, files)" as something the protocol "facilitates").
There was a problem hiding this comment.
No, this input/output modes are not necessary for it.
docs/a2a/fasta2a.md
Outdated
| #### Worker | ||
|
|
||
| The `Worker` is responsible for both scheduling tasks and executing them. | ||
|
|
||
| #### Worker | ||
|
|
||
| The `Worker` is the component that defines how the task is executed. |
There was a problem hiding this comment.
I guess need to mention broker or something
|
@Kludex thanks for developing this. I noticed "Opinions A2A" in your desc and had similar sentiments when I looked at the protocol and the various SDK examples. I felt it is a protocol for defining state machines but with a lot of flexibility about the transitions seems heavy lifting for most, resulting in framework dependence in all likelihood. I think what you've done is hide the incidental complexity under a .to_a2a() wrapper. so for example users neither need to make an executor, nor make state machine decisions just to define and use an agent. Considering this, I'm still curious as to how much interop can occur due to the same thing, though on the other hand notice a lot of samples (and some "examples" in the new SDK). If you end up with any examples of interop with the pydantic a2a, please ping. Also, if you have any summary comments that feel different than your initial let me know, too. Meanwhile, I'm also quite interested in ACP which feels at a glance simpler to grok, so hope you have an example of that at some point. |
|
ps the new SDK for A2A exists, but it isn't published and I didn't see any pinging of others about it on related issues. my playground has been using git for the package https://github.com/google/A2A/tree/main/a2a-python-sdk |
This PR implements the
FastA2A- an easy way to serve an agent using the A2A protocol.We need to make some decisions here.
High level decisions
inspectorclient which makes life easier. This protocol still doesn't have such a thing. It makes the experience of developing A2A servers poor.Low level decisions
Checklist
Opinions A2A
Honestly, after developing this, I'm not sure if the protocol will thrive. It seems the specification was written in a hurry, it misses a lot of examples, and it doesn't specify how the workflows should be.
To be more concrete, let's say we want to send a task. It's (supposedly) the simplest workflow. When you send a task, you have some options:
How do we choose? Thinking about the best HTTP practices, ideally, we should send back an id, and run the task in the background... And that's what I did. That's more complicated tho, and also, is it really necessary? I can't make a simple developer-facing code without making this decision, because it implies in infrastructure changes.
In any case, I've developed this incomplete PR, which I hope we can discuss and refine in the next days.