1.1 From Business Problem to Solution Design

Picture a stakeholder walking into your office and saying, "We want to use Claude to handle our support inbox." It's tempting to immediately start sketching: an agent, a tool for the ticketing system, maybe a multi-agent crew that triages and responds. Stop. You don't yet know enough to design anything, because "we want to use Claude" is not a business requirement — it's a solution looking for a problem. The actual requirement is hiding behind it: reduce response time on tier-1 tickets, or cut the backlog that's currently costing the support team overtime, or something else entirely. Until you know which, every architecture you sketch is a guess.

This is the discipline that separates an architect from an enthusiast: you start from the business OUTCOME, and you let the outcome — plus its constraints — dictate the technology, not the other way around. An architect's first move on any brief is never "which pattern should I use?" It's "what does success actually look like, and what happens if we get it wrong?" Only once those questions are answered does pattern selection (which is Lesson 1.2) even become a meaningful question.

This matters because the exam is written from exactly this stance. A scenario question will hand you a business goal and a pile of constraints, and the wrong answers will almost always be technically impressive but unjustified by anything in the prompt — "stand up a five-agent hierarchy" for a task that a single prompt could handle. The right answer is nearly always the boring one that's actually anchored to what was asked.

With the stance settled, the actual flow an architect follows has three moves, always in this order. First, ELICIT the requirement — get the stakeholder to state the business outcome in terms you can act on, not in terms of a technology. "Cut average ticket resolution time from four hours to under one" is elicited; "use Claude" is not. Second, DERIVE the functional and non-functional requirements that outcome implies — what must the system actually do (functional), and under what conditions must it do it (non-functional: how fast, how reliably, how securely, how cheaply). Third, and only third, CHOOSE the architecture that meets those requirements at acceptable cost.

Notice the phrase "at acceptable cost." There is almost always more than one architecture that could technically satisfy a set of requirements — you could solve a simple classification task with a lone prompt, or with a five-stage agentic pipeline that also happens to work. Both "work." The architect's job is to find the one that meets the bar without paying for capability nobody asked for. That's the throughline of this entire domain: the simplest design that satisfies the constraints wins, and every dollar and millisecond of complexity above that has to earn its place.

• 1.ELICIT — restate the ask as a business outcome with a measurable definition of success, independent of any specific technology.
• 2.DERIVE — translate that outcome into functional requirements (what the system must do) and non-functional requirements (how well, how fast, how safely it must do it).
• 3.CHOOSE — select the architecture, pattern, model tier, and integration approach that satisfies those requirements at the lowest complexity and cost that still clears the bar.

"Derive the requirements" is easy to say and easy to do badly, so Anthropic's guidance gives you six concrete dimensions to interrogate before you let yourself sketch an architecture. Think of these as the six questions a good architect asks in the first five minutes of any scoping conversation — miss one, and you'll find out the hard way, usually in production.

These aren't academic categories — each one has direct teeth. A hard latency SLA rules out anything with an unpredictable multi-step agentic loop. A tight cost ceiling on a high-volume job rules out routing everything to the largest model. High data sensitivity forces decisions about where retrieval happens and what leaves your network (a Domain 5 concern, but the trigger is discovered right here in Domain 1). Extracting these six dimensions is the concrete, checklist version of "elicit and derive" from the previous section.

Here's the payoff for extracting those six dimensions: they aren't just background color, they are the inputs that mechanically decide several major design choices you'll be tested on across the whole certification. This is worth sitting with, because it reframes "architecture" from a matter of taste into a matter of arithmetic.

Latency and volume together decide realtime vs. batch processing — a sub-second interactive SLA forces a realtime path; a nightly reconciliation job with no user waiting can batch, which opens up cheaper, higher-throughput options. Cost ceiling and quality bar together bound the model tier (the subject of Domain 2) — you cannot promise frontier-model accuracy on a budget that only clears a smaller tier, and pretending otherwise is how projects fail their own numbers. Volume, latency, and existing systems shape the integration protocol (Domain 3) — a high-throughput backend integration looks nothing like a low-volume interactive assistant embedded in a chat UI. And criticality and quality bar decide where a human sits in the loop (Domain 5) — a high blast-radius, hard-to-verify output needs a human checkpoint that a low-stakes, easily-verified one doesn't.

The exam trap embedded here is subtle: it's not that you'll forget these connections exist, it's that you'll be handed a scenario, correctly identify the constraint, and then pick an architecture that ignores it anyway because it "sounds" more sophisticated. Constraints aren't decoration on the question — they are the answer key.

One more distinction belongs in this first lesson, because it silently inflates or deflates every requirement you just derived: are you scoping a proof of concept or a production system? It's an easy trap to fall into treating them as the same design with a different label — get a demo working, ship the demo. They are not the same design.

A proof of concept exists to answer one question — "can this approach plausibly work?" — as cheaply and quickly as possible. It's allowed to skip almost everything that isn't the core reasoning step. A production system has to actually survive contact with real users, real load, real edge cases, and real failure modes, indefinitely. That means evaluation (how do you know quality hasn't silently regressed), observability (how do you see what's happening when something goes wrong), security (how do you stop untrusted input from becoming an instruction), and lifecycle (how does this get updated, versioned, and eventually retired) are not "nice to have later" — they are first-class requirements from day one of a production design, exactly on par with the feature itself.

Task Statement 1.1 questions almost always take the same shape: a paragraph describing a business situation, sometimes with numbers attached (a latency figure, a volume figure, a sensitivity note), and a set of answer choices where most jump straight to a technology. Two traps recur constantly and they're really the same trap wearing different clothes — defaulting to sophistication before the requirements justify it.

• •Jumping to "use an agent" or "use the biggest model" before the requirements justify it. ✗ Any answer that reaches for autonomy or scale as a default. ✓ The answer that's explicitly anchored to a stated constraint in the scenario — cite the constraint in your own head before picking.
• •Treating a proof-of-concept design as production-ready. ✗ An answer that ships a working demo as the final design when the scenario describes real users, real load, or ongoing operation. ✓ The answer that adds evaluation, observability, security, and lifecycle as first-class parts of the design, not afterthoughts.

Hold onto one habit for the rest of Domain 1, and honestly the rest of the exam: before you evaluate any answer choice, ask yourself which of the six dimensions from 1.1.3 the scenario is actually telling you about, and let that dimension eliminate the answers that ignore it. Every remaining lesson in this domain — the three patterns, end-to-end architecture, multi-agent orchestration, decomposition, business value — is really just a deeper toolkit for the CHOOSE step you learned about here.