What you need to know
A business request rarely arrives as a specification. It arrives as "we want AI to handle our claims inbox" or "can Claude help our analysts with quarterly reports". Your job as the architect is to turn that sentence into a design that someone can build, fund and defend. The exam tests whether you do that in the right order: understand the work, test it against what a model can and cannot do, and only then choose technology.
Start from four properties of a language model
Every feasibility question comes back to four properties. Each one is a strength with a matching weakness, and each weakness has a standard design answer.
| Property | Where Claude is strong | Where it is weak | How the design compensates |
|---|---|---|---|
| Next-token prediction | Summarizing, rewriting, explaining, classifying | Precise specifics: names, dates, figures, citations can be plausible and wrong | Citations, verification steps, tool calls to the system of record |
| Training knowledge | Common, well-documented topics | Rare, recent, contested or fast-changing facts, stated with the same confidence | Retrieval, web search, tools or MCP servers as the source of truth |
| Working memory | Anything inside the context window | Nothing outside the window exists for the model | Chunking, progressive loading, summarizing across turns |
| Steerability | Clear, concrete, checkable instructions | Vague goals, long chains of logic, exact arithmetic | Explicit system prompts, structured outputs, code for calculations |
Use the table as a checklist. For each capability the request needs, ask which property it leans on and whether the weakness matters here.
Scope before you design
A reliable sequence keeps the conversation grounded:
- Requirement to capabilities. List what the system must actually do: read a scanned form, check a policy, draft a reply, update a record.
- Capabilities to a sketch. Assign each capability to Claude, to an existing system or to a person (lesson 1.5 covers this split in depth).
- Sketch to boundary conditions. Write down the limits the design depends on: document length, request volume, latency target, accuracy threshold, data that may not leave a region.
- Boundary conditions to scope. The conditions become part of the agreed scope, so everyone knows what the system is and is not built to handle.
Size it before anyone writes code
A rough cost and latency model belongs in the feasibility stage. It needs four inputs: call volume (from the business owner, not a guess), tokens per request (input and output, as a distribution rather than an average), the model tier, and a sensitivity check (what happens if volume doubles or long documents become common). If the projection breaks the budget or the latency target, the architecture changes now, while it is still cheap to change.
Give a clear feasibility verdict
| Verdict | Meaning | What you record |
|---|---|---|
| Feasible as scoped | Every capability fits the model's strengths or has a standard compensating control; cost and latency fit | The assumptions, because the verdict changes if they do |
| Feasible with constraints | It works only under conditions that must be enforced, such as a document size limit or a human review gate | Each constraint and what fails if it is broken |
| Not feasible | A limitation cannot be compensated within budget or scope | The disqualifying constraint, and any scope reduction that would change the answer |
"Not feasible" is a legitimate, valuable answer. It prevents a far more expensive failure later, and naming the scope change that would make it feasible gives the business owner a real choice.
In the exam
Expect a short business scenario followed by four designs. The correct option typically:
- keeps authoritative values (balances, prices, eligibility, order status) in the systems that own them;
- uses Claude for the language work: reading, extracting, classifying, drafting, explaining;
- adds a person where a wrong answer is costly or irreversible;
- matches the verdict to the evidence, including "feasible with constraints" or "not feasible" when a hard limit applies.
Distractors tend to over-assign work to the model, ignore a stated constraint such as a latency target or data residency rule, or choose the most powerful option without checking whether it is needed.
Check your understanding
A retailer wants an assistant that tells customers whether an item is in stock at their local store. Which design deals with the model's knowledge limitation?
Show answer
Answer: B. Stock levels are live state owned by the inventory system, so they are fetched per request. Fine-tuning and nightly prompt dumps go stale between refreshes, and estimating invents a value the business already has.
An assessment finds that every capability suits Claude, but the design only works if scanned contracts stay under 150 pages. Which verdict fits?
Show answer
Answer: A. A design that works only while a condition holds is feasible with constraints. The condition, and what happens when it is broken, become part of the documented architecture.
Which TWO facts should be settled before choosing between a workflow and an agent?
Show answer
Answer: A, B. Volume, latency and the cost of an error are the constraints that decide the pattern. Tooling preferences matter later and do not change what is feasible.
Apply it: Write a feasibility brief
Larkfield Mutual's VP of Claims Operations asks: "Can Claude take over claims intake?" Write a one-page feasibility brief that answers the question with evidence rather than enthusiasm. Use only the facts in the case.
- Quantify today. State the current cost of intake in business units: handler hours a month, the cost of keying errors, and the SLA gap.
Why: a verdict without a baseline cannot be defended, and the value case in lesson 1.6 starts from these numbers.
Done when: you have three numbers, each with its unit and the case fact it comes from. - Check each capability against the four properties. List the capabilities intake needs and, for each, name the property it leans on, the risk, and the compensating design.
Why: this is where "Claude can do it" turns into "Claude can do it if...".
Done when: every capability has a row, and anything that must be exactly right comes from a system rather than the model. - Write the boundary conditions. List the conditions the design depends on, including the regulatory ones.
Done when: each condition is specific enough that someone could tell whether it has been broken. - Give the verdict. Feasible as scoped, feasible with constraints, or not feasible, with one paragraph of reasoning and a rough monthly run cost at Tier M.
Try it on your own work: pick one manual process you know and fill in the same four sections.
Show model answer
1. Baseline
- Handling: 18,000 claims × 22 min = 6,600 handler hours a month, about $316,800 at $48 an hour.
- Errors: 6% × 18,000 = 1,080 claims × 35 min rework = 630 hours, about $30,240 a month.
- SLA: 81% acknowledged within one business day against a 98% target.
2. Capabilities against the four properties
| Capability | Property | Risk | Design |
|---|---|---|---|
| Read emails, forms and scans; extract the 31 fields | Next-token prediction | Plausible but wrong values (policy numbers, dates, amounts) | Structured output against the schema; validate key fields against Policy Admin; low-confidence extractions to a handler |
| Confirm the policy was active on the date of loss | Training knowledge | The model cannot know a policy's status | Policy Admin API call; Claude never decides this |
| Handle long medical reports | Working memory | 120-page packages are near the edge and costly | 95% are under 20 pages; split or route the long tail to a handler |
| Request missing documents, draft the acknowledgement | Steerability | Tone and content drift | Template with fixed sections; structured fields filled from the extraction |
| Decide cover or deny a claim | (not a model task) | Regulator forbids automated denials | Stays with licensed adjusters; out of scope |
3. Boundary conditions
- Key fields (policy number, date of loss, claim amount) are validated against Policy Admin before a claim is created.
- Extractions below the agreed confidence threshold go to a handler; the threshold is set from an evaluation, not guessed.
- Packages over 20 pages follow a separate path (chunked processing or a handler).
- No claim is denied or paid by the system; adjusters decide, and payouts over $10,000 need a senior adjuster.
- EU claimants' data is processed through an EU route; US data stays in the US.
4. Verdict: feasible with constraints. Extraction, completeness checks and the acknowledgement draft play to Claude's strengths; the policy check and every decision stay with systems and people. The conditions above are part of the design. Run cost at Tier M is roughly 18,000 × 9,000 input tokens at $3 per million ($486), the cached 4,000-token prefix at $0.30 per million (about $22), and 1,200 output tokens at $15 per million ($324): about $830 a month, small against a $316,800 baseline. Cost is not the constraint; accuracy on key fields and the regulatory boundary are.