A finance team is automating expense report processing in Microsoft Foundry. One agent extracts line items and totals from photographed receipts, a second agent checks each line item against the company's spending policy, and a third orchestrator agent decides whether to approve, flag for review, or reject the report based on the other two agents' outputs. Why might the team choose this multi-agent structure over building a single agent that handles receipt reading, policy checking and final decisions all at once?
Select an answer to reveal the explanation.
Short Explanation
You split the work so each agent does one job, which makes testing, debugging, and updating way easier. When policy rules change, you touch only the policy-checking agent, not the receipt reader or the final decision maker. Single agents can still use multiple tools, so the win is maintainability, not a technical limit.
Full Explanation
The correct choice is the one that says splitting the work lets each agent specialize in one task, making the system easier to test, debug and update when only one part, such as the policy rules, needs to change. Dividing the work into a receipt-reading agent, a policy-checking agent and an orchestrator that makes the final call means each one has a narrow, well-defined job, so when spending policy changes, only the policy-checking agent needs to be updated and retested, without touching the receipt extraction logic or the approval decision logic; this separation also makes it far easier to isolate a bug, since a wrong approval can be traced to whichever agent's output was faulty. The choice claiming a single agent is technically incapable of calling more than one tool is incorrect because single agents can be equipped with multiple tools and call several of them within one workflow; the limitation the team is working around is complexity and maintainability, not a hard technical cap on tool count. The choice claiming multi-agent systems always run faster than a single agent, since each agent processes its portion of the report on a separate, dedicated model, is incorrect because splitting work across agents does not guarantee faster performance, since the agents may still run sequentially, each waiting on the previous one's output, and coordination between agents can add its own overhead. The choice claiming Foundry requires at least three agents for any workflow that involves both image input and structured decision output is incorrect because there is no rule requiring a minimum number of agents based on whether a workflow involves images or structured output; the team chose three agents for organizational clarity, not because Foundry mandated that count.