AnthropicClaude Certified Architect – Professional2026-106.2 Communicate architectural decisions and trade-offs
Recommend an option with explicit consequences
Completed by the knowledge check
Learning objective
Present architecture options with decision criteria, trade-offs, and a clear recommendation.
Core idea
An architecture presentation should let a decision maker choose an option and understand the consequences they accept. A component inventory does not do that. Lead with the decision requested, the requirement that decides it, and your recommendation; then show the alternatives and the cost of choosing yours.
For an architect presenting a Claude system, the output is a decision brief with a comparison table and a named decision owner. NIST AI RMF MAP 3.1 and MAP 3.2 call for documenting intended benefits and potential costs, including nonmonetary costs from errors. MANAGE 2.1 explicitly includes viable non-AI alternatives. Use those requirements to structure the comparison rather than treating AI adoption as a conclusion already reached.
How it works
Separate eligibility from preference
Begin with the business outcome and the constraints an option must satisfy. State the unit of work, affected population, deadline, authority to act, and unacceptable failure. These become eligibility conditions. An option that violates an essential authorization requirement cannot compensate by being cheap.
Then identify preferences among eligible options: accepted-result cost, response time, quality, delivery time, and maintenance burden. Anthropic’s success-criteria guidance recommends measurable, relevant criteria and multidimensional evaluation. Replace “fast and accurate” with an explicit quality rubric and a latency percentile over a named workload. See 1.6.2 for complete workflow cost accounting and 1.6.3 for deriving service targets.
Avoid hiding a constraint inside a weighted average. A score of nine for cost and one for unauthorized writes does not establish that a design is acceptable. Put mandatory conditions in a separate part of the table. State who can change each condition; an architecture review cannot silently relax a business control to improve an option’s score.
Compare options that solve the same problem
Include the status quo, a simpler feasible design, and the strongest more complex alternative. Each needs an honest implementation description, not a label such as “legacy” or “advanced.” Compare the same scope, inputs, checks, and completion conditions. Mark an unmeasured value as unknown rather than giving it a favorable estimate.
Anthropic distinguishes workflows, whose paths are predefined in code, from agents that dynamically direct their processes and tools. Its engineering guidance recommends starting with the simplest viable solution and adding complexity when it demonstrably improves outcomes. That supports testing a workflow against an agent; it does not predetermine which wins for your workload.
Give each option a benefit and a liability. A workflow can make a known process predictable while requiring explicit handling of additional cases. An agent can address variable tasks while introducing more cost and opportunities for compounding errors. Attribute those general trade-offs to Anthropic; attribute your measured magnitude to the particular experiment. Do not present a scenario’s cost ratio as a vendor guarantee.
End with an actionable recommendation
Write the recommendation as a bounded authorization: adopt a named option for a named scope, allocate resources, retain specified oversight, and review under a measurable condition. Attach assumptions and uncertainties to the claim they qualify. “Pilot funding only” means something different from approving an organization-wide deployment.
Use a short decision record containing the question, options, criteria, observations, recommendation, consequences, owner, and reconsideration condition. This is a practical artifact for this lesson, not a NIST-mandated document template. It implements the documented benefit, cost, and deployment-decision practices in MAP 3 and MANAGE 1.1. See 6.4.2 for the full decision record.
Key distinctions and trade-offs
A recommendation versus a menu: A menu transfers the analysis to the sponsor. A recommendation says which option fits the constraints and what would change that answer. Listing three plausible designs without choosing one leaves the architectural task incomplete.
A requirement versus a preference: Requirements determine admissibility; preferences rank admissible options. If every option fails a requirement, recommend changing scope or collecting missing information, not selecting the least visibly defective design.
Measured versus forecast: A prototype provides observations under test conditions. A forecast applies assumptions about traffic, labor, and operation. Keep both visible, because a precise forecast calculated from uncertain assumptions is still uncertain.
A shorter presentation reduces review effort, but excessive compression conceals the deciding condition. Keep the recommendation and losing trade-off on the first page, with the measurement details available behind it. The decision maker should not need to discover the main drawback in an appendix.
Architecture / decision scenario
A retailer wants customer-service refund drafts ready within 30 seconds at the 95th percentile. Its policy requires a person to authorize every refund. The sponsor can fund eight weeks of implementation, and operations requires at least 90% of drafts to pass its usability rubric. The following numbers are hypothetical prototype observations on the same 600 cases, not product benchmarks:
| Criterion | Manual drafting | Fixed retrieval workflow | Tool-using agent with human approval |
|---|---|---|---|
| Usable drafts | 98% | 93% | 96% |
| 95th-percentile draft time | 240 seconds | 18 seconds | 42 seconds |
| Estimated cost per usable draft, including review | $1.80 | $0.70 | $0.95 |
| Estimated delivery | Available | Six weeks | Ten weeks |
| Refund authorization | Person | Person | Person |
Recommend the fixed workflow for the initial scope. The agent’s quality advantage is real and stays in the presentation, but it misses both the latency requirement and delivery budget. Manual drafting remains the fallback and fails the desired turnaround. None of the options receives autonomous refund authority.
The customer-service director owns the business choice and staffing consequence; the architect owns the comparison and its assumptions. Ask for six weeks of implementation funding plus a bounded pilot, not full rollout. Record that unusual cases still require manual drafting and that the cost estimate depends on review time remaining near the measured value. Reopen the comparison if live usability drops below the agreed threshold or the case mix changes enough that the workflow no longer fits. Defending the experimental comparison itself is covered in 6.2.4.
Common exam traps
- Showing components without stating the decision requested.
- Comparing the chosen design against an implausibly weak alternative.
- Letting a weighted score conceal a failed mandatory condition.
- Removing the quality measure on which the rejected option wins.
- Reporting estimated savings as observed production savings.
- Asking for unrestricted rollout when the observations justify only a pilot.
What to remember
Present an explicit recommendation after testing eligibility and comparing credible alternatives. Show benefits, costs, uncertainty, and the consequence your preferred option loses on. Name the decision owner and the condition that would reopen the choice; an attractive diagram cannot substitute for those commitments.
Knowledge check
An insurer requires a person to authorize every claim payment. In a weighted comparison of three claim-handling designs, one design scores highest overall because of its cost and speed, but it pays approved claims without that authorization. What should the decision brief do?
A bank requires loan-summary drafts within 60 seconds at the 95th percentile, at least 90% usable under its rubric, and delivery within eight weeks. Prototype results on the same 500 cases are: manual drafting, 99% usable in 400 seconds, available now; a fixed retrieval workflow, 92% in 40 seconds, six weeks; a tool-using agent, 97% in 75 seconds, twelve weeks. What should the architect recommend?
A claims-summary workflow meets the agreed quality and latency criteria on 600 historical cases. Its cost estimate depends on reviewer time staying near the measured value; production performance remains untested. The sponsor asks to fund the next step that tests that assumption in live operation. What should the recommendation request?