Conventions for Schema/Mode Negotiation and SDK Level Type Dispatch for Media Types

## Problem

`inputModes`/`outputModes` and `acceptedOutputModes` ([3.2.2 SendMessageConfiguration](https://a2a-protocol.org/latest/specification/#322-sendmessageconfiguration)) provide protocol-level format negotiation, but the spec provides no guidance on how structured data schemas are advertised or how SDKs should dispatch media types to language-native types.

This creates a gap between what modes *advertise* and what SDKs can *act on*. I may be misunderstanding what is possible with Media Types but this is my current understanding.

## Current behavior

For structured data, there are two options:

1. **Use `application/json`** — the agent card says "I accept/produce JSON," but the SDK and protocol have no way to advertise *what shape* of JSON. Clients must do application-level validation manually, which defeats the purpose of input/output mode negotiation.

2. **Use vendor media types** (e.g., `application/vnd.acme.my-type.v1+json`) — these can appear in `inputModes`/`outputModes` since they're unconstrained `list[str]`, but there is no spec-level convention for where the corresponding schema lives (if not a registry). A client that discovers a vendor media type in an agent card has no standard way to resolve its structure. This may also result in an explosion of registered media types with no clear versioning strategy.

In both cases, SDK consumers must write manual (de)serialization and validation logic for every agent interaction. There is no mechanism to take a `Part` with a given `media_type` and automatically route it to a validated, language-native type (e.g., a Pydantic model in Python, a TypeScript interface, a Go struct).

## What might be missing?

### 1. Schema advertisement (protocol level)

No standard location for schemas that correspond to media types in `inputModes`/`outputModes`. The traditional out-of-band mechanism for media type semantics is IANA registration, but IANA registrations are fixed — they don't accommodate agents that iterate on the types they accept or produce. The agent card is the natural place for this since it already describes the agent's current capabilities and is fetched dynamically.

The schema format itself is also an open question. You can use a JSON Schema to describe each type, but this isn't the only approach but something like [A2UI](https://github.com/google/A2UI) takes a catalog-based approach: components and their valid structures are defined in a Catalog Definition Document, and client/server negotiate which catalogs they support via capabilities rather than exchanging per-type JSON Schemas. Language ecosystems might prefer protobuf descriptors, TypeSpec, or other schema languages.

### 2. Type dispatch (SDK level)

No guidance on how SDKs should map `Part.media_type` to language-native types. This includes:

- **Inbound dispatch:** receiving a `Part` with a vendor `media_type` and automatically deserializing its `data` field into a registered type with validation
- **Outbound serialization:** producing a typed response object and automatically setting the correct `media_type` on the outgoing `Part`
- **Handler routing:** selecting the right handler function based on the resolved input type

### 3. Multi-mode parts in a single request

`inputModes` advertises multiple accepted modes, but there is no guidance on whether a single message can contain parts of *different* modes simultaneously (e.g., a `text/plain` part alongside an `application/json` part) and how the agent should handle mixed-mode input.

## Concrete example of what could be done

I am just adding a custom extension that bridges media types to language-native types (specifically for Python). This issue is outside the scope of an official extension proposal but just a potential solution of what is required to actually do type negotiation in practice.

### Agent card with schema advertisement

The SDK auto-generates vendor media types from registered model classes and publishes their schemas in the agent card via an extension. The key change is that schemas appear *alongside* the native `inputModes`/`outputModes`, so the card is self-describing:

```json
{
"skills": [
{
"id": "translate",
"inputModes": [
"text/plain",
"application/vnd.acme.translation-input.v1+json"
],
"outputModes": [
"text/plain",
"application/vnd.acme.translation-output.v1+json"
]
}
],
"extensions": [
{
"uri": "https://a2a.org/extensions/inputmodes/v1",
"params": {
"application/vnd.acme.translation-input.v1+json": {
"type": "object",
"properties": {
"targetLanguage": { "type": "string" },
"formal": { "type": "boolean", "default": false }
},
"required": ["targetLanguage"]
}
}
},
{
"uri": "https://a2a.org/extensions/outputmodes/v1",
"params": {
"application/vnd.acme.translation-output.v1+json": {
"type": "object",
"properties": {
"translatedText": { "type": "string" },
"confidence": { "type": "number" }
},
"required": ["translatedText", "confidence"]
}
}
}
]
}
```

### Part-level usage

Parts carry the vendor media type so the SDK can dispatch without inspecting the payload/metadata fields (optionally you could put the extension uri there instead but that works against the media type construct):

```json
{
"parts": [
{
"data": { "targetLanguage": "fr", "formal": true },
"mediaType": "application/vnd.acme.translation-input.v1+json"
}
]
}
```

The SDK can match `Part.media_type` against its type registry, deserializes into the corresponding model (e.g., a Pydantic `TranslationInput`), and validates before the agent executor is invoked.

### Discovery flow

1. Client fetches agent card
2. Reads `inputModes`, sees vendor media type
3. Looks up matching schema in the extension params keyed by media type
4. Optionally generates a client-side model from the schema

A2A-only clients (no extension support) still see vendor types in `inputModes`/`outputModes` and know the agent accepts structured typed input, even if they can't resolve the schema. Extension-aware clients get full schema discovery from the card itself — no external registry needed.

## Action Items?

At a minimum, the spec should define:

1. **A convention for schema advertisement** — a standard place in the agent card where schemas for structured media types are published, so clients can discover the shape of data an agent expects/produces without out-of-band knowledge. The format of the schema itself (JSON Schema, catalog, protobuf descriptors, etc.) can remain pluggable, but the *location* and *linkage* to media types should be standardized.

2. **Guidance for SDK implementers** — recommendations for how SDKs should implement type registries that map media types to language-native types, enabling automatic (de)serialization and validation.

3. **Clarification on multi-mode messages** — whether a single message can contain parts with different media types, and what semantics the agent should apply.

## Additional References
- [Discord Thread](https://discord.com/channels/1362108044737253548/1415384685298847765/1496161959349850132)

Review the A2A specification sections 3.2.2 and the agent card structure. Examine existing SDK implementations for how they handle media types and Part deserialization. The goal is to propose a spec extension for schema advertisement in the agent card and guidance for SDK type dispatch. 'Done' means a concrete proposal for the spec, not an implementation.

Scritto dal modello di indicizzazione a partire dal testo della issue.