Contoso Insurance is designing a multi-agent claims intake system in Microsoft Foundry. The business goal is: "Accept a first notice of loss (FNOL), classify claim type, gather supporting documents, and either auto-approve low-risk claims or route complex claims to a human adjuster." The architect must decompose this goal before selecting models or hosting. Which decomposition best matches production multi-agent design practice?
Select an answer to reveal the explanation.
Short Explanation
Decomposition comes first — not model size, not fine-tuning. Contoso needs a claims orchestrator that owns the workflow, plus specialist subagents (classification, document intake, risk scoring) and explicit tools (OCR, policy lookup, fraud). Auto-approve stays inside the machine path; high-severity claims hit a human-in-the-loop gate. That is option A. A giant single agent (B) skips boundaries and makes failures hard to isolate. One Function per sentence (C) is decomposition theater without orchestration or shared state. Fine-tuning first (D) locks you into the wrong abstraction before you know which skills are agents versus tools.
Full Explanation
In multi-agent architecture, goals are decomposed into workflows, agents, subagents, and tools before compute or model choices. Option A correctly creates an orchestrator workflow, specialist agents with clear scopes, tool boundaries for deterministic systems of record, and a human-in-the-loop control for high-risk outcomes — matching AI-500 logical architecture skills.
Option B is incorrect because a single large-context agent is not a substitute for decomposition. Monolithic agents blur autonomy boundaries, complicate evaluation, and make partial failure recovery harder.
Option C is incorrect because breaking the goal into disconnected Azure Functions without shared workflow state, personas, or coordination is not multi-agent design; it is fragmented microservices without an agent control plane.
Option D is incorrect because fine-tuning is a later optimization. Agent scopes, tool permissions, and HITL gates should be designed first so training data and evaluation sets map to the real solution structure.
Exam tip: When a stem asks how to decompose a goal, look for orchestrator + specialists + tools + explicit human gates.