What You Need to Know
When you translate a business problem into a Claude solution, you produce three things. They are a measurable success criterion, a bounded scope, and a defensible boundary between the model and ordinary software.
This lesson uses one made-up example throughout: a security firm. Its operations director says "we want AI for the control room". Guards write free-text incident reports every shift. Supervisors summarise the reports for clients and calculate the billable hours for each site.
Problem-First Design
Before an architect chooses any pattern, model, or prompt, the architect establishes three things.
-
The job to be done. The architect establishes who performs this work today, how long the work 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 a job, because it names a task and a measurable cost.
-
The constraint set. This set contains latency tolerance, maximum cost, minimum accuracy, acceptable risk, data sensitivity, and regulatory context. Constraints eliminate architectures. A strict latency SLA (service level agreement) excludes long sequential chains, because each step adds to the response time. An audit requirement excludes unpredictable agent paths, because an auditor cannot check a path that changes from run to run. Capture the constraints first. Then the constraints decide a large part of your design.
-
The success criterion. It is a metric, a baseline, and a target. The architect states them 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 that the solution did better than anything. At the security firm, the metric could be the time that a supervisor spends per client summary.
Key Concept
Define how you will measure the solution before you implement it. Distrust any option that starts 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 is the right choice 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 is better in every way. It is cheaper, faster, exactly correct, auditable and testable.
Most production solutions are hybrids: deterministic code around a core that Claude handles. The architect places the boundary between the code and Claude deliberately. At the security firm, Claude summarises the guards' reports and extracts structured fields. Rule-based validation and a deterministic billing calculation use these fields. Sending a rule-bound calculation through a model call adds cost, latency, and a non-zero error rate. It adds zero capability.
Capability Mapping
Requirements map to a small set of task shapes (the kinds of task in the table below). 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 that is built as a chatbot wastes the structure that the task naturally has. The security firm wants the same fields from every report. This is an extraction task. A chatbot would lose the task's schema validation and field-level scoring.
Scoping: Narrow First, Then Expand
Start with the narrowest workflow that delivers measurable value. Prove that the workflow delivers that value, then expand. A targeted workflow embedded in an existing tool is better than 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. Its risk is spread across many areas, and nobody can state its success criterion. At the security firm, the targeted workflow drafts summaries inside the supervisors' existing reporting tool.
In the exam
The Professional exam starts where real projects start: 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. The exam rewards answers that define measurement before implementation. It tests both where a model fits a task and where it does not. Knowing where not to use a model scores as highly as knowing where to use one.
In the most common pair of options, the question names a measured cost driver. One option targets that cost driver directly. Another option proposes something broader and more impressive. The measured, targeted option is the correct answer.
Exam Traps
Proposing a general-purpose assistant when the business case names one high-volume workflow
A general assistant has no baseline to beat and a success criterion nobody can state. A targeted workflow addresses the measured cost driver, so its value is measurable and its risk is bounded. Propose the narrow workflow first.
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, maximum cost, minimum accuracy, data sensitivity, regulatory context
Why: Constraints eliminate architectures before you design anything. A tight latency budget or an audit requirement removes whole groups of solutions.
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 is also the starting point for 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 matched to the task.
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