A retailer wants a multi-agent solution that handles “resolve a late shipment”: detect delay, check inventory alternatives, propose options to the customer, and create a replacement order only after confirmation. How should you decompose the goal into agents and tools at the logical architecture level?

Architecting multi-agent solutions starts by decomposing goals into workflows, agents, and tools, including control loops and human-in-the-loop. The correct approach is separate agents or subagents for delay detection, inventory alternatives, customer communication, and order creation, each with narrowly scoped tools, plus a workflow gate requiring human-in-the-loop or explicit customer confirmation before order creation runs. This maps specialized agents to sub-goals, scopes tools per function, and matches autonomy boundaries and HAX/responsible automation. The monolithic agent with a single unbounded tool that can read and write every enterprise system without sub-goals is incorrect because it violates least-privilege tool design and makes evaluation and safety harder. The three human employees only approach with no software agents is incorrect because human-in-the-loop is compatible with multi-agent design, and excluding software agents ignores the requirement to design an agentic solution. The pure batch ETL pipeline that nightly reprocesses all shipments without interactive agents or tools is incorrect because nightly ETL does not provide interactive resolution workflows with customer confirmation. Exam tip: Look for decomposition into specialized agents plus scoped tools plus explicit human-in-the-loop or control gates when goals include irreversible actions.