Solution Design & Architecture

Koko: Here is the one instinct that runs through everything in Solution Design and Architecture: every architectural choice is a purchase. Autonomy is bought with predictability. A second agent is bought with a delegation contract. A more capable model is bought with cost, latency, and sometimes a data-retention constraint. The Professional exam rarely asks what is best — it asks what you would choose given constraints, and the defensible answer is the one that names what it gave up. That is the whole domain in two sentences, and we are going to make it concrete right now.

Chris: That framing is exactly what I want to sharpen today. I have shipped these systems and I can recognize the patterns on a diagram. What I want out of this module is decision rules precise enough to defend in a design review — not just to nod at on a slide.

Koko: Perfect. And Solution Design is seventeen percent of the Professional exam — the second-largest domain — so it is also where a wrong choice at the architecture level means no amount of prompt engineering or evaluation rigor saves you later. Okay, first purchase. The fact.

Koko: Three named patterns sit on a single axis: how much the model decides at run time. An augmented LLM is one call with retrieval or tools attached, and your code owns the control flow entirely. A workflow is a sequence you wrote, with the model filling in named steps. An agent chooses its own steps and its own stopping point. As you move along that axis, you are buying adaptability and paying in predictability, auditability, and token cost.

Chris: So the axis is not capability — it is where the control flow lives. In an augmented LLM, control flow is in my code. In a workflow, control flow is still mostly in my code but the model is doing more of the content work inside each step. In an agent, the model owns the loop.

Koko: Exactly right. And that distinction — where does the control flow live — is the discriminating question on any exam scenario. Now the worked example, because this is where it gets real.

Koko: A claims-triage intake sees four document types and nothing else. A deterministic router plus three fixed extraction steps handles it end to end, costs a known number of tokens per claim, and produces the same trace every time. Right next to it, the same team's exception desk sees anything that comes in — a handwritten fax, a translated foreign form, a voice transcript, whatever. That desk gets an agent with a tool set and a turn cap. Same team, same building, two different patterns — because the inputs differ.

Chris: The turn cap is doing real work there. That is the price negotiation in practice: you are bounding how much autonomy the agent actually exercises before it has to surface.

Koko: Right, a turn cap is a predictability purchase inside the agent pattern. Good. Now the analogy, because I want this to stick.

Koko: You do not hire an improvising chef to assemble the same four sandwiches all day. You hire one for the kitchen where the order could be anything. The four-sandwich line has a recipe, a fixed station, a measurable throughput. The improvising chef is more capable in open-ended situations, but if you put them on the sandwich line you have bought nondeterminism and received nothing in return.

Chris: And the sandwich line is actually faster and cheaper, because there is no overhead of the chef deciding what to do next.

Koko: Exactly. Planning has a cost. The takeaway, then, and this is the instinct to carry into the room: measure the variance in the input before you choose the pattern. Where the set of inputs is enumerable, enumerate it in code and let the model do the language work inside each branch. Take the lowest-autonomy pattern that covers the variance. Name the price before you agree to pay it.

Chris: The way I would state that for a design review: if I can write down the complete list of input types on a whiteboard, I probably should not be handing control flow to the model.

Koko: That is a clean rule. Write it on the whiteboard test. Now the trap — and I want to name this as a misconception, because it is widespread. The misconception is that autonomy is a maturity level. That an agent is the grown-up version of a workflow, the way microservices are the grown-up version of a monolith in some people's heads.

Koko: It is not. Autonomy is a price paid for input variance. If the inputs do not vary, you have bought nondeterminism, a wider audit surface, and an unbounded token bill, and received nothing in return. On the exam, a scenario that enumerates its input types is signaling the answer. Four document types, three steps, known trace — that is a workflow or an augmented LLM. The option next to it will say 'agent,' and it will sound more sophisticated. It is not. It is just more expensive.

Chris: The version of that I keep seeing on teams is the phrase 'future-proofing' — we will use an agent now so we are ready when the inputs get more complex. But you are paying the audit and cost price today for variance that may never arrive.

Koko: And the Professional exam will not reward future-proofing speculation. It gives you constraints, and the defensible answer matches the pattern to the stated variance. That is the whole first purchase: measure the variance, buy the minimum autonomy that covers it, name what you gave up.

Koko: So here is the fact, stated plainly: a subagent is a separate instance with its own context window. Its intermediate tool calls, its chain of thought, all of its working — that stays inside it. Only its final message comes back to the parent. Which means the product of decomposition is a smaller parent context, not a bigger workforce.

Chris: That framing shift matters. I think a lot of teams reach for multi-agent because they want more capacity — like spinning up more workers. But the actual mechanism is the opposite: you are shrinking what the parent has to carry.

Koko: Exactly. Anthropic names four reasons to delegate to a subagent: context isolation, parallelization of independent subtasks, specialized instructions through a different system prompt, and tool restriction — giving one agent access only to the tools it should touch. And there is a fifth that shows up in model-selection guidance: escalation. You hand a genuinely hard subset of the problem to a more capable model for that one step.

Chris: The escalation case is interesting. So the parent might be running on a lighter model, and it delegates one reasoning-intensive subtask to something heavier, gets the answer back, and carries on.

Koko: Right. The subagent does not need to share the parent's identity or the parent's model. It just needs a clean delegation prompt and the authority to use whatever tools it's been given. Let me make this concrete.

Koko: Due-diligence assistant. It fans out three subagents. Each one reads forty filings. The parent ends up holding three summaries — not a hundred and twenty documents. And because the three subtasks are independent, the wall-clock time is the duration of the slowest one, not the sum of all three.

Chris: And then there is the verification step in that scenario — a fourth subagent that is read-only by tool restriction. It checks the assembled draft against the extracted quotes. It literally cannot write anything, because the tool set it was given does not include a write tool.

Koko: Which is the tool restriction benefit in action. You are not relying on the instruction 'please don't modify anything.' You are enforcing it structurally.

Chris: That is a meaningful distinction for exam purposes. Instruction-based constraints and capability-based constraints are not the same thing.

Koko: Good place to land the analogy. You hire three researchers. You ask each one for a memo. You get their conclusions back. You do not get their reading piles. That is the entire benefit. The isolation is what makes the parent lighter. If you were receiving their reading piles, you would have gained nothing.

Chris: And the memo is the delegation prompt working as a contract. The researcher goes off with whatever brief you gave them. They do not call you mid-task to ask what you meant.

Koko: Which is the takeaway. Delegate when a subtask is independent, when it needs a different tool set or system prompt, or when it needs a stronger model for that one step. And when you delegate, put everything the subagent needs into the delegation prompt itself — because it inherits nothing from the parent. Nothing. The delegation prompt is the contract.

Chris: That last part is where I see the split go wrong in practice. The subagent starts hallucinating or asking circular questions, and the diagnosis is almost always that the delegation prompt was underspecified — not that multi-agent was the wrong pattern.

Koko: And there is a sharper diagnostic than that. A subagent that seems to need more context is usually a sign that the decomposition was made at the wrong seam. The boundary between parent and subagent should be a place where the subagent can work completely from what it was handed.

Chris: The option sitting next to the right answer on the exam usually offers to share the full conversation history with the subagent — framed as giving it context to do good work. I see teams make that call in production too.

Koko: And that is the misconception to name directly: piping the parent's history into the subagent sounds generous, but it destroys the isolation the decomposition existed for. You have just reintroduced exactly the context pressure the architecture was supposed to relieve. The subagent's context window fills up with the parent's working, and you are back where you started — except now you have more moving parts. The delegation prompt is the contract. Everything else is noise.

Koko: Every architecture diagram I've ever seen in a workshop covers the same four boxes: input, processing, output, done. And almost every one of them is missing the fifth thing — the feedback edge. That's the part that makes the system improvable after it ships. You capture what the system produced, you capture what a human did with it, and you route the difference somewhere that actually changes future behavior.

Chris: The 'route somewhere' part is where I see teams fall short. They capture the data — it goes into logs — and then nothing reads it. It just sits there.

Koko: Exactly. And we'll come back to why that distinction matters enormously on the exam. But let's ground it first. Concrete scenario: an invoice-coding assistant. Every time it processes a transaction, it writes three things — the code it proposed, the code the reviewer accepted or overrode, and the retrieved evidence it used to make the call.

Chris: So next quarter you have a regression set built from real production disagreements, not cases someone invented in a sprint planning meeting.

Koko: Right. And the override rate — how often a human rejected the system's proposal — becomes the number the steering group reads. Not some synthetic benchmark. A number rooted in what the system actually got wrong in production.

Chris: And that number can feed back into routing logic, or prompt revision, or a rebuild of the retrieval index. There's a named consumer for what was captured.

Koko: That's the key phrase: named consumer. Here's the analogy I keep coming back to. A thermometer tells you the temperature. A thermostat changes it. Most architecture diagrams ship a thermometer. They measure; they do not act.

Chris: So the design question becomes: what is the thermostat in this system? What reads the signal and adjusts something?

Koko: Exactly the right question to ask at design time. And that's the takeaway you want to carry into the exam room: draw the feedback edge, and name what consumes it. Is it the evaluation set? A routing threshold? A prompt revision? A rebuild of the retrieval index? If you can't name the consumer, you have telemetry, not a feedback loop.

Chris: That's a clean discriminator. Telemetry observes. A feedback loop changes something downstream, in a future run.

Koko: Crosses run boundaries — that's the defining property. Which brings us to the trap, because the exam will put something right next to the correct answer that looks like a feedback loop but isn't.

Chris: The option I keep seeing on teams is treating retry logic as a feedback mechanism. The system fails, it retries, it eventually succeeds — and the team says the system is self-correcting.

Koko: And the misconception there is that a retry is error handling inside a single run. It changes nothing about the next run. A retry that leaves no record is the absence of a feedback loop, not an instance of one. A real feedback loop crosses the run boundary and has a named consumer on the other side. Those are two completely different things.

Chris: So if an exam question describes a system that retries on failure and asks whether a feedback loop is present, the answer is no — unless something outside that run reads a record of what happened.

Koko: That's it. Draw the full picture: input, processing, output, and then the edge that goes back. Name what's on the receiving end of that edge. If the edge terminates in a log file nobody reads, you've shipped a thermometer.

Koko: Here is the thing that catches architects who have done everything right technically. Governance constraints do not arrive at the end of the design process to bless your choices. They delete options. Before any benchmark runs, some paths are already closed.

Chris: And closed permanently in some cases. The workspace geography one is the sharpest example I know. You pick a region at workspace creation and that is it. There is no migration path, no setting to change afterward.

Koko: Exactly right. Two constraints in particular have that quality — they are not configurable after the fact. First, workspace geography: chosen once, immutable. Second, Covered Models: certain models in the catalog require thirty-day data retention, which means they are not available under a zero-data-retention arrangement unless Anthropic expressly authorizes it.

Chris: So a zero-data-retention requirement and a Covered Model are mutually exclusive by default. You cannot configure your way out of that.

Koko: Right. Now here is the scenario that makes this concrete. A regulated insurer has a hard requirement: no prompts stored at rest. Zero-data-retention. The most capable model in the catalog is a Covered Model, so it cannot run under that organization's ZDR arrangement. Full stop.

Chris: So the design question becomes: what do you do with the use cases that genuinely need that higher capability?

Koko: You split the architecture. The main flow runs on a mid-tier model under zero-data-retention for the whole pipeline. Then you create a separate workspace with thirty-day retention enabled — a narrow, consented escalation path for the cases that need the more capable model and where the user has explicitly agreed to retention.

Chris: Two workspaces. Not because of any accuracy benchmark, not because of latency — because of a retention rule.

Koko: That is the whole point. The architecture was decided by the constraint. No benchmark was involved. The analogy I like: you choose the building site before the architect. Some sites you cannot re-zone later. Once you have poured the foundation in the wrong jurisdiction, there is no configuration panel that moves the building.

Chris: And the instinct that follows from that is pretty clear: you have to surface these constraints in discovery, not in review.

Koko: That is the takeaway. Collect residency, retention, approval, and audit requirements during discovery. Apply them as a filter over your option set before you score anything on accuracy, latency, or cost. And then — this part matters for the exam — write down which options the filter removed. That list is the answer to the question the review board will ask.

Chris: The audit trail of eliminated options. I have started doing that explicitly on regulated projects because the question always comes up: why didn't you evaluate the more capable model? The answer is documented.

Koko: Exactly. Now the trap, and it is a process trap more than a technical one. The misconception the exam is testing is this: that you pick the best model and then get it approved. The assumption being that approval is a step that can be satisfied after the design is done — by paperwork, by configuration, by negotiation.

Chris: The version of this I keep seeing on teams is someone building against the most capable model in a dev environment where retention rules do not apply yet, and then learning in the staging review that the production arrangement cannot support it. At that point you are not adjusting, you are rebuilding.

Koko: And the workspace geo case makes it even starker. If you stood up the workspace in the wrong region, there is no setting that fixes it. The constraint was not satisfiable by configuration — it was only satisfiable by the choice you made at creation. Learning that late does not mean a longer approval process. It means starting over.

Chris: So the exam question is really asking: do you know that governance is a filter applied first, not a stamp applied last?

Koko: That is the discriminator. Constraints narrow the option set. Benchmarks rank what is left. In that order, always.

Koko: Last one. And this one is about how you prove the thing worked — which turns out to be a design decision, not a reporting decision.

Chris: And it has to be made before the build starts, not after.

Koko: Exactly. Here is the fact. Efficiency, transformation, productivity, cost, and performance SLAs are five different claims. They have five different measurements, usually five different owners, and a proposal that claims all five has committed to none of them. Because afterward, nobody can say whether it worked.

Chris: I have sat in that retrospective. The system ships, something moved, and then everyone argues about which number is the real number.

Koko: Right, because when every metric is a success metric, the program cannot fail — and that means it also cannot succeed. The analogy I use: a diet that promises weight loss, better sleep, more energy, and improved mood has promised nothing. No single result can falsify it.

Chris: If one number goes the wrong way, there are four others to point at.

Koko: So here is the worked scenario. An accounts-payable program declares cycle time as the primary pillar — expressed as a performance SLA, ninety-fifth percentile under four hours. That baseline is captured for six weeks before the build starts. Cost per processed document is the secondary pillar. And exception rate is named as the counter-metric: the thing that must not degrade, with a threshold that triggers a pause.

Chris: That structure does a lot of work. The primary pillar says what winning means. The baseline gives you the before. The counter-metric says what kind of win would actually be hollow.

Koko: That phrase — hollow win — is exactly what the counter-metric is protecting against. And each number has an owner in the business, not on the delivery team. The delivery team does not get to call their own grade.

Chris: The takeaway I carry from this: name one primary pillar, measure its baseline before you build, name the counter-metric, and attach a business owner to each number.

Koko: That is the instinct. Now the trap — and it is a specific one. The misconception is that token spend is the cost pillar. Token spend is one line in the total cost of the workflow. The full picture also carries human review time, exception handling, the evaluation work the system now needs permanently, and the incident cost of the failure modes you accepted when you made your architecture choices.

Chris: A program that halves token cost and doubles review time got more expensive. I have seen that outcome called a success because the infrastructure bill went down.

Koko: That is the trap in production, and it is the trap on the exam. Cost means total workflow cost.

Koko: Alright. That is the last new concept in Domain One. Chris, you have shipped these systems — give me the through-line.

Chris: The five decisions happen in a specific order when you are actually designing something. First, measure input variance before you pick a pattern — the shape of what comes in determines the shape of what you build. Second, delegate for isolation and write the delegation contract before you draw any boxes. Third, draw the feedback edge and name who consumes it — if nobody is named, that edge does not exist in practice. Fourth, filter by constraint before you score anything — remove the options that are already off the table, then choose. And fifth, name one primary pillar with a baseline and a counter-metric, and attach a business owner before the build starts.

Koko: That sequencing matters. You cannot pick a pattern before you know your variance. You cannot score options before you have filtered them. The order is part of the answer.

Chris: And the through-line connecting all five is the same thing: every decision is a trade-off, and the Professional exam wants to know whether you can name what each choice costs.

Koko: That is the exam habit I want to leave you with. When two options both look defensible — and on this exam they will — the question is almost always testing whether you know what each one costs. The answer that names the trade-off is nearly always the one they want. Not the answer that names the feature. The answer that names the cost.

Chris: Choose and defend. That is the whole domain.

Koko: The drills and flashcards for Domain One are at KokoAI Academy — find them at kokoknows dot AI. You have done the hard conceptual work in this lesson; the flashcards are there to make it automatic before exam day.

Chris: Run the drills until naming the trade-off is the first thing you reach for, not the last.

Koko: You already think like an architect. This exam is just asking you to prove it on paper. Go show them.