[Feat]: A2A-compliant user confirmation form

[NicklasChristiansen]

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

A remote agent might require confirmation from a user before executing specific tasks. What is the appropriate way to send a confirmation form/button, so the host/client can show the button in the UI and pass the result back to the remote agent?

Describe the solution you'd like

Ideally some A2A compliant form structure all hosts/clients expect. Example if a remote agent can delete an employee from a system:

employee_name = "John Doe"
employee_id = "E12345"
sub_task_id = "sub_task_abc"

# Create the simple confirmation form
Part(
    root=DataPart(
        kind="data",
        data={
            "type": "form",
            "title": f"Are you sure you want to delete employee {employee_name}?",
            "description": f"By confirming, employee {employee_name} will be deleted permanently.",
            "schema": {
                "type": "object",
                "properties": {
                    "confirmation": {
                        "type": "boolean",
                        "title": "I confirm the permanent deletion of this employee."
                    }
                },
                "required": ["confirmation"]
            },
        },
        metadata={
            "form_id": f"delete_confirmation_{sub_task_id}",
            "employee_id": employee_id,
            "subtask_id": sub_task_id,
        }
    )
)

Describe alternatives you've considered

A remote agent could ask for confirmation via text → the user responds via text → the remote agent handles this, but I see errors happening here down the line.

Additional context

No response

Code of Conduct

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

[pstephengoogle]

This type of use case is supported by use of the extensions system. This is preferred over trying to formalize a schema in the core protocol definition as there isn't a clear universally accepted standard.

For example you could define 'my-form-extension' which will returns data parts with the required structure, as defined by the extension. Users of your agent will need to know the extension semantics (as it is announced by your agent, and the client should indicate knowledge of it when it sends a request) - it is the clients responsibility then to use the data as intended.

Our hope is that the really useful extensions will be standardized on and can become part of the core protocol eventually; we don't want people to be blocked from building what they need, but we also don't want to include the wrong things in the protocol that will make it too hard or complicated for people to build with in the future.