Solution Design & Architecture

Three shapes cover almost every Claude system, and picking between them is the most testable judgment in this domain.

A single augmented call is one request with whatever context it needs attached: retrieved documents, a system prompt, maybe a tool or two. Classification, extraction, summarization, and question-answering all live here. If you can describe the whole task in one prompt and the output is done when the response arrives, this is the answer.

A workflow is several model calls wired together by your code. You decide the order, the branching, and the stopping condition. The model fills in the steps; the control flow is deterministic and belongs to you. Reach for this when the steps are known in advance even though their content isn't: classify, then route to one of four handlers; extract fields, then validate, then write.

An agent is a loop where the model decides what to do next, calling tools until it judges the work finished. You give it a goal and a tool surface, not a sequence. This is the right shape only when the path genuinely cannot be specified up front.

The exam's bias, and the correct engineering bias, is toward the simplest shape that works. An agentic loop over a task with four known steps is a worse design than the workflow: it costs more, takes longer, and fails in ways that are harder to reproduce. When a scenario describes a task whose steps are enumerable, the agentic option is usually the distractor.

Four questions decide whether a task has earned an agent:

• Complexity: is it genuinely hard to specify in advance?
• Value: does the outcome justify higher cost and latency?
• Viability: is the model actually good at this task type?
• Cost of error: can mistakes be caught and recovered from, with tests, review, or rollback?

A "no" on any of these argues for a simpler tier.

Decomposition is not just "break the task up." The useful cut separates work the model should own from work that should stay deterministic.

Give the model the parts that need judgment, language, or tolerance for messy input: reading an unstructured ticket, deciding which of six categories a document belongs to, drafting a reply. Keep in ordinary code the parts that have a correct answer you can compute: totals, date arithmetic, permission checks, deduplication, anything with a regulatory audit trail.

A recurring failure in real systems, and a recurring distractor in scenario questions, is asking the model to do arithmetic or enforce a policy that code could enforce exactly. If a step has a deterministic answer, a probabilistic component is the wrong tool no matter how capable it is.

Sub-tasks are cut correctly when each one can be specified, prompted, and verified independently. That third property is the one people skip. If you cannot write a check that tells you whether a sub-task succeeded, you cannot debug the system later, and you cannot evaluate it at all.

An end-to-end design has four segments, and candidates routinely under-specify the fourth.

Input: how work arrives. Synchronous request, queue, webhook, scheduled batch. This choice sets your latency budget more than the model does: a batch job can afford a slower model and multiple verification passes; a user waiting on a chat response cannot.

Processing: the model calls, retrieval, tools, and orchestration.

Output: what is returned, in what format, to what consumer. If a downstream system parses the output, that argues for constrained structured output rather than prose you regex afterward.

Feedback: how outcomes get back into improving the system. Thumbs up/down, correction capture, human edits to drafts, downstream success metrics. This is what turns a deployment into something that improves; without it you have a system that can only degrade as the world drifts away from your prompt.

Tie the whole thing back to a business pillar, because that is what a professional-level architect is being tested on: throughput (how many units of work per hour), cost per unit, staff leverage (what a person no longer does), or a latency commitment you can actually hold. An architecture that cannot be connected to one of those has not been justified, only described.

Splitting work across multiple agents buys parallelism and context isolation. It costs coordination, and the cost is larger than it looks: each sub-agent re-establishes its own context, explores on its own, and reports back, and the coordinator then has to read that report.

The split is worth it when the sub-tasks are genuinely independent and each is substantial. Fanning out across many files, investigating several unrelated subsystems, or running the same analysis over many candidates all qualify. Delegating something the coordinator could finish in a few tool calls does not.

Whatever the topology, three things have to be specified or the system will not terminate cleanly:

• Coordination: how work is divided and whether sub-agents can see each other's results.
• Handoff: what the sub-agent returns, and in what form the coordinator can consume it.
• Termination: what "done" means for each sub-agent, and what the coordinator does when one fails or returns nothing useful.

A useful pattern to know by name is writer–verifier: one agent produces, a second with a fresh context checks. A verifier that starts clean catches things self-review misses, because self-review inherits the same assumptions that produced the error.