Claude Certified Architect exam guide for agentic engineers

The Claude Certified Architect exam is a scenario-based assessment of the practical engineering decisions behind production Claude systems. It covers agent architecture, Claude Code workflows, prompt and structured-output design, tool use and Model Context Protocol integrations, plus context reliability. More importantly, its subject areas form a useful learning roadmap for developers building agentic software. The recurring lesson is simple: useful coding agents need explicit control loops, narrow responsibilities, bounded context, reliable verification, and clear escalation paths. Teams adopting an agent-first control plane face the same problems when agents begin working across issues, code, tests, and delivery workflows at speed.

At a Glance

The exam’s production scenarios are also a practical checklist for building reliable coding-agent workflows.

• Core skill: Build an application loop around the model instead of treating a single response as a completed action.
• Tool safety: A model proposes tool calls, while your application performs the actual execution and validation.
• Context discipline: Isolate subtask work, return compact summaries, and prevent long-running sessions from growing unchecked.
• Agent design: Give subagents narrow jobs and limited tools rather than creating one overloaded generalist.
• Delivery workflow: Use noninteractive automation carefully, with verification and human review where consequences matter.
  

What does the Claude Certified Architect exam cover?

The Claude Certified Architect exam tests whether you can make sound architecture choices in realistic agentic-system scenarios. Its domains span agent architecture, Claude Code configuration, prompt and output design, tool and MCP integration, and context reliability, with questions centered on production constraints rather than abstract definitions.

The assessment is designed around six possible production scenarios, with four selected for an individual exam attempt. That format matters because it shifts preparation away from memorizing isolated features. You need to identify tradeoffs: when a tool loop should continue, when an answer is incomplete, when to isolate a task, and when a person should approve an outcome.

The five knowledge areas offer a useful curriculum even for engineers who do not plan to take the exam:

• Agentic architecture: Loops, orchestration, subagents, handoffs, and safe stopping conditions.
• Claude Code: Repository-level guidance, workflow configuration, task isolation, and automation.
• Prompt engineering: Clear instructions, structured outputs, and formats such as JSON.
• Tools and MCP: Designing tools that an agent can call reliably through the Model Context Protocol.
• Context management and reliability: Keeping the context relevant, monitoring token use, compacting sessions, and handling partial work.

Anthropic’s Claude Code documentation similarly frames coding-agent work as an iterative process across a codebase, commands, files, and developer-controlled instructions. That is why architectural discipline matters more than a clever initial prompt.

Why are agent loops the foundation of reliable tool use?

An agent loop lets application code inspect why a model stopped, execute requested tools, return results to the model, and end only when a usable answer is complete. Without this loop, an application can mistake a tool request or incomplete output for a final result.

A language model does not independently execute a database query, update a ticket, deploy code, or send a message. It can determine that a tool is needed and produce structured arguments for a tool call. Your software owns the execution environment, credentials, validation rules, error handling, and audit trail.

A reliable loop follows this pattern:

1. Send the current messages, system instructions, and available tools to the model.
2. Inspect the response and its stop reason.
3. If the model requested tool use, validate the requested arguments and execute the allowed tool.
4. Add the tool result to the conversation state.
5. Call the model again so it can interpret the result or choose the next action.
6. Finish only when the stop reason and output indicate a complete response.

Stop reasons are operational signals, not incidental metadata. A tool-use stop indicates that application code needs to do more work. A token-limit stop can indicate that the model’s response was cut off, which means treating the partial output as final can create an incorrect result. A production workflow should recognize these states explicitly.

The same layering principle extends beyond any single platform — see how agent harnesses form the foundation of AI-native software more broadly, vendor-agnostic.

For sensitive customer support, production changes, or account actions, add a confidence check and a human escalation path after the loop. The right boundary depends on the task. A read-only lookup may run autonomously, while a refund, deletion, or deployment may require approval.

How should Claude Code instructions be organized in a repository?

Claude Code instructions work best when they are layered by scope: broad project rules at the repository root, more specific guidance within project areas, and local rules inside directories with specialized conventions. This gives agents useful context without forcing every task to carry every instruction.

To systematically prune these repository guidelines and prevent instruction creep, teams can implement an ablation testing program to isolate and measure the impact of each rule.

Repository guidance should describe stable engineering expectations, not become a dumping ground for temporary notes. A top-level instruction file can define the project’s build commands, test commands, coding conventions, architectural boundaries, and contribution expectations.

More focused directories can contain their own instructions where conventions differ. For example, a service directory might specify API contract rules, while a frontend package may define component conventions and local test commands. The closer an instruction is to the relevant code, the less likely it is to distract an agent working elsewhere.

Good instruction hierarchy mirrors a familiar engineering practice: global rules set shared standards, while local rules capture constraints that only apply in one subsystem. This reduces ambiguity and gives coding agents a more accurate working environment. The same layering principle applies to agent skills specifically since teams should apply progressive disclosure templates for SKILL.md files to keep entry-point instructions lean while isolating higher-privilege details until they're actually needed.

Keep instructions concrete. “Run the relevant unit tests before proposing changes” is actionable. “Write high-quality code” is not. Anthropic’s prompt engineering guidance also emphasizes clear, specific instructions and structured formats where appropriate.

Why should multi-agent systems use specialized subagents?

Specialized subagents are easier to evaluate, cheaper to run, and less prone to confused behavior than one agent equipped with every possible tool and responsibility. Assign each agent a bounded role, expose only the tools it needs, and return a concise result to an orchestrator.

Instead of building a single all-purpose agent, separate your pipeline's responsibilities into reusable agent skills that load dynamically only when a specific subtask is triggered.

The common anti-pattern is the all-purpose agent. It receives broad context, a large tool catalog, and responsibility for research, planning, implementation, review, and execution. That may appear flexible, but the agent must repeatedly decide which role it is playing and which tools are relevant. Its context grows quickly, and failures become harder to diagnose.

A better system separates responsibilities. A research agent gathers evidence. A critic checks a proposed claim against that evidence. An implementation agent changes code. A verification agent runs tests and reports results. An orchestrator decides which step comes next.

Limit both tools and context

Specialization is not only about job titles. It also means limiting what each agent sees. A critic evaluating a claim does not necessarily need every intermediate message that produced the claim. It may be more useful to receive the claim, the supporting evidence, and evaluation criteria.

That separation can reduce convergence toward the same initial idea. If every subagent inherits the full reasoning trail and prior conclusions, independent review becomes weaker. Give the reviewer enough evidence to assess the work, but not so much inherited framing that it simply repeats the original decision.

This approach also controls cost and reliability. More tokens mean more context to process, and more context can dilute the instructions that actually matter. A large context window is capacity, not a recommendation to load every artifact into every prompt.

How do you prevent agent context from growing out of control?

Prevent context sprawl by running expensive or verbose subtasks in isolated contexts, returning only their useful summaries, and compacting long sessions when token use reaches a defined threshold. The primary thread should contain decisions and evidence, not every intermediate trace.

Consider an agent asked to search large logs for errors. The main task does not need thousands of raw log lines and every intermediate observation. Fork that work into a separate subtask. Have the subtask return a compact report: likely root cause, affected component, relevant timestamps, and representative evidence.

The primary context then receives the report rather than the entire investigation. This gives the next agent enough information to decide what to do without contaminating the main thread with a large volume of low-value detail.

Use compaction deliberately

Long-running tasks still accumulate decisions, file changes, test results, and tool outputs. Track token growth and establish a threshold where the active context should be summarized or compacted. The goal is continuity, not perfect retention of every message.

A useful compacted state preserves:

• Current objective and constraints.
• Decisions already made and why they were made.
• Files changed, commands run, and notable results.
• Open risks, failing tests, or unanswered questions.
• Next actions and the required acceptance criteria.

Do not compact blindly. Preserve evidence needed for a later decision, and keep original artifacts available outside the active context when auditability matters. The compacted summary guides the agent, while logs, commits, test output, and issue history remain accessible through controlled tools.

Give agents shared context without turning prompts into a project database.

Levr keeps issues, acceptance criteria, tests, workflow gates, and attributed activity on shared project objects, so coding agents can work from current context and return proof with the work.

Explore Levr’s agentic workflow

How should teams run coding agents in CI/CD pipelines?

CI/CD workflows should be noninteractive when automation must run unattended, but they still need constrained permissions, deterministic checks, and explicit quality gates. A pipeline that pauses for routine confirmation is not fully automatable, while unrestricted automation creates an unnecessary operational risk. When introducing automation into unattended environments, simple pipelines are often insufficient; establishing a stateful Claude Code workflow is critical to prevent parallel execution conflicts.

Interactive modes are useful when a developer is present to answer questions. They are a poor fit for a scheduled pipeline because a confirmation prompt can stall the run indefinitely. Configure automated paths to operate within clearly defined permissions and with inputs supplied by the workflow.

Automation should not mean that agents bypass engineering standards. Require the same evidence that a human-authored change would need: tests, build results, reviewable diffs, and appropriate approvals. This is especially important because coding agents can produce changes faster than teams can assess them manually.

One way to handle the workflow in Levr’s agent-first project system is to attach acceptance criteria and tests to the same issue an agent works on. The agent can update the work item, run or record verification, and leave an attributable activity trail for human review.

For work that is not time-sensitive, batch processing can reduce token costs in exchange for delayed completion. It is best suited to tasks such as broad repository analysis, offline generation, or planned maintenance. It is not suitable for an urgent incident, a developer actively debugging a failure, or any task that needs immediate feedback.

What mistakes most often weaken agentic engineering systems?

The most damaging agentic engineering mistakes are treating model output as an action, giving every agent unlimited tools and context, mixing unrelated subtasks in one thread, and removing verification from automated workflows. Each mistake reduces observability precisely when systems become more autonomous.

• Accepting a first response as final: Inspect stop reasons and complete tool-use loops before relying on an answer.
• Assuming the model runs tools: The application executes tools. Validate arguments, permissions, and outputs in application code.
• Building a generalist agent by default: Use narrow roles with the smallest effective tool set.
• Passing full reasoning between agents: Share the required evidence and task state, not every internal artifact.
• Letting context accumulate indefinitely: Fork verbose work, summarize results, and compact long sessions.
• Allowing unattended interactive prompts: Design CI/CD paths for noninteractive execution with deliberate guardrails.
• Equating generated code with verified code: Keep tests, review gates, and traceable outcomes in the workflow.

The broader lesson is that agentic engineering is systems engineering. Prompts matter, but so do state management, permissions, tool interfaces, verification, and observability. An agent becomes dependable through the workflow around it.

How does Levr put these architecture principles into practice?

The Claude Certified Architect exam tests whether you can reason about agent loops, tool design, and context discipline in isolation. Levr answers a related but different question: how do those same principles hold up once multiple agents, multiple humans, and real delivery deadlines are involved?

Every concept this guide covers maps to something Levr enforces structurally, not just architecturally:

• Agent loops become workflow states. Instead of a model looping until a task completes, Levr tracks the task itself — issue, acceptance criteria, and gate — so the loop's "stop reason" is a visible status, not a hidden implementation detail.
• Subagent specialization becomes heterogeneous routing. Mix Claude Code, Codex, Cursor, or any MCP-compatible agent on the same project, routing each task to whichever agent fits it best, without losing a single shared audit trail.
• Context compaction becomes shared project memory. Rather than one session's context growing unbounded, Levr keeps issue history, prior decisions, and test results attached to the work itself — available across sessions and across agents, not lost when a context window resets.
• Human escalation becomes a workflow gate. The exam's "when should a human review this?" question becomes a concrete, configurable checkpoint — nothing reaches Done until the gate says so, whoever or whatever is driving.

The architectural judgment the exam tests for is exactly what a production control plane needs to enforce at scale — this guide is a study aid for the exam and, just as usefully, a preview of what disciplined agentic engineering looks like in a live system

Loops You Can See: The Levr Dashboard

Every principle in this guide — tool loops, subagent boundaries, context compaction, human review gates — is easier to build when the workflow itself is visible. The Levr Dashboard aggregates agent runs, tool calls, and approval gates into a single pane of glass, giving architects the same real-time insight the exam scenarios test for.

The Levr Dashboard shows agent loops, tool calls, and approval gates in real time — the architecture this guide describes, made visible.

Technical Deep Dive FAQ

What is agentic engineering?

Agentic engineering is the practice of building software workflows where language models can plan, use tools, inspect results, and continue through an application-controlled loop. It goes beyond asking a model for text or code. The system provides task context, available tools, execution boundaries, and evaluation steps. Developers still design the architecture, permissions, data flows, and stopping conditions that determine whether agent actions are safe and useful.

What is the Claude Certified Architect exam?

The Claude Certified Architect exam is a scenario-based assessment focused on production Claude architecture and workflows. Its areas include agentic architecture, Claude Code, prompt and structured-output design, tool and Model Context Protocol integration, plus context reliability. Questions use practical constraints and scenarios rather than asking only for definitions. The associated topics provide a strong study framework for developers who want to understand how to build and operate Claude-based agent systems responsibly.

What is a stop reason in an agent loop?

A stop reason explains why the model stopped generating at a particular point. In an agent workflow, it helps application code determine the next step. A tool-use stop generally means the model has requested a tool and supplied arguments for it. A token-limit stop can mean the output is incomplete. Treating every stop as a final answer is an error because different stop states require different application behavior.

Can a language model execute tools by itself?

No. A language model can select a tool and generate structured inputs that describe the intended call, but the host application performs the actual execution. The application decides whether the tool is available, validates arguments, applies permissions, invokes the service, and returns the result to the model. This separation is important for security and reliability because it keeps real-world actions under deterministic software controls.

Why should subagents have separate contexts?

Separate contexts keep verbose research, logs, and intermediate reasoning from overwhelming the primary task. They also let each subagent focus on a defined problem with relevant instructions and evidence. A main orchestrator can receive a concise finding instead of every raw artifact. This reduces token use, improves signal quality, and makes it easier to inspect why a specific subagent reached its conclusion.

How many tools should a coding agent have?

There is no universal number, but a coding agent should have only the tools needed for its assigned task. A focused reviewer may need repository search and test-result access, while a deployment workflow may need carefully scoped environment tools. Adding unrelated tools creates extra choices, broader permissions, and more failure paths. Start narrow, evaluate the workflow, and add a tool only when it solves a demonstrated limitation.

What should be included in a context compaction summary?

A useful compaction summary records the active objective, hard constraints, completed steps, decisions, changed files or systems, verification results, remaining risks, and the next action. It should preserve facts needed to resume the task without reproducing every conversation turn. Keep source logs, commands, and larger artifacts externally accessible when needed, but avoid carrying them in the active context unless they directly affect the next decision.

How can teams keep coding-agent changes auditable?

Auditability requires an attributable record connecting a task, agent action, code change, test result, and approval decision. Keep the issue and acceptance criteria visible, record tool actions and outputs where practical, link pull requests and CI results, and require a review gate for consequential changes. Levr supports this model by keeping issues, tests, activity, and workflow states in one control plane where human and agent contributions are attributed.

When should a human review an agent’s work?

Human review is most valuable when an agent action has a high impact, ambiguous requirements, security implications, customer consequences, or weak automated verification. Examples include production deployments, destructive operations, changes to authorization logic, and external communications. Review can be lighter for low-risk, reversible, well-tested work. The goal is not to approve every token, but to put human judgment at the points where automated evidence is insufficient.

Can coding agents run effectively in noninteractive CI/CD?

Yes, if the workflow supplies the required inputs and permissions without waiting for a person to respond. The agent should operate in a constrained environment, use known commands, produce structured artifacts, and pass deterministic quality checks. Noninteractive execution does not remove the need for controls. It makes upfront workflow design more important because the pipeline must handle expected decisions, failures, and escalation conditions on its own.

What is MCP in agentic development?

MCP, short for Model Context Protocol, is a protocol for connecting models to external tools and context sources through a consistent interface. In an agentic workflow, MCP can expose capabilities such as issue access, repository operations, test execution, or internal knowledge retrieval. Teams should still apply least privilege, inventory the tools they expose, validate inputs and outputs, and avoid granting broad access merely for convenience.

Key Takeaways

Reliable agent systems are built from controlled loops, focused responsibilities, compact context, and visible verification.

The exam themes translate directly into production engineering practices.

• Loop before action: Inspect stop reasons and process tool calls through application code.
• Specialize agents: Assign narrow tasks, restricted tools, and only the context each role needs.
• Control context: Fork long subtasks, return summaries, and compact sessions before they become noisy.
• Keep proof with work: Connect implementation, tests, CI/CD outcomes, and human approval in one traceable workflow.

The strongest agentic systems do not rely on a single prompt. They make the next correct action easy and the unsafe action difficult.

Further reading

• Anthropic Claude Code documentation
• Anthropic prompt engineering overview
• Anthropic Model Context Protocol documentation
• Levr agent-first project management platform
• Levr features for agentic engineering teams
• How Levr’s agentic workflow operates
  

Ship at agent speed

Give your coding agents a control plane, not just a prompt.

Levr connects Claude Code, Cursor, Codex, and Copilot to shared project context with issues, quality gates, test suites, and attributable workflow history. Teams can define intent, let agents take on tasks, verify outcomes, and keep human approval where it matters.

Get early access to Levr

No credit card required during beta.