A transit agency hosts a delay-predictor agent and a rider-assistant agent on Agent Runtime and coordinates them via A2A into one unified rider-facing chat experience. What does this design achieve?
Select an answer to reveal the explanation.
Short Explanation
Two specialists working the same front desk can feel like one seamless service to the person standing there, even though each one still has their own job. That's what A2A coordination buys here — the delay-predictor and rider-assistant stay separate and specialized, but riders experience one unified conversation.
Full Explanation
This design pattern composes specialized agents through coordination rather than merging their logic: the delay-predictor keeps its own focused capability, the rider-assistant keeps its own, and A2A handles passing information between them so the rider experiences one seamless interaction. That composition doesn't eliminate each agent's own state management — A2A coordinates handoffs and messages between agents, it doesn't centrally own or replace each agent's internal memory and session handling. Running on the same Agent Runtime deployment doesn't remove the need for Agent Identity either — permission boundaries between agents still matter even when they're co-located, since co-location is a deployment detail, not an authorization decision. And the two agents remain architecturally distinct rather than becoming one merged definition — that separation is exactly what lets each be updated, evaluated, or redeployed independently while still contributing to a combined experience. Scope note: this pattern scales to more than two agents, provided each new agent's capability is cleanly scoped and its coordination points with the others are well defined. Operational check: verify that updating the delay-predictor agent alone, without touching the rider-assistant agent's deployment, doesn't break the combined chat experience.