Skip to content

A2A Documentation lacks the client perspective for adoption #1726

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dat-adi opened this issue May 14, 2025 · 4 comments
Open

A2A Documentation lacks the client perspective for adoption #1726

dat-adi opened this issue May 14, 2025 · 4 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@dat-adi
Copy link

dat-adi commented May 14, 2025

Ref: https://ai.pydantic.dev/a2a/#pydanticai-agent-to-a2a-server

The documentation addresses how an agent can be converted to be A2A-compatible but doesn't include examples or information on how a client should send messages to the agent to receive a response.

I could open a PR to update the documentation to reflect this?

@Kludex Kludex added the documentation Improvements or additions to documentation label May 14, 2025
@Kludex
Copy link
Member

Kludex commented May 14, 2025

Yeah, PR is welcome.

We also need to add the other supported methods.

@dat-adi
Copy link
Author

dat-adi commented May 15, 2025

Hey @Kludex, I haven't changed anything on the uv.lock file but seem to be failing the pre-commit stage. Any clues on what could be done here?

clai help output.........................................................Failed
- hook id: clai-help
- exit code: 2

error: Failed to parse `uv.lock`
  Caused by: TOML parse error at line 691, column 1
    |
691 | [[package]]
    | ^^^^^^^^^^^
missing field `version`

@dat-adi
Copy link
Author

dat-adi commented May 15, 2025

Turns out that it was a uv version issue. Upgrading it did the trick.

@dat-adi
Copy link
Author

dat-adi commented May 15, 2025

Done with the documentation for A2A with #1737

On another note, I do have a question. Is there a reason as to why we don't run coverage tests on the user's end during pre-commit?

I found myself committing to the PR multiple times before I realized that I could've just run the tests on my system for the docs before sending in a commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants