What You Need to Know
Translating a business problem into a Claude solution produces a measurable success criterion, a bounded scope, and a defensible boundary between the model and ordinary software.
A security firm's operations director says "we want AI for the control room". Guards write free-text incident reports every shift. Supervisors summarise them for clients and work out each site's billable hours.
Problem-First Design
Before any pattern, model, or prompt is chosen, an architect establishes three things.
-
The job to be done. Who performs this work today, how long it takes, what it costs, and where it goes wrong. "AI for the control room" is not a job. "Summarising shift reports for clients, which takes most of each supervisor's day" is one, because it names a task and a cost you can measure.
-
The constraint set. Latency tolerance, cost ceiling, accuracy bar, risk appetite, data sensitivity, and regulatory context. Constraints eliminate architectures. A strict latency SLA rules out long sequential chains, because each step adds to the response time. An audit requirement rules out unpredictable agent paths, because an auditor cannot check a path that changes from run to run. Capture them first and half your design decisions make themselves.
-
The success criterion. A metric, a baseline, and a target, stated before the build. Anthropic's own guidance is to define specific, measurable, achievable, relevant criteria (task fidelity, consistency, latency, price) before building evaluations. A solution without a measurable success criterion is a demo, not an architecture, because nobody can show it beat anything. At the security firm, the metric could be supervisor time per client summary.
Key Concept
Define measurement before implementation. Distrust any option that jumps to a build with no baseline and no target metric. The professionally correct sequence is problem, constraints, success criterion, then solution shape.
The Fit Test: Is This an LLM Problem at All?
Claude earns its place where a task intrinsically involves language understanding, synthesis, judgement over unstructured input, or flexible conversation. Where deterministic rules fully specify a task (tax calculation, fixed-schema validation, threshold checks), conventional software wins on every axis: cheaper, faster, exactly correct, auditable, testable.
Most production solutions are hybrids: deterministic code around a Claude-shaped core. The architect draws that boundary deliberately. At the security firm, Claude summarises the guards' reports and extracts structured fields for rule-based validation and a deterministic billing calculation. Routing a rule-bound calculation through a model call adds cost, latency, and a non-zero error rate for zero added capability.
Capability Mapping
Requirements map to a small set of task shapes. Each shape implies a different architecture, evaluation method, and risk profile.
| Task shape | Typical architecture implication | Evaluation implication |
|---|---|---|
| Classification | Single call, constrained output | Accuracy against a labelled set |
| Extraction | Structured output plus schema validation | Field-level precision and recall |
| Summarisation | Single call, grounding checks | Faithfulness rubric or similarity scoring |
| Generation | Draft-for-review delivery, tone constraints | Rubric-graded quality |
| Conversation | Context management, session state | Multi-turn quality plus safety |
| Agentic action | Tools, guardrails, observability | End-to-end task success rate |
Name the shape early. An extraction problem dressed up as a chatbot wastes the structure the task naturally has. The security firm wants the same fields from every report: extraction. A chatbot would lose its schema validation and field-level scoring.
Scoping: Narrow First, Then Expand
Start with the narrowest workflow that delivers measurable value, prove it, then expand. A targeted workflow embedded in an existing tool beats a general-purpose assistant on every business value pillar (objective 1.6). Its value is measurable and its risk is bounded. The general assistant has no baseline to beat, diffuse risk, and a success criterion nobody can state. At the security firm, that is summary drafting inside the supervisors' existing reporting tool.
In the exam
The Professional exam opens where real projects open: someone with a budget says "we want AI for X". Every question on this objective tests whether you start from the problem or from the technology. It rewards defining measurement before implementation. It tests the fit both ways: knowing where not to use a model scores as highly as knowing where to use one.
In the favourite distractor pair, the stem names a measured cost driver. One option targets it directly; another proposes something broader and more impressive. The measured, targeted option wins.
Exam Traps
Proposing a general-purpose assistant when the business case names one high-volume workflow
The general assistant has no measurable success criterion and diffuse risk. The targeted workflow addresses the measured cost driver with bounded risk and provable value — and the exam stem usually hands you the measurement.
Selecting an architecture before capturing constraints and success criteria
Constraints eliminate architectures: a strict latency SLA rules out long chains, an audit requirement rules out unpredictable paths. Deciding shape before constraints guarantees rework, and the exam expects the professional sequence: problem, constraints, criterion, then shape.
Routing a fully rule-specified sub-task, such as a payout calculation or fixed-schema validation, through a model call
Deterministic code is cheaper, faster, and exactly correct. A model adds cost, latency, and a non-zero error rate for zero added capability. The exam rewards recognising where not to use a model.
Practice Scenario
An insurer wants to introduce AI into its claims department, and a claims handler must still approve every settlement. A time-and-motion analysis shows 70% of claims-handler time goes on summarising claim files and drafting settlement letters, and the sponsor wants that share reduced. Which solution should the architect propose first?
Build Exercise
Write a One-Page Solution Brief
What you'll learn
- How to quantify a business problem before proposing a solution
- How to capture the constraint set that eliminates architectures
- How to state a success criterion with a metric, baseline, and target
- How to map a requirement to a task shape
- How to draw the boundary between deterministic code and model calls
- Pick a real workflow from your organisation and quantify its current cost: time per case, volume, error rate
Why: Professional solution design starts from a measured problem, not a technology. The quantification becomes your baseline.
You should see: Two or three sentences with real numbers: who does the work, how long it takes, what it costs per month.
- Write the constraint set: latency tolerance, cost ceiling, accuracy bar, data sensitivity, regulatory context
Why: Constraints eliminate architectures before you design anything. A tight latency budget or an audit requirement removes whole solution families.
You should see: Five one-line constraints, each specific enough to rule something out.
- State the success criterion as a metric with a baseline and a target
Why: A solution without a measurable success criterion is a demo. The criterion also seeds the evaluation work Domain 4 examines.
You should see: One sentence: metric, current baseline, target, and how it will be measured.
- Map the requirement to a task shape (classification, extraction, summarisation, generation, conversation, agentic action) and justify the mapping
Why: The shape implies the architecture, the evaluation method, and the risk profile. Naming it early keeps the design honest.
You should see: The shape named, plus one sentence on what that implies for validation and evaluation.
- Draw the boundary: list which sub-tasks stay in deterministic code and which go to Claude, with one sentence of justification each
Why: The exam scores recognising where not to use a model as highly as where to use one. Hybrid boundaries are the professional norm.
You should see: A two-column list: model side (language understanding, synthesis, judgement) and code side (rules, calculations, validation).
Sources
- Define success criteria and build evaluations — Anthropic
- Building Effective AI Agents — Anthropic
- Choosing the right model — Anthropic