Professional domain 1 · Solution design and architecture
From business problem to design
- Start from the outcome the business wants and how it will be measured, the current process and its baseline, the users, the data and the constraints. Then decide whether Claude is the right tool at all, and where in the process it fits.
- Design end to end: input → processing → output → feedback loop. The feedback loop (user ratings, human corrections, logged failures) is what lets the system improve and gives you evaluation data.
- Tie the design to the business value pillar the sponsor cares about (efficiency, transformation, productivity, cost, or meeting performance SLAs) and measure that, not model quality alone.
Architectural patterns
Anthropic separates workflows (LLMs and tools orchestrated through predefined code paths) from agents (the LLM directs its own process and tool use). The building block of both is the augmented LLM: a model with retrieval, tools and memory.
| Pattern | Use when |
|---|---|
| Prompt chaining | The task splits cleanly into fixed steps, each simpler to get right |
| Routing | Inputs fall into distinct categories that are better handled separately |
| Parallelisation | Independent subtasks can run at once for speed, or several attempts or perspectives are needed (sectioning, voting) |
| Orchestrator-workers | A complex task whose subtasks can't be predicted in advance |
| Evaluator-optimiser | There are clear evaluation criteria and iterative refinement measurably helps |
| Agent | Open-ended problems where the number of steps can't be predicted or hard-coded |
Anthropic's advice: start with simple prompts, optimise them with evaluation, and add multi-step agentic systems only when simpler solutions fall short.
Multi-agent systems and decomposition
- Anthropic's research system uses an orchestrator-worker design: a lead agent plans, spawns subagents to explore in parallel, and synthesises what they find.
- It costs more: agents use about 4× the tokens of a chat, and multi-agent systems about 15×. It pays off for valuable, broad tasks that parallelise well, exceed one context window or involve many tools. It's a poor fit when agents must share context or depend on each other closely, which includes most coding.
- Give each subagent an objective, an output format, guidance on tools and sources, and clear boundaries. Scale the effort to the question: a simple lookup needs one agent, a comparison a few.
- Decompose by independence: fixed, known steps suit a chain; unknown or changing subtasks suit an orchestrator that plans as it learns.
See also: Foundations domain 1 · Subagents and coordination.
Docs: Building effective agentsMulti-agent research system
Practise Domain 1