Designing Agent-to-Agent Collaboration

I designed how users experience an Azure workload agent collaborating with an external Oracle agent during an investigation, including showing what was delegated and what came back, communicating progress or delays, and asking the user for clarification or approval when needed.

Role: Senior UX Designer, working with product, engineering, and UX partners
Timeline: Sep 2026 – Present
Outcome: Defined how users see and steer delegated agent work; the delegation pattern is now in early discussion with the Azure Design System team as a potential core Azure Copilot pattern. POC accepted and moving towards implementing with design system team.

The end to end agent trace including delegation, user elicitation, and external agent enumeration in the final response.

Context

Our Azure workload agent helps users investigate issues across a complex enterprise workload. For specialist Oracle questions, it can delegate part of the investigation to an external Oracle agent. That agent may return a finding or ask for clarification or approval before it can continue. The Azure agent remains responsible for combining the Oracle result with broader workload evidence and explaining the conclusion to the user.

Round 1, in progress: the Oracle delegation shown as an existing tool step, with the DB Fleet Central Agent's investigation plan and raw JSON input and output for a database health check — Current agent chain of thought explains what it is doing and names the 3P agent, but does not provide enough of the right info to support governance and trust.

This introduced a new interaction for our product. The existing trace framework did not yet provide a clear way to show delegated work, its progress, or requests for user input. I needed to design those moments as part of one coherent investigation, without making users follow the underlying agent-to-agent protocol.

The problem

Agent-to-agent collaboration can happen out of sight. During an investigation, our agent may delegate a specialist question to an external partner agent, share context, and receive a finding. Users do not need to follow every protocol message, but they do need to understand the consequential parts of that exchange: what was delegated, what information was shared, what came back, and which agent is responsible for the final conclusion.

The handoff can also require the user to clarify a question or approve a next step. Those requests need to be clear about who is asking, why input is needed, and what will happen after the user responds.

Meanwhile, the underlying agent capabilities and protocol behavior were evolving. The design needed to make delegation and user input understandable without depending on one implementation of the exchange.

What the user sees

The user sees each step of the exchange, with a clear line between what our agent does and what the partner’s agent does.

Flow diagram of an agent-to-agent exchange across a trust boundary. On our orchestrator agent's side: 1, ask for approval, so the user approves before anything is shared; 2, delegate the task, showing why it was called and what is sent. On the partner company agent's side: 3, the partner agent works, with progress shown including delays; 4, return results, shown as the partner agent's output. Back on the orchestrator side: 5, synthesize, where the orchestrator combines and responds. Every step feeds an activity record outside the chat, a persistent trail of each delegation for audit and awareness. — This diagram shows the flow of information and what needs to be shown to establish user trust

Approval gates the crossing, and the activity record outlives the conversation.

Key decisions

1. Make the handoff visible without exposing the protocol. I designed the trace to show why the Azure agent delegated work, what the Oracle agent was asked to investigate, its progress, and the finding it returned. Raw messages and identifiers remain available for technical inspection rather than appearing in the default view.

Round 3, in progress: the delegation step for turn 1 showing "Delegating request" — The loading state of the component shows the Agent's CoT rational for delegation.

Round 3, in progress: the response received, with its context ID and the returned finding that current Oracle diagnostic evidence does not cover the reported incident window — An early exploration of the agent trace A2A component

Round 3, in progress: the sent analysis request, with protocol details moved into an expandable input, waiting for a response — An early exploration of the agent trace A2A component

2. Keep the agents’ responsibilities distinct. The Oracle agent provides specialist findings; the Azure agent combines those findings with broader workload evidence and owns the final conclusion. Showing that transition helps users understand where the answer came from.

3. Ask for user input at consequential moments. When the investigation needs clarification or approval to proceed, the experience explains what is needed, why, and what will happen after the user responds. I did not assume every delegation requires a separate approval step.

4. Design for work that outlasts the conversation. Delayed partner activity raised a broader question: how users return to an investigation, see what completed, and inspect its history. I explored persistent activity and history as a direction, rather than treating the chat transcript as the complete record.

Extending the agent trace framework

The existing trace framework gave me a starting point, but it did not yet clearly represent work delegated to an external agent. I first mapped the Oracle investigation to its current layers, testing whether an existing tool step could show the handoff without a new component.

Round 1, complete: the delegation step collapsed to a single line, "Investigated Oracle database health and performance" — Planned trace components from the framework team might technically show some information about the A2A delegation, but none of the existing patterns provided for the full set of information recquired to engender trust.

That exercise clarified what the trace needed to communicate: the delegated objective, the Oracle agent’s progress and finding, and the Azure agent’s subsequent synthesis. I explored a dedicated delegation step for cases where the existing pattern obscured those distinctions, while keeping technical identifiers and protocol details available on inspection rather than in the default view.

Impact

The delegation design gave product, engineering, and UX partners a central artifact for evaluating and aligning on how an external agent’s work should appear within an investigation based on the ongoing technical implementation discussions.

The work has gained traction within the broader design studio. I’ve since begun working with the design system team to understand how the pattern could be implemented as a core Azure Copilot pattern. It has not been adopted yet, but it has opened a path to evaluate it at the studio level.