From Requirements to Architecture

The professional exam rarely asks what a parameter does. It describes a business situation, often with incomplete information, and asks which architecture you would propose and why. This lesson gives you the discipline for that conversion: from a stakeholder's request, through requirements, to a pattern, a model tier and a set of recorded decisions.

Start with the job, not the model

Failed projects usually began with "we want to use AI for X" rather than "we need outcome Y". Before you draw anything, establish five facts:

1. Outcome and consumer. Who or what consumes the output, and in what form? A human reading prose, a downstream system expecting JSON, or another agent?
2. Cost of error. What happens when the output is wrong, and who notices? This single answer drives how much human oversight, evaluation and reversibility you must design in.
3. Volume and latency shape. Interactive (seconds, one at a time), near-real-time (minutes, bursty) or offline (hours, bulk)? The shape decides whether you stream, queue or batch.
4. Data classification and residency. Personal data, regulated data, customer secrets? This narrows the platform choice (direct API, Bedrock, Vertex AI, Foundry) and the retention settings before any prompt is written.
5. Integration surface. Which systems must Claude read from or act on? Each becomes a tool, an MCP server or a retrieval source, and each is a trust boundary.

Anthropic's guidance on building agents gives a useful viability gate: pursue an agentic design only when the task is genuinely multi-step and hard to specify in advance, the value justifies higher cost and latency, the model is demonstrably capable at the task type, and errors can be caught and recovered. If any of these is a "no", stay with a simpler design.

Separate functional from non-functional requirements

Functional requirements say what the system does. Non-functional requirements (NFRs) decide the architecture. Translate each NFR into a concrete consequence:

Non-functional requirement	Architectural consequence
Sub-second perceived latency	Streaming, smaller model tier, aggressive prompt caching, short outputs
High throughput, no interactivity	Message Batches API, rate-limit planning across workspaces
Data residency or sovereignty	Platform and region selection; inference location controls where offered
Auditability	Request/response logging, trace IDs, immutable decision logs for tool calls
Accuracy threshold (for example 98% field-level)	Evaluation suite before launch, model grader plus sampled human review, confidence routing
Cost ceiling per transaction	Caching strategy, model routing, output length control, effort settings
Zero data retention	Confirm eligibility; some features and the newest model tiers may require standard retention

Write the NFRs with numbers. "Fast" is not a requirement; "p95 time-to-first-token under 800 ms" is.

Map capabilities to Claude features

Once requirements are explicit, map them to platform capabilities rather than inventing bespoke machinery:

Need	Platform capability
Question answering over documents	Files API, document blocks with citations, large context windows
Reliable machine-readable output	Structured outputs with a JSON schema; strict tool schemas
Live enterprise data	Tool use; MCP servers via the MCP connector or an agent host
Current web information	Server-side web search and web fetch tools
Computation, charts, file generation	Server-side code execution and Agent Skills
Long-running autonomous work	Agent SDK or Managed Agents, with compaction and memory
Bulk offline processing	Message Batches API at reduced cost

Capability mapping prevents the anti-pattern of building custom machinery for something the platform already provides.

Choose the pattern, then the model

Work up the ladder of autonomy and stop at the first rung that satisfies the requirements: a single call, then a code-orchestrated workflow (chain, router, parallel fan-out), then a single agent with tools, then multiple agents. Every rung adds cost, latency and failure modes.

Only after the pattern is settled do you choose a model tier. The professional habit is to prototype with the most capable model to establish what "good" looks like, build the evaluation set, and then test whether a cheaper tier or lower effort setting holds the quality bar. Judge by cost per completed task, not cost per request; a cheaper model that needs more retries is not cheaper.

Write the decision down

An architecture that lives only in a diagram will be re-argued at every steering meeting. Keep a short Architecture Decision Record per significant choice:

# ADR-004: Use a routed workflow, not an agent, for claims triage
Status: Accepted
Context: 40k claims/day, p95 latency 5s, wrong routing costs a manual re-queue.
Decision: Classifier call (small model) -> deterministic router -> extraction call
  with structured outputs. No tool use in the request path.
Consequences: Predictable cost; new claim types need a router change; agentic
  escalation deferred to phase 2 behind an eval gate.

ADRs also give you the artefact stakeholders ask for when they want to know why the system is not "just an agent".

A worked conversion

A retailer asks for "an AI assistant that answers supplier emails". Requirements work reveals 3,000 emails a day, a two-hour reply window, replies that commit the company to prices, and contracts held in a CRM. The cost of error is financial, so the answer is a queued workflow: CRM retrieval via MCP, structured extraction, a drafting call, and mandatory human approval before send. The autonomous email agent the stakeholder first described was never the right design.

Exam focus

• Expect scenario questions where the correct answer is the simplest pattern that meets the stated NFRs; agentic answers are often distractors.
• Know the four viability criteria for agents: complexity, value, model capability and recoverable cost of error.
• Be able to translate an NFR (latency, residency, auditability, cost) into a specific architectural consequence.
• Model selection comes after pattern selection; start capable, build evals, then step down based on measured quality.
• Recognise capability mapping: prefer built-in platform features (citations, structured outputs, Batches, server tools) over custom equivalents.
• Architecture decision records are the expected artefact for communicating and defending design choices.