Claude Certified Architect - Professional common mistakes
Claude Certified Architect - Professional · Understand the traps and how to avoid them.
Designing an agentic workflow with a single monolithic prompt and no explicit state or handoff contract between steps, then describing it as 'orchestrated'.
Candidates conflate 'multi-step prompt' with orchestration and skip defining the control flow, termination conditions, and data passed between stages, so the design cannot be reasoned about under failure.
What to do instead
For any agentic design, explicitly name the orchestrator, the per-step inputs/outputs, the loop termination and max-iteration bounds, and the fallback path; draw the control flow before writing prose.
Choosing the largest or newest model for every subtask in a pipeline instead of matching model capability to task difficulty and latency/cost budget.
Candidates assume 'best model = best answer' and treat model selection as a single global decision rather than a per-stage tradeoff involving accuracy, latency, context limits, and cost.
What to do instead
Justify each model choice per stage against explicit criteria (task complexity, required context window, latency SLO, cost per call), and identify which stages can use a smaller/cheaper model with acceptable quality.
Treating the context window as unlimited and dumping entire documents or full conversation history into every prompt.
Candidates underestimate lost-in-the-middle degradation, cost scaling, and latency, and do not distinguish what must be in-context versus retrieved on demand.
What to do instead
Specify a context budget per request, state what is always included (system rules, task, schema) versus retrieved or summarized, and describe the truncation/summarization strategy and its failure behavior.
Describing RAG as 'embed documents, retrieve top-k, answer' without specifying chunking, embedding model choice, hybrid retrieval, reranking, or how retrieval quality is measured.
Candidates memorize the RAG acronym but not the design decisions that determine answer quality, so they cannot defend the pipeline under questioning.
What to do instead
For each RAG design, justify chunk size/overlap and embedding model against document structure and query type, name the retrieval and reranking strategy, and define retrieval metrics (recall@k, context precision) separately from answer metrics.
Proposing an evaluation plan that is only 'run a test set and check accuracy' with no golden dataset construction, no LLM-as-judge calibration, and no regression gating.
Candidates treat evaluation as an afterthought and lack familiarity with building labeled sets, judge bias, and CI integration, so the plan is unfalsifiable.
What to do instead
Specify dataset sourcing and labeling, per-metric definitions with thresholds, how the judge is validated against human labels, and where evaluation sits in the deployment pipeline as a gate.
Writing prompts that state the goal but omit output schema, role constraints, examples, and explicit handling of ambiguous or out-of-scope input.
Candidates optimize for the happy path and do not anticipate that the model will guess when the contract is underspecified, producing unparseable or hallucinated output.
What to do instead
For each prompt, include the role, the exact output format (with a schema or example), explicit refusal/clarification behavior for out-of-scope input, and a stated criterion for what 'correct' looks like.
Designing tool definitions with vague descriptions and no input validation, error semantics, or idempotency guarantees, and assuming the model will call them correctly.
Candidates focus on the happy-path tool call and overlook that tool schemas are the model's only contract, and that failures must be surfaced back to the model rather than silently swallowed.
What to do instead
Specify precise tool names/descriptions, typed parameter schemas, validation rules, structured error returns the model can act on, and idempotency or retry semantics for side-effecting tools.
Treating safety as a single input filter rather than defense in depth across prompt injection, tool misuse, data exfiltration, and output handling.
Candidates reduce responsible AI to 'add a moderation call' and miss that retrieved content and tool outputs are untrusted inputs that can hijack the agent.
What to do instead
Enumerate threats per trust boundary (user input, retrieved documents, tool results, model output), and name the specific control at each layer: input validation, privilege scoping for tools, output sanitization, and human approval for high-impact actions.
Ignoring cost and latency engineering: no token accounting, no caching strategy, no streaming, and no plan for handling rate limits or provider outages.
Candidates treat operations as out of scope for an architecture exam and propose designs that are correct but economically or operationally infeasible.
What to do instead
For each design, estimate tokens and cost per request, name caching (prompt/response/semantic) and batching opportunities, specify timeout/retry/backoff and fallback-provider behavior, and state the latency budget per stage.
Presenting a design with no stated assumptions, tradeoffs, or rejected alternatives, and answering follow-ups by adding scope instead of defending decisions.
Candidates believe the exam rewards the most features rather than the most defensible architecture, so they cannot explain why a simpler alternative was rejected.
What to do instead
For each major decision, record the assumption it depends on, the alternative considered, and the reason for rejection; when challenged, restate the constraint and show how the design satisfies it before adding anything new.