Solution Design & Architecture · Lesson 1 of 6

2.1 - Translating a Business Problem into a Claude-Based Solution

Turn a vague business goal into a scoped, testable Claude solution: decompose it into tasks, decide per task whether Claude owns, assists or is not used, and write success criteria you can measure.

An architect's first deliverable on a Claude engagement is not a prompt or a diagram. It is a problem statement a team can test. Sponsors arrive with goals such as "cut support costs" or "automate month-end close". Those are outcomes, not tasks, and no model choice or prompt can be evaluated against them. This lesson covers the translation step: business goal → tasks → a fit decision per task → measurable success criteria → a scoped first release. Structured stakeholder discovery is lesson 5.1, and choosing the architectural pattern once the task is understood is lesson 2.3.

Step 1: Decompose the goal into tasks

Before proposing anything, write the goal down as five facts:

Outcome and owner: the business metric that moves, and the person accountable for it.
Workflow today: the steps, the volumes, and who or what performs each one.
Artifact or decision per step: what each step must produce.
Cost of a wrong output: rework, money, harm, regulatory exposure.
Baseline: current cycle time, error rate and cost per case. Without it you cannot show improvement.

Then split the workflow into tasks and treat the task, not the job title or the department, as the unit of design. "Automate support" becomes: classify and route the ticket, draft a first reply from policy, look up order status, issue the refund, decide the exceptions. Each has different inputs, a different cost of error and a different answer to "should Claude own this?". Scenario questions in this area are usually solved by noticing that the sponsor's one sentence hides several tasks with different answers.

Step 2: Fit and non-fit signals

Dimension	Points toward Claude owning the task	Points toward Claude assisting, or not being used
Data	Text, documents, transcripts or tables that you can place in the request	Facts that change by the minute in a system Claude cannot reach on its own
Nature of the work	Judgement over language: summarise, classify, extract, draft, compare against criteria	Exact, auditable arithmetic or rule execution: totals, tax, eligibility formulas
Rules	Too many or too fuzzy to hand-code; input varies a lot	Fully specified and stable, so ordinary code is cheaper, faster and deterministic
Error tolerance	Errors are cheap to detect and fix, or a verifier or human sits downstream	One error is costly and nothing checks it
Accountability	The output is a draft or recommendation	A credentialed person or legal entity must own the decision (clinical, legal, compliance sign-off)
Economics	High volume, or high expert time per item, so a modest quality bar still pays	Low volume, or the task already takes seconds and integration costs more than it saves

Read the right-hand column as a routing instruction, not a veto. "Live data" usually means add a tool or a retrieval step (lesson 2.3 and Domain 1). "Exact arithmetic" means Claude extracts and code computes; a language model is not a deterministic calculator, and the code execution tool or your own code should do the computing. "Regulated sign-off" means Claude drafts and a human decides (lesson 4.3). The non-fit is with a bare prompt, not with the project. Prompting harder changes none of the right-hand-column facts.

Common exam distractor

When a scenario describes a live-data need, a deterministic calculation or a regulated sign-off, the tempting answers are "write a better prompt", "give Claude more context" or "use a larger model". None of them changes the underlying constraint. The right answer changes the architecture around Claude: a tool, deterministic code, or a human gate. The mirror-image distractor is just as common: rejecting Claude for the whole workflow because one step is a non-fit.

Step 3: Write success criteria you can test

Anthropic's guidance is that success criteria should be specific, measurable, achievable and relevant, and that most use cases need several criteria at once. The documentation lists common dimensions: task fidelity, consistency, relevance and coherence, tone and style, privacy preservation, context utilization, latency and price. An architect adds two things on top: a baseline to beat and an explicit error-tolerance statement that says which mistakes are acceptable and which are never acceptable.

Vague	Testable
"Drafts should be good"	Agents accept the draft with no or light edits on at least [target]% of a held-out set of [n] real tickets, judged against a written rubric
"It must be fast"	p95 time to first token under [n] seconds in the chat surface; nightly job finishes before [time]
"It must be safe"	No refund above [limit] is issued without human approval; every case in the adversarial set is handled
"It must be cheaper"	Cost per resolved case, including human review time, at or below today's baseline at target volume

The bracketed targets are yours to set from the baseline and the business case; the point is that each one can be checked by a script and a dataset. Anthropic's eval guidance says to mirror the real task distribution including edge cases, automate grading where possible, and prefer more questions with automated grading over fewer hand-graded ones. Its write-up on agent evals suggests starting with a modest set (20 to 50 tasks) drawn from real failures and the manual checks you already run. Detailed metric and dataset design is Domain 3; here the skill is refusing to build until at least a seed set exists.

Key concept: the unit of design is the task

A business goal decomposes into tasks, and each task gets one of three dispositions: Claude owns it (verified by evals), Claude assists it (a human or a system of record stays the source of truth), or Claude is not used (deterministic code is the better tool). A defensible recommendation names the disposition and the deciding fact: data freshness, determinism, accountability or error cost.

Step 4: Scope the first release

Anthropic's guidance on agentic systems is to start with the simplest solution and add complexity only when it demonstrably improves outcomes, because more elaborate systems trade latency and cost for performance. Apply the same discipline to scope:

Thin slice, riskiest assumption first. Test first-draft quality on the three highest-volume ticket categories, not the whole queue.
Keep the source of truth. Run in shadow mode (Claude's output is logged and compared, not acted on) until measurements justify removing the human or the system of record.
Test across real variation. One clean demo shows the task is possible, not that the criteria are met. Sample instances across the natural distribution, including the ugly ones.
Pre-commit the decision rule. Write go, no-go and rollback thresholds before the pilot so they are not renegotiated after the data arrives.
Record what you chose not to automate and why. That list is the seed of the decision record in lesson 5.2.

Worked example: month-end reconciliation

The CFO says: "use Claude to automate reconciliation". Decomposed, the workflow has four tasks. Extract line items from bank statements and vendor PDFs: language and layout understanding, a strong Claude fit, checkable against last quarter's labelled data. Match statement lines to ledger entries: fuzzy descriptions favour Claude, but proposed matches need a confidence signal and a review queue. Compute totals and variances: exact, so code does it. Explain and approve exceptions: Claude drafts the explanation, a named accountant signs off. The project is viable, but only as a mix of three dispositions. A team that hands the whole job to a single prompt would fail on the compute step no matter how good the prompt is, and would have no criteria to notice.

Exam traps

Treating a task that needs live data, exact calculation or regulated sign-off as fixable with a better prompt, more context or a larger model

Those constraints are architectural. The fix is a tool or retrieval step for live data, deterministic code for calculation, and a human decision-maker for regulated sign-off, with Claude assisting rather than owning the step.
Declaring success criteria such as 'high accuracy' or 'users like it' with no threshold, dataset or baseline

Criteria must be specific and measurable, and they only mean something against an eval set and a baseline. Without them nobody can tell whether the solution beats the current process or whether a change made it worse.
Rejecting Claude for a whole workflow because one step is a poor fit

Fit is judged per task. The usual correct design keeps Claude on the language-heavy tasks and assigns the poor-fit step to code, a tool or a human. Rejecting the whole project throws away value; handing the whole workflow to Claude ignores risk.
Choosing the architecture (agents, multi-agent, RAG) before the problem statement and success criteria exist

The pattern follows from the task's characteristics and the measurable targets, not the other way around. Starting from an architecture leads to over-engineering, and to systems that cannot be evaluated.

Practice question

A finance director asks you to 'use Claude to automate month-end reconciliation'. In a pilot, Claude reads bank-statement PDFs and ledger exports well, but when asked to total each account and report variances it is occasionally off by small amounts, and the controller says every variance must be defensible in an audit. What should you recommend first?

A Decompose the workflow: Claude extracts and proposes matches, code computes totals and variances, an accountant approves exceptions; then set measurable criteria on last quarter's labelled data Correct
This assigns each task the disposition that fits it (Claude owns extraction, Claude assists matching and explanation, code owns arithmetic, a human owns sign-off) and makes the pilot testable against a baseline. It keeps the value and removes the audit risk.
B Add an instruction to double-check all arithmetic and re-run the pilot, since the extraction quality shows the task is a good fit and the arithmetic slips are small
Prompting harder does not make a language model a deterministic, auditable calculator. The constraint is the nature of the compute step, so the fix has to be architectural.
C Decline the project, because reconciliation involves exact arithmetic and audit requirements that a language model cannot satisfy, so the only defensible option is to keep the process manual
Only one task in the workflow is a poor fit for Claude. Rejecting the whole project ignores the extraction, matching and explanation tasks where Claude adds clear value.
D Switch to the largest available model for the whole workflow and accept the higher cost, because the variance errors show the current model is too weak for finance work
A larger model may reduce slips but cannot turn probabilistic generation into deterministic, auditable calculation. It also raises cost without addressing the missing criteria or the sign-off requirement.

Build exercise: Write a use-case fit brief and go/no-go plan

Intermediate · 75 minutes

You'll practice:

Decompose a vague business goal into tasks with inputs, outputs and cost of error
Assign each task a disposition (Claude owns, Claude assists, not Claude) and name the deciding fact
Write multidimensional, measurable success criteria with a baseline and an error-tolerance statement
Stand up a seed eval set and a first measurement before any architecture is chosen
Define a thin first release with pre-committed go, no-go and rollback thresholds

Pick a business goal (for example 'reduce time spent answering internal HR policy questions') and write the five-fact statement: outcome and owner, workflow today with volumes, artifact per step, cost of a wrong output, and baseline.

Everything downstream is judged against these facts. Teams that skip the baseline cannot later show improvement, and teams that skip the cost of error cannot justify a human gate.

You should see: A half-page statement where every fact is a concrete number, name or sentence you could defend, with any unknowns listed as open questions to take to lesson 5.1 style discovery.

Hints

Which of the five facts do you currently know only as a feeling rather than a number?

Interview or imagine the process owner: how many requests per week, how long each takes, what happens when an answer is wrong. Write unknowns down explicitly instead of guessing.

Example: Outcome: cut median time-to-answer for HR policy questions (owner: HR operations lead). Workflow: ~[n]/week arrive by email; an HR generalist searches the handbook and replies. Artifact: a policy-grounded answer. Cost of error: a wrong leave-entitlement answer causes payroll rework and employee distrust. Baseline: median [x] hours, [y]% reopened.

Break the workflow into 5 to 8 tasks. For each, record the input, the output, and the cost of a wrong result.

The task is the unit of design. A single 'automate the process' entry hides tasks with very different fit and risk.

You should see: A table with one row per task, for example: classify the question, retrieve the relevant policy section, draft the answer with a citation, check eligibility against the employee record, approve exceptions.

Hints

Where in the workflow does the input change form, or a different person or system take over?

Split at every point where the artifact changes type (question, policy text, draft, decision) or where a different source of truth is consulted.

Tasks: 1 classify question type; 2 retrieve policy passages; 3 draft cited answer; 4 look up employee's tenure and region in the HR system; 5 decide non-standard exceptions. Cost of error rises steeply from task 3 to task 5.

Classify each task as Claude owns, Claude assists, or not Claude. Write the deciding fact (data freshness, determinism, accountability, error cost, economics) and, for assist or not, the mechanism that takes over (tool, code, human gate).

This is the core judgement the task statement tests: fit is decided per task and justified by a specific constraint, not by a general feeling about AI.

You should see: Every row has a disposition, a deciding fact and a mechanism. At least one task should not be 'Claude owns', and the reason should not be 'the prompt is not good enough'.

Hints

For each task ask: is the source of truth text I can supply, a live system, a formula, or a person's accountable decision?

Map the answer: text you can supply, and errors easy to catch, points to owns; live system points to a tool (assist); a formula points to code; an accountable decision points to a human.

Example: 1 classify: owns (text in, cheap to check). 2 retrieve: assists (needs retrieval over the handbook; Domain 1). 3 draft: owns behind a citation check. 4 employee lookup: tool call, not Claude's memory. 5 exceptions: not Claude, a person decides; Claude may summarise the case.

Write four testable success criteria covering task quality, latency, cost per resolved case (including human time) and a safety or error-tolerance rule. Each must name a metric, a target, a dataset and the baseline it improves on.

Anthropic's guidance is that criteria be specific, measurable, achievable and relevant, and that most uses need several. Without them, 'it seems good' becomes the launch decision.

You should see: Four criteria in the form: metric, target, measured on which dataset, versus which baseline. The safety rule states which errors are never acceptable.
Hints
1. ```
Could a script decide pass or fail for each criterion? If not, what is missing?
```
2. ```
Turn adjectives into metric plus threshold plus dataset. Include the cost of the human reviewer, otherwise the cost criterion flatters the design.
```
3. ```
Example: (1) Answer accepted with light or no edits on at least [target]% of 40 held-out real questions, rubric-graded. (2) p95 time to first token under [n] s. (3) Cost per resolved question, including reviewer minutes, at or below baseline. (4) No answer that states an entitlement contradicting the policy text; measured on 10 adversarial cases.
```

Build a 20-case seed eval set for the task you classified as Claude owns, and run a first measurement with a small exact-match harness.

A seed set forces the criteria to be concrete and gives the first data point on fit before any architecture is committed. Anthropic recommends starting small from real cases rather than waiting for a large dataset.

You should see: A cases.json file with 20 labelled real or realistic inputs (include a few awkward ones) and a printed score such as 15/20 with the misses listed for review.

Hints

Where will you get realistic inputs? Which ones did the current team find awkward?

Store input plus expected label per case, call the model once per case with a short system prompt, compare normalised output with the label, and print the misses so you can read them.

import anthropic, json
client = anthropic.Anthropic()
MODEL = 'claude-sonnet-5'  # check the models overview page for current IDs
def classify(q):
    r = client.messages.create(model=MODEL, max_tokens=20, system='Classify the HR question as one of: leave, payroll, benefits, other. Reply with the label only.', messages=[{'role': 'user', 'content': q}])
    return next(b.text for b in r.content if b.type == 'text').strip().lower()
cases = json.load(open('cases.json'))  # [{'input': '...', 'label': 'leave'}, ...]
misses = [c for c in cases if classify(c['input']) != c['label']]
print(f'{len(cases) - len(misses)}/{len(cases)} correct')
for m in misses: print('MISS:', m)

Write the first-release scope and decision rule: the thin slice, the shadow-mode plan, go and no-go thresholds tied to your criteria, the rollback trigger, and the list of tasks you deliberately did not automate.

Pre-committing the decision rule stops thresholds being renegotiated after results arrive, and the not-automated list documents the judgement calls for later stakeholders.

You should see: A one-page plan: slice (for example only leave and payroll questions), shadow-mode duration or volume, thresholds copied from your criteria, rollback trigger, and a short 'not automated and why' list.
Hints
1. ```
What is the smallest slice that would still surprise you if it failed?
```
2. ```
Choose the highest-volume category where errors are cheap to catch, run in shadow mode against real traffic, and state numerically what result means go, no-go or roll back.
```
3. ```
Slice: leave and payroll questions only. Shadow mode: Claude's draft is logged next to the human reply for [n] weeks. Go: criteria 1 to 4 met on the seed plus shadow data. Rollback: any answer that contradicts policy reaches an employee. Not automated: exception approvals and anything involving legal or medical situations.
```

Sources

Define your success criteria (Claude API docs) - Anthropic
Create strong empirical evaluations (Claude API docs) - Anthropic
Building effective agents - Anthropic
Demystifying evals for AI agents - Anthropic