The human-in-the-loop confirmation flow (paused long-running tool call -> input-required status -> decision reply) uses part metadata and DataPart schemas that are effectively private ADK conventions: kagent_type/adk_type = function_call, kagent_is_long_running/adk_is_long_running, an adk_request_confirmation DataPart with args.originalFunctionCall / toolConfirmation.hint / ask_user questions, and a decision DataPart (decision_type, ask_user_answers, rejection_reason).
Both the kagent_ and adk_ prefixes appear in the wild, so consumers sniff both, and the payload schema is undocumented, so every consumer reverse-engineers it and can break on any refactor.
Ask:
- Pick one prefix and treat the payload schema as a stable contract.
- Declare it as an A2A
AgentExtension in the AgentCard (the spec mechanism for exactly this), with the schema documented, so consumers can feature-detect instead of sniffing.
The A2A mechanics themselves (input-required + status message parts) are fine; this is only about the payload contract.
The human-in-the-loop confirmation flow (paused long-running tool call -> input-required status -> decision reply) uses part metadata and DataPart schemas that are effectively private ADK conventions:
kagent_type/adk_type=function_call,kagent_is_long_running/adk_is_long_running, anadk_request_confirmationDataPart withargs.originalFunctionCall/toolConfirmation.hint/ask_userquestions, and a decision DataPart (decision_type,ask_user_answers,rejection_reason).Both the
kagent_andadk_prefixes appear in the wild, so consumers sniff both, and the payload schema is undocumented, so every consumer reverse-engineers it and can break on any refactor.Ask:
AgentExtensionin the AgentCard (the spec mechanism for exactly this), with the schema documented, so consumers can feature-detect instead of sniffing.The A2A mechanics themselves (input-required + status message parts) are fine; this is only about the payload contract.