Lab 1 · Domain 1 · 17%

Solution Design & Architecture

The Professional exam does not ask whether you can call the API. It asks whether the system you designed should exist in that shape. This lab is about the first and most expensive decision an architect makes: choosing the simplest architecture that satisfies the requirement, and being able to say out loud why the more impressive one was wrong.

Answer key Lab1_Complete.ipynb
Exam objectives covered
  • Translate business problems into Claude-based AI solutions
  • Design end-to-end architectures (input → processing → output → feedback loops)
  • Select appropriate architectural patterns (workflow, agentic, augmented LLM)
  • Apply decomposition techniques for complex problem solving
  • Align solutions to business value pillars (efficiency, transformation, productivity, cost, performance SLAs)
The exam's default answer is "less." Across every domain, when one option adds a capability and another removes one, the removing option is usually correct. That is not a quirk of item writing; it is the stated position of the credential: an architect is measured on what they chose not to build. Read the guide's own Sample 1 (Lab 5) if you doubt it: the right answer deletes two tools.

1. From Business Problem to Architecture

Candidates fail this domain by starting at the model. The discipline runs the other way: you start at the decision the business wants changed, and you do not name a Claude feature until you have named that decision.

A usable sequence, and the one the objectives imply:

StepThe questionFailure if skipped
1. DecisionWhat action or judgment happens today, by whom, how often?You build a chatbot nobody's workflow has room for.
2. Value pillarWhich pillar does this move: efficiency, transformation, productivity, cost, or an SLA?The project cannot be defended at renewal.
3. Ground truthHow will anyone know if an output was right?You cannot evaluate, so you cannot improve. See Lab 6.
4. DeterminismAre the steps enumerable in advance?You reach for an agent where a workflow was sufficient.
5. Blast radiusWhat is the cost of a wrong output reaching production?You skip the human-in-the-loop gate the regulator required.

The five business value pillars

The blueprint names them explicitly, so know them as a vocabulary, not a list to recite. They are the language you use to justify an architecture to someone who does not care about tokens.

PillarYou are claimingMeasured by
EfficiencyThe same output, fewer human hoursHandle time, throughput per FTE
TransformationAn output that was previously impossibleNew capability shipped; revenue from it
ProductivityThe same humans produce more or betterOutput per person, quality scores
CostThe same output, less moneyCost per resolved ticket / per document
Performance SLAThe same output, inside a latency or availability boundp95 latency, uptime, error budget
Cost and Performance SLA are usually in tension, and the exam knows it. Prompt caching is one of the few levers that moves both at once; it cuts per-request cost and time-to-first-token, which is precisely why the guide's Sample 2 uses it. Batching moves cost and destroys latency. A bigger model moves quality and destroys both. When an item says "addresses both," look for caching.

2. Three Patterns, in Order of Preference

There are exactly three patterns in the blueprint, and they are a ladder. Climb only when the rung below cannot hold the requirement.

PatternWho decides the control flowUse whenCost of misuse
Augmented LLM
one call, enriched
Nobody — there is no flow Classification, extraction, summarization, Q&A over retrieved context Almost none. This is the floor.
Workflow
your code
You, in advance The steps are enumerable and stable: OCR → validate → write row Rigidity. Add a branch, change the code.
Agentic
the model
Claude, per turn The path is genuinely unknown until the work begins Cost, latency, non-determinism, and an audit trail nobody can reconstruct

The four-part test for whether an agent is warranted (every one must pass):

  1. Complexity. Is the task hard to fully specify in advance? "Turn this design doc into a PR" qualifies. "Extract the title from this PDF" does not.
  2. Value. Does the outcome justify the higher cost and latency? An agent that saves ninety seconds of a $30/hr task, at $0.40 a run, is a loss.
  3. Viability. Is the model actually capable here? If it fails the task in a single call with perfect context, a loop will fail it many times, expensively.
  4. Cost of error. Can mistakes be caught and recovered (tests, review, rollback)? An agent with irreversible actions and no gate is a liability, not an architecture.
"The steps never change" is the tell. When a scenario describes a fixed nightly sequence and offers you an autonomous agent, the agent is the distractor; it adds model-directed indirection to a path you already know. Conversely, when a scenario says "the number of steps depends on what the previous step returns," a workflow cannot express it and the agent is correct.

3. End-to-End: The Feedback Loop Is Not Optional

The objective is written as input → processing → output → feedback loops. Most candidates can draw the first three arrows. The fourth is what separates the credential from a tutorial.

A production Claude architecture has five planes. If your diagram is missing one, an exam item is waiting for it:

PlaneContainsThe question it answers
IngressAuth, rate limits, input validation, PII redaction, untrusted-content isolationWhat is allowed in?
ContextRetrieval, caching, prompt assembly, token budgetWhat does the model see?
ReasoningModel choice, effort, tools, orchestrationWhat does the model do?
EgressSchema validation, guardrails, human-in-the-loop gates, action executionWhat is allowed out?
FeedbackTraces, evals, cost/latency telemetry, labelled failures flowing back into the eval setHow do we know, and how do we improve?

The feedback plane is what makes the other four improvable. Without it you have no eval dataset (Lab 6), no way to distinguish a retrieval regression from a prompt regression (Lab 7), and no evidence for the stakeholder conversation (Lab 9). Design it on day one, because the data it needs (the trace, the input, the human's correction) is unrecoverable if you did not capture it.

4. Decomposition

Decomposition is the technique the objectives name for "complex problem solving," and it has one governing rule: decompose along the seams where verification is possible.

Splitting a task into three steps is only useful if you can independently tell whether each step was right. A pipeline of three unverifiable steps is worse than one unverifiable step, because errors compound silently and you cannot localize them.

SeamSplit whenExample
VerifiabilityAn intermediate output can be checked by code or a humanExtract structured fields, validate schema, then reason over them
TrustOne part handles untrusted input and another holds privilegeSummarize the scraped page in an isolated call; never let it reach the tool-calling turn
CostSteps have wildly different difficultyRoute classification to Haiku, the hard synthesis to Opus
ContextA subtask needs a large corpus the parent must not carrySubagent reads 40 files, returns a 200-token finding (Lab 2)
LatencySteps are independentFan out three retrievals concurrently, then synthesize once
Do not decompose for elegance. Every seam adds a serialization boundary, a place for context to be lost, and a call to pay for. If you cannot name which of the five seams above a split sits on, it is not a decomposition, it is a diagram.

5. Worked Call: The Claims Triage System

An insurer processes 4,000 claims a day. Today an adjuster reads each claim packet (a PDF, sometimes photographs) and routes it to one of four queues: auto-approve, standard review, fraud review, or request-more-information. Adjusters agree with each other about 85% of the time. Regulation requires that any denial be attributable to a named human.

Work the sequence rather than reaching for a pattern.

  1. Decision: route a claim to one of four queues. 4,000/day. Not a chatbot, a classifier with evidence.
  2. Value pillar: primarily efficiency (adjuster hours per claim). Secondarily an SLA: claims must be routed within an hour of receipt. Not transformation; nothing new becomes possible.
  3. Ground truth: exists, and it is imperfect. Historical routings, and an 85% inter-adjuster agreement ceiling. That 85% is the target, not 100%. An architecture that promises 99% accuracy against labels humans only agree on 85% of the time is promising to overfit one adjuster's opinion.
  4. Determinism: the steps are fixed: parse the packet, retrieve the policy terms, classify, emit a rationale. No step's existence depends on a previous step's output.
  5. Blast radius: a wrong auto-approve costs money; a wrong denial is a regulatory event.

So: a workflow, whose classification step is an augmented LLM call (retrieved policy terms + the packet), with a human-in-the-loop gate on exactly one branch. Not an agent. Nothing about the path is unknown in advance.

PlaneDecisionBecause
IngressPDF + images accepted; claimant PII redacted before the model call where not needed for the decisionMinimizes data exposure and the compliance surface (Lab 8)
ContextPolicy terms retrieved by policy ID: a lookup, not a vector searchThe query pattern is an exact key. Embedding it would be architecture theatre (Lab 4)
ReasoningOne Opus call with structured output; the four queues as an enum; a required rationale and cited_clauseForcing a citation makes the output checkable, which creates the eval seam
EgressAuto-approve executes. Denial and fraud routes require a named adjuster to confirm.The regulation says attributable to a human. That is an architectural constraint, not a UX preference
FeedbackEvery adjuster override is written to an eval set with the original packet and the model's rationaleOverrides are free labelled data. They are also the only early warning of drift

The structured-output call is where the design becomes code. Note that the schema is the architecture: it is what makes step 3's rationale auditable and step 5's feedback loop possible.

Current — structured output via output_config.format
python
import anthropic

client = anthropic.Anthropic()

TRIAGE_SCHEMA = {
    "type": "json_schema",
    "schema": {
        "type": "object",
        "properties": {
            "queue": {
                "type": "string",
                "enum": ["auto_approve", "standard_review",
                         "fraud_review", "request_information"],
            },
            # A citation the downstream check can verify against the policy text.
            "cited_clause": {"type": "string"},
            "rationale": {"type": "string"},
            "confidence": {"type": "number", "minimum": 0, "maximum": 1},
        },
        "required": ["queue", "cited_clause", "rationale", "confidence"],
        "additionalProperties": False,
    },
}

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    thinking={"type": "adaptive"},
    output_config={"effort": "high", "format": TRIAGE_SCHEMA},
    system=[
        # Stable prefix first, so it can be cached across all 4,000 claims/day.
        {"type": "text", "text": TRIAGE_POLICY_MANUAL,
         "cache_control": {"type": "ephemeral"}},
    ],
    messages=[{"role": "user", "content": claim_packet_blocks}],
)

Three architectural choices are visible in that call, and each one is an exam item waiting to happen. The policy manual sits in the system block, before anything that varies, with a cache breakpoint, because caching only works on a stable prefix (Lab 3). effort is nested inside output_config, alongside format. And cited_clause is required, which converts an opinion into something a validator can reject.

Confidence scores from a language model are not calibrated probabilities. Do not route on confidence > 0.9 and call it a risk control. Use it to rank a review queue, never to bypass one. The regulator's requirement is a human on the denial path; a float the model produced about itself does not discharge it.

6. Design Exercise

Self-driven lab Lab1_Self_Driven_Lab.ipynb

Objective: produce a one-page architecture for a scenario you have not seen, and defend the pattern choice. About 60 minutes. This is the exercise the exam guide itself recommends: "practice architectural decision-making."

Scenario. A hospital network wants to reduce the time clinicians spend writing discharge summaries. Today a physician dictates notes; a transcriptionist produces a draft; the physician edits and signs. Volume is 900 discharges a day across 11 facilities. Summaries must be signed by the attending physician. Records are PHI under HIPAA. Physicians will abandon any tool that takes more than 20 seconds to produce a draft.

  1. Run the five-step sequence. Write one sentence per step. Name the decision, the pillar, the ground truth, whether the steps are enumerable, and the blast radius. Do not proceed until step 3 has an answer. If you cannot say how you would know a summary was good, you cannot build this.
  2. Choose the pattern and write the sentence that kills the other two. "This is not agentic because ___." "This is not a bare augmented LLM call because ___." Force yourself to say it.
  3. Draw the five planes. For each, name one concrete decision. At ingress, what do you do with the patient identifiers? At egress, what is the gate, and what does the physician actually see?
  4. Reconcile the SLA with the model choice. Twenty seconds is a hard bound. Which of streaming, caching, model tier, and effort level move it, and which of those degrade quality? Which one moves latency and cost together?
  5. Design the feedback loop before you build. The physician edits the draft before signing. That edit is a labelled correction. Write down exactly what you persist, and note what you must not persist under HIPAA without a BAA and a retention policy.
  6. Now defend the cost. 900 drafts a day. Estimate input tokens (the chart), output tokens (the summary), and the cache hit rate. State the pillar you are claiming and the number you would put in front of a CFO. Then state what would falsify it.

Step 2 is the one the exam tests. Step 6 is the one that gets the project funded.

Check Yourself

Exam-style items. Commit to an answer before expanding.

A logistics firm runs a nightly job that reads each shipping manifest, calls a customs-code lookup service, and writes a classified row to a warehouse. The three steps are the same for every manifest and have not changed in two years. Which architecture is most appropriate?
  • A. An autonomous agent that selects which tool to call on each turn.
  • B. A workflow in which application code invokes each step in a fixed order.
  • C. A multi-agent system with one subagent per manifest field.
  • D. A single augmented LLM call with all three capabilities exposed as tools.

Correct: B. The steps are fully enumerable and stable, so the control flow belongs in your code. That is the definition of a workflow, and it buys determinism, a trivial audit trail, and the lowest cost per manifest.

A hands control of a known path to the model, paying for tokens and non-determinism to rediscover a sequence you already wrote down. C multiplies that cost by the number of fields and introduces coordination overhead for a task with no coordination problem. D is subtler and worth sitting with: exposing the steps as tools still lets the model choose whether and in what order to call them, so you have bought agentic non-determinism while telling yourself you built a single call. The rung of the ladder you want is the one where you own the sequence.

An architect proposes an agentic system for a customer-refund process. Refunds are irreversible, there is no staging environment, and the team has no way to detect an incorrect refund until the monthly reconciliation. Which of the four agent-viability criteria does this proposal most clearly fail?
  • A. Complexity — refund processing is too simple to require an agent.
  • B. Viability — Claude is not capable of processing refunds.
  • C. Cost of error — mistakes cannot be caught or recovered from.
  • D. Value — the outcome does not justify the latency.

Correct: C. The scenario is engineered around one fact: an incorrect action is irreversible and undetectable for up to a month. That is precisely the cost-of-error criterion; agents are appropriate where errors surface quickly and can be rolled back, reviewed, or tested against.

A may or may not be true; the scenario gives you nothing about complexity, and a refund process can be genuinely branching. B is unsupported and, in general, a distractor pattern to distrust; "the model can't do it" is rarely the architectural objection. D speaks to latency, which the scenario never mentions. The discriminating fact is always the one the scenario spends its words on.

A retailer's support system sends the same 12,000-token policy corpus with every request, followed by a short customer question. Leadership wants lower cost per ticket and a faster first response. Which two changes address both goals? (Choose two.)
  • A. Place the policy corpus at the start of the system prompt and enable prompt caching.
  • B. Move the entire workload to the Batches API for the 50% discount.
  • C. Stream the response so the customer sees tokens as they are generated.
  • D. Truncate the policy corpus to its first 2,000 tokens.
  • E. Raise output_config.effort to max so answers are right the first time.

Correct: A and C. Caching a stable prefix cuts both per-request cost (reads bill at roughly a tenth of input) and time-to-first-token, because the prefix does not have to be reprocessed. Streaming does not reduce cost, but the goal was a faster first response; streaming reduces perceived latency to the first token, which is the metric leadership described.

B halves cost and annihilates latency: batches have no SLA and may take hours, so a customer is not waiting on one. D reduces cost by discarding policy the system needs to answer correctly; you have not optimized, you have changed the product. E raises token spend and latency in exchange for quality nobody asked for. The trap is B: "50% discount" is a real fact attached to the wrong requirement.

A team decomposes document processing into four sequential Claude calls: classify, extract, summarize, recommend. Each call's raw text output is passed as the next call's input. Accuracy is worse than the single call it replaced. What is the most likely architectural error?
  • A. The calls should run in parallel rather than sequentially.
  • B. The decomposition created boundaries where no intermediate output can be independently verified, so errors compound undetected.
  • C. Four calls cost four times as much, and cost is the real problem.
  • D. A larger model at each step would restore the lost accuracy.

Correct: B. Decomposition pays off only at seams where an intermediate result can be checked (by a schema, a validator, or a human). Passing unverified free text down a chain gives every stage a chance to amplify the previous stage's error, with no place to catch it. The single call at least reasoned over the source document rather than over a lossy paraphrase of it.

A is impossible: each step consumes the previous step's output, so the chain is inherently serial. C is true and irrelevant; the stated symptom is accuracy, not cost. D papers over a structural defect with spend; the errors still compound, just more articulately. The fix is to give the extract step a required schema so its output can be rejected before it poisons the rest.

Key Takeaways

  • Start at the decision the business wants changed, not at the model. Name the value pillar before you name a feature.
  • The three patterns are a ladder: augmented LLM → workflow → agentic. Climb only when the rung below cannot hold the requirement.
  • An agent needs all four of complexity, value, viability, and a survivable cost of error. Irreversible actions with no detection is the classic disqualifier.
  • "The steps never change" means workflow. "The next step depends on the last result" means agent. Exposing steps as tools does not make a workflow; it makes an agent you did not admit to.
  • Five planes: ingress, context, reasoning, egress, feedback. The feedback plane is the one candidates omit and the one that makes the other four improvable.
  • Decompose along seams where verification is possible: verifiability, trust, cost, context, latency. A chain of unverifiable steps is worse than one unverifiable step.
  • Ground truth caps your accuracy target. If humans agree 85% of the time, 99% is overfitting, not excellence.
  • Caching is the rare lever that improves cost and latency together. Batching trades latency for cost. A bigger model trades both for quality.