[Feat]: Generate Pydantic models from proto definition for Python-idiomatic validation for A2A Version 1.0.x

[Coding-Crashkurse]

Is your feature request related to a problem? Please describe.

The migration to protobuf-generated types (PR #572) removes Pydantic models entirely from the SDK. While using a2a.proto as the single source of truth is the correct architectural decision, the removal of Pydantic models creates a significant developer experience gap for the Python ecosystem.

The problem:

1. FastAPI, the most widely used Python web framework for building AI/agent services, uses Pydantic natively for request validation, serialization, OpenAPI schema generation, and error reporting. Proto objects don't integrate with any of this. Developers lose automatic validation, clear error messages, .model_dump(), .model_validate(), union discriminators, and Field() defaults.

2. Protobuf objects in Python are not idiomatic. WhichOneof(), HasField(), CopyFrom(), MessageToDict()/ParseDict() are foreign patterns to Python developers building agents with LangChain, CrewAI, or custom FastAPI services. Proto3 has no required fields, so ParseDict({}, SendMessageRequest()) succeeds silently with an empty object, providing no validation at all.

3. The v0.3.0 Pydantic types (generated from the OpenAPI spec via datamodel-codegen) were well-received and widely adopted. Multiple community frameworks depend on them for HTTP-layer validation. Removing them without replacement forces every downstream project to either vendor their own type definitions or wrap proto objects with manual validation boilerplate.

4. This is visible in the issue tracker right now: SDK doesn't validate proto REQUIRED fields in SendMessage: missing messageId, role, or parts is accepted #876 "SDK doesn't validate proto..." and [Bug]: Server does not validate A2A-Version header — missing VersionNotSupportedError for unsupported versions #856 "Server does not validate..." are direct consequences of losing Pydantic's validation layer.

Describe the solution you'd like

Generate Pydantic models from the proto definition as an additional build artifact, alongside the existing proto-generated types. Both would be published in the SDK package.

Concretely:

• a2a.types.proto (or a2a.grpc): Proto-generated types from a2a_pb2, as implemented in PR refactor!: upgrade SDK to A2A 1.0 specs #572. Used by gRPC transport and anyone who prefers proto-native patterns.

• a2a.types (or a2a.types.models): Pydantic models generated from the same a2a.proto source. Used for HTTP/JSON validation, FastAPI integration, and Python-idiomatic development.

Generation can be automated via protobuf-to-pydantic, custom protoc plugin, or a build script that derives Pydantic models from the OpenAPI/JSON schema (which is already generated from the proto via buf). The key point: a2a.proto remains the single source of truth. The Pydantic models are a generated artifact, not a manually maintained parallel type system.

This is not an either/or decision. The proto types serve gRPC consumers well. The Pydantic types serve the HTTP/JSON/FastAPI ecosystem. Both are generated from the same source, stay in sync automatically, and serve different transport layers of the same protocol.

The cost is one additional codegen step in the build pipeline. The benefit is that the Python SDK remains usable for the majority of Python agent developers who build on FastAPI/Pydantic.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[brucearctor]

FWIW: I took a prerequisite step towards updating CI.

Generating pydantic directly is ideal [ rather than via JSONSchema ].

https://github.com/protocgen/proto2pydantic/ ... I wrote this, and will be happy to further modify so usable here [ or contribute ]. More to come. I imagine just updating the build processes. But, is quite late for now. So, for a future time.

Cheers -

[Coding-Crashkurse]

@brucearctor Thanks for sharing proto2pydantic, that looks like a solid foundation for the codegen step!

That said, I think it's important that the Pydantic models ship as part of the official SDK rather than relying on external tooling. The value here isn't just that it's possible to generate Pydantic types from proto, it's that they're included out of the box, maintained alongside the proto types, and treated as a first-class citizen of the Python SDK.

If Pydantic models live outside the SDK, every downstream project has to discover, integrate, and pin a separate codegen tool. That fragments the ecosystem and defeats the purpose of having a standardized protocol.

Would love to hear from the maintainers / Google folks on whether this is something that's being considered for the official build pipeline. Even a quick signal on whether this direction is viable would help the community plan accordingly.