Best practice for exposing Remote A2A Agent state and UI metadata to the calling ADK agent

[rivkav]

Title: Best practice for exposing Remote A2A Agent state and UI metadata to the calling ADK agent

Hi,

I'm building a multi-agent system with Google ADK where one ADK agent communicates with an external agent through RemoteA2aAgent.

The external agent is not just returning a final result. It has a long-running workflow and exposes information such as:

• Current workflow state
• Progress
• Current step
• Next expected action
• Dynamic UI controls (buttons, forms, etc.)
• Other metadata that the calling agent can use to decide how to continue the conversation.

After reading the A2A specification, I'm still unsure what the recommended approach is for this kind of information.

My questions are:

1. Is there an official or recommended pattern for exposing agent state through A2A?
2. Should this information be placed in metadata, artifacts, or somewhere else?
3. If the information is not part of the user's final output but rather represents the execution state of the remote agent, what is the intended location?
4. Is there a recommended contract for exposing dynamic UI information (buttons, forms, next actions) so that different agents can interoperate consistently?
5. If multiple remote agents are integrated, is there a best practice for keeping a consistent response contract across all of them?

My goal is to define a standardized contract that every external agent can implement, allowing the calling ADK agent to understand the remote agent's state without requiring custom logic for each integration.

I'd appreciate any guidance or examples of recommended patterns.

[arpitraval]

For this kind of Remote A2A integration, I would separate the remote agent’s final user-facing result from its execution/control metadata.

A clean contract could be:

{
  "status": "running | waiting_for_user | completed | failed",
  "current_step": "collecting_requirements",
  "progress": {
    "percent": 45,
    "message": "Waiting for approval"
  },
  "next_action": {
    "type": "user_input_required",
    "label": "Approve workflow",
    "schema": {}
  },
  "ui": {
    "controls": [
      {
        "type": "button",
        "id": "approve",
        "label": "Approve"
      }
    ]
  },
  "result": null
}

I would avoid putting all of this into the natural-language final output, because the calling ADK agent or UI then has to parse text.

My preferred split would be:

• result / final response: only the user-facing answer or completed output
• metadata: machine-readable workflow state, progress, current step, next action
• artifacts: durable files or large structured outputs that need to be referenced later
• UI contract: keep it small and explicit, for example ui.controls, ui.form_schema, or next_action

For multiple remote agents, I would define one normalized envelope that every external agent returns, even if the internal implementation differs.

Example:

{
  "agent_id": "billing_agent",
  "execution_id": "exec_123",
  "status": "waiting_for_user",
  "state": {},
  "next_action": {},
  "ui": {},
  "artifacts": [],
  "result": null
}

Then the calling ADK agent only needs to understand one contract instead of custom logic for each remote agent.

In production, I would also include execution_id, trace_id, and schema_version so the caller can resume, debug, and evolve the contract safely.