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. You need a claims orchestrator that owns the workflow, plus specialist subagents for classification, document intake, and risk scoring, plus explicit tools for OCR, policy lookup, and fraud signals. Auto-approve stays inside the machine path, and high-severity claims hit a human-in-the-loop gate.
Full Explanation
In multi-agent architecture, goals are decomposed into workflows, agents, subagents, and tools before compute or model choices. The claims orchestrator workflow with specialized subagents for classification, document intake, and risk scoring, plus tools for document OCR, policy lookup, and fraud signals, plus a human-in-the-loop gate for high-severity paths 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. The single general-purpose agent with a 128k context window so the entire claims process stays in one conversation without decomposition 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. The approach that maps each sentence of the business goal to a separate Azure Function with no shared workflow state or agent personas 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. The approach that starts by fine-tuning a single model on historical claims text, then decides agent boundaries after the model is trained is incorrect because fine-tuning is a later optimization. Agent scopes, tool permissions, and human-in-the-loop 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.