Meridian keeps adding topics and actions to a single Service agent to cover appointment booking, refills, claims, and referrals, and the agent is starting to misclassify what pet owners are asking for. An architect proposes splitting claims handling into its own dedicated agent that the Service agent delegates to when needed. Why does this multi-agent approach, enabled by the agent-to-agent protocol, help?
Select an answer to reveal the explanation.
Short Explanation
Picture one vet tech trying to juggle scheduling, refills, claims, and referrals all in their head at once versus a small team where each person owns one thing well - fewer, cleaner responsibilities means fewer mix-ups, and a quick hand-off covers the rest.
Full Explanation
Topic classification accuracy tends to degrade as a single agent accumulates more topics that overlap or blur together, since the reasoning engine has to distinguish pet-owner intent across an ever-growing, less distinct set of choices. Splitting claims handling into its own focused agent narrows what each agent has to classify, and the agent-to-agent protocol lets the Service agent delegate a claims-related request to that dedicated agent without re-implementing claims logic itself.
'A single agent can only ever have one topic active at a time' misstates how topics and classification actually work and invents a hard platform limitation that is not the real reason to split agents. 'MCP requires every distinct business capability to live in a separate agent' confuses MCP (context sharing with external models and tools) with an entirely different concept, and MCP imposes no such structural requirement. 'The Agent User security model forbids more than five topics' is a fabricated numeric limit with no basis in the actual constraint - the real driver here is classification reliability and maintainability, not a hard cap.
Exam takeaway: multi-agent design via A2A is chosen for classification clarity and reuse, not because of an invented topic-count ceiling.