How to perform Human in the loop approval in A2A agents

[deepakn27]

How can we perform Human in the loop in A2A agents

UI ----(AGUI)-----> Agent A ---(A2A)-------> Agent B

UI calls Agent A using AGUI protocol
Agent A calls Agent B using remote A2A

If AgentB want to call a tool which need Human Approval, How can we take flow back to UI ?

[Manoj-Gujare]

Hi @deepakn27 ,

The key thing: there's no single "HITL flag" that tunnels an approval from Agent B all the way back to the UI. You chain three independent pause/resume mechanisms — one per hop — and carry correlation IDs so each resume targets the right paused task. One of those hops has a current gap (below).

The three layers

1. Tool → Agent B (Strands interrupt). The approval-requiring tool pauses Agent B via a BeforeToolCallEvent hook calling event.interrupt(name, reason=...). That stops B's loop, returns control, and is resumable; persist it with a session manager. ([Interrupts docs](https://strandsagents.com/docs/user-guide/concepts/interrupts/))

2. Agent B ⇄ Agent A (A2A input-required). Agent B (A2A server) should return the task in input-required state carrying the approval prompt, keyed by task_id / context_id; Agent A (A2A client) stops consuming at that state — it's the protocol's defined pause point — and resumes by sending a follow-up message on the same context_id. ⚠️ Current gap: Strands' StrandsA2AExecutor emits only working / completed and does not yet map a Strands interrupt to input_required — tracked in [#1371]([FEATURE] Support for Full A2A Task Lifecycle States (especially input_required) #1371) (check it for current status). Until it ships, subclass the executor to call updater.requires_input(...) when the agent invocation returns an interrupt, and on the next A2A turn feed the user's reply back into agent(...) to resume the interrupt.

3. Agent A ⇄ UI (AG-UI HITL). Serve Agent A to the UI with the official [ag_ui_strands](https://github.com/ag-ui-protocol/ag-ui/tree/main/integrations/aws-strands) adapter. AG-UI's HITL pattern is a frontend tool call: Agent A emits the approval request as a tool call on the AG-UI event stream; the UI (CopilotKit useCopilotAction / renderAndWaitForResponse) renders it, the human decides, and the decision comes back as the tool result, keyed by thread_id / run_id.

Resume cascades back down: UI result → Agent A resumes → reply on the same A2A context_id → Agent B resumes its interrupt → the tool executes, or is cancelled via event.cancel_tool = "...".

Gotchas that will bite you

• Preserve correlation IDs at every boundary (AG-UI thread_id/run_id ↔ Agent A; A2A task_id/context_id ↔ Agent B). If you start a fresh run instead of resuming the same task, the tool re-fires — the "loops forever" symptom the AG-UI Strands adapter explicitly guards against.
• Persist interrupted state with Strands session managers at both A and B; a human approval can take minutes or span a restart.
• Mentally, you're translating Strands interrupt ⇄ A2A input-required ⇄ AG-UI frontend-tool approval — each layer has its own native pause.

Simplest workaround today (sidesteps the A2A gap)

Keep the approval on the A ↔ UI hop only. Don't pause inside B — gate the sensitive action at Agent A: A exposes the approval as an AG-UI frontend tool, gets the human's decision, and only then calls B to execute (split B into a "propose/plan" call and an "execute" call). HITL stays entirely where it's well-supported, with no input-required needed over A2A. Trade-off: the approval policy lives in A, and B must be structured so its sensitive step can be triggered separately.

There's a full walkthrough of the UI hop in the AWS tutorial [Building HITL AI Agents with Strands, AG-UI and CopilotKit on AgentCore](https://builder.aws.com/content/3C80MYfWY9419ZDJyqsnJpPmvYy/building-human-in-the-loop-hitl-ai-agents-with-strands-agents-ag-ui-and-copilotkit-on-amazon-bedrock-agentcore).