DEV Community: Poorna Reddy

Five Stop Conditions Every Production Claude Tool Loop Needs

Poorna Reddy — Mon, 05 Oct 2026 22:56:19 +0000

A demo agent loop runs until the model says it is done. A production loop cannot work that way. Each tool call is a request to change something, and your code, not the model, decides when the loop stops.

Treat every tool call as an untrusted request

Claude returns a structured tool-use block: a tool name and arguments. Before anything runs, the application checks five things:

Schema: the arguments have the right shape. A strict schema catches malformed calls.
Identity and permission: the caller may use this tool for this task.
Business rules: the live record is in the right state, amounts match, limits hold.
Approval: actions above a threshold wait for a person.
Idempotency: a retry cannot create a second payment, order or message.

Valid JSON that asks for an invalid action is still invalid. The schema checks shape; business validation checks meaning.

Return typed results

Send back a typed success or error, with fields the model can use safely. Separate two kinds of error:

Recoverable: for example AMOUNT_MISMATCH with the recorded amount. Claude may repair the request once.
Terminal: a permission failure, policy denial or unsafe content. Stop immediately.

A loop that returns free-text errors invites blind retries and invented fixes.

The five stop conditions

Write these in code:

Done: the defined business outcome is complete.
Waiting: a required human approval is missing. Pause; do not guess.
Refused: a permission failure, policy denial or unsafe content.
Retries used up: a small, fixed number of retries for transient or repairable errors.
Budget exhausted: the maximum turns, tool calls, elapsed time, tokens or cost.

Leave out tools the task does not need

The simplest control is the tool you never give the agent. An accounts-payable agent that may request invoice approval does not need a payment tool. If payment is not on the allowlist, no prompt can make the loop release one.

Trace every run

Record the model version, inputs, tool calls, results and approvals for each run. When someone asks why the agent did something, the trace is the answer.

Go further

The full guide, with a worked invoice example and a controls table: production Claude tool loop on Timo Labs.
The exam view: task statement 1.1: agentic loops in the CCAR-F study guide.
Test your loop design reasoning with the free CCAR-F practice exam.

Claude Message Batches: What to Do With Each Result State

Poorna Reddy — Mon, 05 Oct 2026 22:55:45 +0000

The Message Batches API processes independent Messages API requests asynchronously. Submitting a batch is easy. The design work is in what happens after the results come back, especially when some succeed and some do not.

When a batch fits

Use a batch for independent work that can wait: evaluations, document classification, data analysis. Use an interactive request when a person or service needs the answer before it can continue. A batch can take up to 24 hours, so check the current limits in the documentation before building anything time sensitive.

Join by custom_id, never by position

Results can come back in a different order from the requests you sent. Give each request a custom_id taken from your own record, such as ticket_8831, and store the mapping before you submit. When results arrive, write each outcome next to its source record, with the prompt version, submission time and status.

Four result states, four next steps

State	What it means	Next step
`succeeded`	The model returned a message	Validate the message and its business meaning before any action
`errored`	The request failed	Read the error. Fix invalid input; retry only errors that are eligible
`canceled`	The batch was canceled	Check each request. A canceled batch can still contain completed results
`expired`	The request was not sent before the batch expired	Decide which requests are still useful, then resubmit those

succeeded is the state people misread. It means a message exists, not that the message is right for the decision.

Never rerun the whole file

When a few records fail, the tempting fix is to resubmit everything. That can create duplicate tasks or overwrite decisions a person already made. Instead:

Keep successful and unresolved records separate.
Retry only eligible records, with their original IDs.
Preserve completed outcomes and human decisions.

Keep the model away from the action

For refunds, notices, account changes or payments, separate the model's output from execution:

Mark a record approved_for_action only after validation and any required review.
Let the action service enforce an idempotency key, so a retry cannot run the action twice.

custom_id joins a result to its input. It does not make execution idempotent. That job belongs to the service that performs the action.

Checklist

Requests are independent, can wait, and carry unique custom_id values.
Inputs, prompt versions and results are kept and joined by ID.
A successful message and an approved business decision are different fields.
Partial failures have an owner and a retry rule.
Retries cannot duplicate an external action.

Go further

The full article, with a supplier classification example: Claude Batch API on Timo Labs.
The exam view: task statement 4.5: Message Batches API in the CCAR-F study guide.
Free CCAR-F practice questions test when to batch and how to handle partial failures.

PreToolUse or PostToolUse? Where to Put a Check in the Claude Agent SDK

Poorna Reddy — Mon, 05 Oct 2026 22:55:18 +0000

If an agent can trigger a business action, the most important design question is where each check runs. In the Claude Agent SDK, hooks give you two points around every tool call. Only one of them can stop the action.

The rule that decides most designs

A check that must prevent a side effect belongs in PreToolUse. It runs before the tool executes and returns a decision. PostToolUse runs after execution. It can add context, replace the result the agent sees, or record an event, but it cannot undo what the tool already did.

The three PreToolUse decisions

Decision	Use it when	What happens
`deny`	Required data is missing or a business rule fails	The tool does not run. Return a reason the agent and the operator can act on
`ask`	The request is valid but needs a person's approval	Your approval handler (`canUseTool` in TypeScript, `can_use_tool` in Python) gets the decision. Returning `ask` alone does not create an approval screen
allow	The request meets the hook's policy	The call continues to the tool service

A PreToolUse hook can also return changed input. Use that sparingly and log it, because the tool then runs something the agent did not ask for.

Two traps

Async hooks cannot gate. A callback that returns async: true (async_: True in Python) cannot block the tool or change its input. A hook that gates an action must return its decision before execution.

The hook is not the last line. The hook does not own the business record. The tool service must repeat authorization and business validation, and use an idempotency key so a retry cannot create a duplicate. Passing the hook shows the request looked acceptable, not that the action is correct.

Agent SDK hooks are not Claude Code hooks

The event names overlap, but the owners differ. Agent SDK hooks are registered by the application running the agent, through ClaudeAgentOptions in Python or the SDK options in TypeScript. Claude Code hooks are configured in the Claude Code environment. Exam questions and real incidents both turn on this difference.

A test plan before any real side effect

Send a valid, below-limit request. Confirm the tool receives unchanged input.
Remove a required field, change the supplier, exceed the limit. Confirm the expected deny or ask.
Simulate a lookup timeout, a tool error and a duplicate request. Confirm each one produces a visible event and no unintended action.
Check that the log records the session ID, tool-use ID, decision and reason, without unnecessary personal data.

Review the blocked paths as carefully as the successful one.

Go further

The full article walks through an invoice approval flow: Claude Agent SDK hooks on Timo Labs.
The architect exam covers this as task statement 1.5: Agent SDK hooks.
Practise these placement decisions with the free Claude Certified Architect practice exam.

5 Reasons Claude Code Seems to Ignore Your CLAUDE.md

Poorna Reddy — Mon, 05 Oct 2026 22:54:09 +0000

When Claude Code skips a rule you wrote in CLAUDE.md, the file is rarely broken. Usually the rule never loaded, lost to a conflicting rule, or was never something a context file could enforce. These are the five causes to check, in order.

1. The session started in the wrong directory

Claude Code loads CLAUDE.md and CLAUDE.local.md from the directory where the session starts and from every parent directory. A file in a sibling package does not apply just because it exists in the repository. Start in services/billing/ and the billing guidance is relevant. Start in apps/web/ and it is not.

2. The nested file has not loaded yet

Files below the working directory are not loaded at startup. They load when Claude reads files in that directory. If you start at the repository root and ask a question before Claude has opened anything in apps/web/, the web guidance is not in context yet. Run /context to see which memory files Claude Code reports as loaded.

3. Two files disagree

Loaded files are combined in order, from the root down to the working directory. A closer file adds more specific guidance, but it does not automatically win a contradiction. If the root says "update the lockfile" and a package file says "never change the lockfile", Claude has two instructions, not a rule. Give each rule one owner and write exceptions out in full.

4. The conflict sits in an import

A CLAUDE.md can pull in other documents. A stale rule in a referenced file behaves exactly like a stale rule in the main file, but it is harder to spot. Check every imported document and the .claude/rules/ folder in each relevant directory, not only the top-level file.

5. The rule needed enforcement, not guidance

CLAUDE.md is context that guides Claude. It is not a control layer. "Never read the secrets folder" written in CLAUDE.md is a request. If an action must be blocked whatever Claude decides, use a permission rule or a hook.

A two-minute test

Before relying on a new set of instructions, run three harmless tasks:

A change inside one package: does Claude name that package's rules and the right test command?
A change inside a second package: does it switch to that package's rules?
A change that touches both: does it identify both scopes, instead of applying one package's rules everywhere?

Ask Claude to restate the rule it will follow before it edits, and correct the instruction if the restatement is wrong. Then run the tests yourself. Guidance improves behaviour; a passing test or review is the evidence.

Write rules Claude can follow

"Test thoroughly" leaves room for interpretation. "Run npm test -w apps/web before proposing a commit" does not. Specific commands, file paths and scopes make a rule checkable.

Go further

The full article, with an illustrative monorepo and a debugging sequence, is on Timo Labs: CLAUDE.md hierarchy in Claude Code.
For the exam angle, read task statement 3.1: CLAUDE.md hierarchy in the CCAR-F study guide.
Free scenario questions on configuration decisions are in the CCAR-F practice exam.

Claude Code MCP: Connected but Not Working? Check These Three Gates

Poorna Reddy — Mon, 05 Oct 2026 22:53:32 +0000

An MCP server can appear in claude mcp list and still fail the first real request. In most cases the connection is fine and one of three separate gates is closed. Checking them in order saves a lot of configuration churn.

The three gates

Every MCP request from Claude Code passes three independent checks:

Gate	Question it answers	Who controls it
1. Project-server approval	May Claude Code load this connection in this project?	You, in an interactive session, plus any organisation restrictions
2. Tool permission	May Claude call this specific tool now?	Claude Code permission rules in personal, project and organisation settings
3. Data access	Does the credential behind the server allow this read or write?	The external system, for example GitHub, using the token's permissions

Passing one gate says nothing about the next. Approving a tool call in Claude Code cannot grant a repository permission your token lacks, and a token with full access does not help if the project server was never approved.

Read the symptom, then pick the gate

What you see	Check first
The server does not appear at all	Configuration: project directory, JSON syntax, server name
Approval is pending	Gate 1: review the project-server request in an interactive session
Every call asks for permission, or the call is refused	Gate 2: the permission rule, written against the actual tool name
Authentication or "not found" errors from the service	Gate 3: token expiry, selected repositories, organisation approval

Labels vary by Claude Code version. What matters is which stage failed. Use /mcp inside a session to inspect the connection before you change any files.

One detail catches many people at gate 2. Permission rules can target a whole server or a single tool, and the server sets the tool names. Inspect the real name before writing the rule. A name guessed from your own server label may not match.

Choose the scope before you share anything

Claude Code stores an MCP connection at one of three scopes:

Local (the default): you, in the current project.
Project: everyone who receives the project's .mcp.json.
User: you, across all your projects.

Sharing a Project-scope definition shares the connection, not the access. Each teammate still supplies their own credential, usually through an environment variable referenced in .mcp.json, so the secret never lands in the repository.

Limit access twice

For a read-only task such as summarising an issue, restrict both layers:

Use a read-only endpoint or toolset, so the server only offers read tools.
Use a read-only credential, so the identity cannot write even if someone later swaps the endpoint.

The endpoint limits what the connection exposes. The credential limits what the identity can do. You want both, because either can change without the other.

A quick verification habit

Before trusting a new connection with a larger task, ask for one record you can check by hand: title, state, owner and URL. Open the URL and compare every field. If a field is missing, the answer should say so rather than invent it. Note what you checked and when. That one confirmed lookup becomes your baseline when something breaks later.

Go further

The full walkthrough, with a read-only GitHub token, the .mcp.json entry and a troubleshooting table, is on Timo Labs: Claude MCP server integration guide.
The architect exam tests these same decisions. See task statement 2.4: MCP server integration in the CCAR-F study guide.
To check yourself on exam-style scenarios, try the free Claude Certified Architect practice exam.

Claude Certified Associate Foundations (CCAO-F): Exam Domains, Weights and Topics

Poorna Reddy — Sun, 27 Sep 2026 15:46:08 +0000

This article summarises the Claude Certified Associate Foundations (CCAO-F) exam guide published by Anthropic: what the certification validates, the exam format, what the domain weights mean, and the objectives under each domain.

What CCAO-F validates

Anthropic's exam guide states that the certification "validates that an individual can apply Claude to complete business and productivity tasks with minimal guidance."

The exam is intended for professionals who use Claude as a productivity tool and build Claude Projects in their day-to-day work, across operations, marketing, project management, education, communications and general knowledge work. The guide recommends:

Regular, hands-on experience using Claude in a professional setting
A foundational understanding of structured problem-solving, workflow design and digital tool usage
A practical understanding of AI limitations, including hallucinations, context constraints and data sensitivity

The guide states: "There are no mandatory prerequisites or required courses, and no software development or API experience is needed."

Exam format

Item	Detail
Exam code	CCAO-F
Questions	60
Question types	Multiple choice and multiple response. Each question states how many answers to select.
Time	120 minutes
Delivery	Proctored, online or at a test centre
Passing score	Scaled score of 720 on a scale of 100 to 1,000
Result	Pass or fail, scaled score, and percent correct by domain
Exam fee	US$99
Validity	12 months from the award date

A scaled score of 720 does not mean 72% of questions answered correctly.

What domain weights mean

The exam guide divides the exam content into seven domains and gives each domain a weight. The guide explains the weights as follows:

"The exam blueprint defines the content domains measured and the approximate weight of each domain on the exam. Weights reflect the relative importance of each domain to competent performance as determined through the job task analysis."

The exam guides for the other three Claude certifications add that the percentages indicate the approximate proportion of scored items drawn from each domain. In practice, a domain weight tells you roughly what share of the questions come from that domain. Multiplying the weight by 60 gives an estimate of the number of questions. The actual number on your exam can differ.

Domain	Domain weight	Estimated questions
Output Evaluation and Validation	21%	13
Workflow Integration and Solution Design	16%	10
Governance, Risk, and Responsible Use	15%	9
Prompting and Task Execution	14%	8
Product and Model Selection	12%	7
Configuration and Knowledge Management	12%	7
Troubleshooting and Optimization	10%	6

The largest domain is Output Evaluation and Validation: checking what Claude produces, not writing prompts.

Your result shows percent correct for each domain, so you can see which domains to study again if you need to retake the exam.

Objectives in each domain

The guide lists objectives under each domain. The objectives do not have separate weights. The lists below follow the guide's wording.

Prompting and Task Execution (14%)

Create effective prompts for business and technical tasks
Apply task decomposition techniques to structure complex requests
Iterate prompts to improve output quality
Adapt prompting strategies to the task type (analysis, research, drafting, brainstorming)

Output Evaluation and Validation (21%)

Evaluate Claude-generated outputs for accuracy and completeness
Identify hallucinations, inconsistencies and biases in responses
Apply fact-checking and validation techniques
Determine when human review or additional verification is required
Edit, adapt, refine and compare outputs for the intended audience
Organize and curate information, and select output formats (artifacts, inline, structured data)

Product and Model Selection (12%)

Select Claude product features (Projects, research mode, chat, artifacts)
Differentiate between Claude model types (Haiku, Sonnet, Opus)
Align model selection with task requirements (cost, speed, quality)
Understand and manage context limitations and memory considerations (when to restart, summarize or persist)

Workflow Integration and Solution Design (16%)

Apply Claude to analyze requirements and use cases
Use Claude for research, planning and process optimization
Use Claude to support solution design, development and iteration
Integrate Claude into existing workflows to augment or redesign them
Communicate Claude's value and limitations to stakeholders

Configuration and Knowledge Management (12%)

Configure Claude Projects with instructions and knowledge sources
Manage uploaded knowledge and connectors (for example Google Drive, Gmail)
Create effective system-level instructions
Maintain and update Claude configurations, knowledge sources and instructions

Governance, Risk, and Responsible Use (15%)

Identify appropriate and inappropriate use cases
Apply data sensitivity, regulatory and privacy considerations
Follow organizational AI policies and governance standards
Understand the ethical implications of AI use

Troubleshooting and Optimization (10%)

Identify, diagnose and resolve issues with underperforming prompts or poor outputs
Adjust the approach based on feedback and results
Optimize workflows for efficiency and effectiveness

Example question

This is an original Timo practice question on the Output Evaluation and Validation domain. It is not an official exam question.

A marketing manager asks Claude to draft a product comparison for a client presentation. The draft includes current prices for three competitor products. Company policy requires every figure shown to a client to be checked against a source.

What should the manager do before using the draft?

A. Ask Claude whether the three prices are correct, and keep them if Claude confirms them.

B. Check each price against the competitor's published pricing or another primary source.

C. Ask Claude to add a note that prices may be out of date, and keep the figures.

D. Regenerate the draft with a more capable Claude model, and use the new figures.

Answer: B. The policy requires each figure to be checked against a source. Only B does that.

A asks Claude to confirm its own output. That is not a check against a source.
C adds a warning but leaves the figures unchecked.
D produces new figures that are still unchecked.

More questions in this format are in the free 20-question Claude Certified Associate practice exam for CCAO-F, which explains every answer option and does not require sign-up. For the exam format and registration steps, see the Claude Certified Associate Foundations exam guide on Timo Labs.

Official sources

Claude Certified Architect Professional (CCAR-P): Exam Domains, Weights and Topics

Poorna Reddy — Sun, 27 Sep 2026 15:37:44 +0000

This article summarises the Claude Certified Architect Professional (CCAR-P) exam guide published by Anthropic: what the certification assesses, the exam format, what the domain weights mean, the objectives under each domain, and how CCAR-P differs from Claude Certified Architect Foundations (CCAR-F).

What CCAR-P assesses

Anthropic's exam guide states that the purpose of the certification is "to provide an independent assessment of the knowledge, skills, and abilities required to architect Claude-based solutions competently in production environments."

The exam is intended for mid- to senior-level technical professionals such as solution architects, AI/ML engineers, technical leads and senior software engineers who design and deliver production AI solutions with large language models. The guide recommends:

A foundation in software engineering best practices
3+ years of experience in systems architecture or platform engineering
6+ months of hands-on experience with Claude or comparable LLM-based systems in production
Experience delivering end-to-end systems from discovery through deployment

There are no mandatory prerequisites or required courses. The experience above is recommended, not required.

Exam format

Item	Detail
Exam code	CCAR-P
Questions	63
Question types	Multiple choice and multiple response. Each question states how many answers to select.
Time	120 minutes
Delivery	Proctored, online or at a test centre
Passing score	Scaled score of 720 on a scale of 100 to 1,000
Result	Pass or fail, scaled score, and percent correct by domain
Exam fee	US$175
Validity	12 months from the award date

A scaled score of 720 does not mean 72% of questions answered correctly.

What domain weights mean

The exam guide divides the exam content into seven domains and gives each domain a weight. The guide explains the weights as follows:

"Weights reflect the relative importance of each domain to competent performance as determined through the job task analysis. The percentages indicate the approximate proportion of scored items drawn from each domain."

In practice, a domain weight tells you roughly what share of the scored questions come from that domain. Multiplying the weight by 63 gives an estimate of the number of questions. The actual number on your exam can differ.

Domain	Domain weight	Estimated questions
Integration	19%	12
Solution Design & Architecture	17%	11
Evaluation, Testing & Optimization	16%	10
Governance, Safety & Risk Management	14%	9
Stakeholder Communication & Lifecycle Management	14%	9
Claude Models, Prompting & Context Engineering	13%	8
Developer Productivity & Operational Enablement	7%	4

No single domain carries more than 19%. Six of the seven domains sit between 13% and 19%.

Your result shows percent correct for each domain, so you can see which domains to study again if you need to retake the exam.

Objectives in each domain

The guide lists objectives under each domain. The objectives do not have separate weights. The lists below follow the guide's wording.

Solution Design & Architecture (17%)

Translate business problems into Claude-based AI solutions
Design end-to-end architectures (input, processing, output, feedback loops)
Select architectural patterns (workflow, agentic, augmented LLM)
Design multi-agent systems and orchestration strategies
Apply decomposition techniques for complex problem solving
Align solutions to business value pillars (efficiency, transformation, productivity, cost, performance SLAs)

Claude Models, Prompting & Context Engineering (13%)

Select Claude models based on trade-offs
Design system prompts, templates and guardrails
Apply prompt engineering techniques (zero-shot, few-shot, chain-of-thought)
Optimize context windows and manage token usage
Implement prompt reuse strategies (caching, modular prompts, Skills)

Integration (19%)

Evaluate tool and agent configuration for capability bloat
Analyze authentication and authorization requirements to identify security gaps
Evaluate accuracy-latency trade-offs and justify configuration decisions
Analyze observability challenges and select monitoring strategies at scale
Design a RAG pipeline with appropriate chunking and indexing strategies
Apply retrieval strategies matched to data shape and query pattern
Evaluate connection protocols and select an integration mechanism (MCP, API/CLI, agent-to-agent)
Evaluate progressive discovery vs. monolithic context strategy

Evaluation, Testing & Optimization (16%)

Define evaluation metrics (accuracy, latency, cost, safety, security)
Design evaluation datasets and test frameworks using mixed methodologies
Conduct A/B testing and iterative improvements
Diagnose system issues (prompt failure, hallucinations, model mismatch)
Optimize token usage, latency and cost-performance trade-offs
Monitor system performance using logging and observability tools

Governance, Safety & Risk Management (14%)

Implement guardrails and safety controls
Identify risks, limitations and failure modes of LLM systems
Apply human-in-the-loop validation strategies
Ensure compliance with regulations (for example GDPR, HIPAA, FedRAMP)
Address ethical AI considerations (bias, fairness, transparency)

Stakeholder Communication & Lifecycle Management (14%)

Conduct structured discovery and requirement gathering
Communicate architectural decisions and trade-offs
Manage stakeholder feedback loops and expectation alignment, including SLAs
Document architectures and provide implementation guidance
Support lifecycle phases (discovery, design, handoff, monitoring, iteration)

Developer Productivity & Operational Enablement (7%)

Configure Claude tools and environments for teams (for example Claude Code)
Improve developer workflows using AI-assisted tooling
Support debugging and operational issue resolution

How CCAR-P differs from CCAR-F

Both exams are for architects. The two exam guides differ in these ways:

Item	CCAR-F	CCAR-P
Questions	60	63
Exam fee	US$125	US$175
Recommended experience	6+ months building with Claude APIs, Agent SDK, Claude Code and MCP	3+ years in systems architecture or platform engineering, and 6+ months with Claude or comparable LLM systems in production
Structure described in the guide	4 scenarios picked from a bank of 6	No scenario structure described
Domains	5	7
Largest domain	Agentic Architecture & Orchestration (27%)	Integration (19%)

Three CCAR-P domains have no CCAR-F equivalent: Evaluation, Testing & Optimization; Governance, Safety & Risk Management; and Stakeholder Communication & Lifecycle Management.

CCAR-F task statements name specific configuration: stop_reason values, tool_choice settings, .mcp.json, CLAUDE.md levels, CLI flags. CCAR-P objectives are about design decisions and their trade-offs: RAG pipelines, authentication gaps, evaluation metrics, regulatory compliance and stakeholder communication.

Example question

This is an original Timo practice question on the Evaluation, Testing & Optimization domain. It is not an official exam question.

A team has built a contract review assistant that will replace a manual first review. The client requires at least 95% accuracy on each of its five contract types, measured before go-live. The team tested the assistant on 1,000 contracts that lawyers had already reviewed. Overall accuracy was 96%.

What should the team do next?

A. Go live, because overall accuracy of 96% is above the 95% requirement.

B. Measure accuracy separately for each contract type on the reviewed set, and fix any type below 95% before go-live.

C. Switch to the most capable Claude model to raise accuracy further, then go live.

D. Go live, and track complaints from the client's lawyers to find weak contract types.

Answer: B. The requirement is 95% for each contract type. An overall figure of 96% can hide one type that is well below 95%, so the team must measure each type separately.

A uses the overall figure, which does not show accuracy for each contract type.
C changes the model without measuring accuracy for each contract type, so the requirement is still not checked.
D measures after go-live, but the client requires the measurement before go-live.

More questions in this format are in the free 20-question Claude Certified Architect Professional practice exam for CCAR-P, which does not require sign-up. For the exam format and registration steps, see the Claude Certified Architect Professional exam guide on Timo Labs.

Official sources

Claude Certified Architect Foundations (CCAR-F): Exam Domains, Weights and Scenarios

Poorna Reddy — Sun, 27 Sep 2026 15:35:48 +0000

This article summarises the Claude Certified Architect Foundations (CCAR-F) exam guide published by Anthropic: what the certification validates, the exam format, what the domain weights mean, the task statements under each domain, and the scenarios the exam uses.

What CCAR-F validates

Anthropic's exam guide states that the certification "validates that practitioners can make informed decisions about tradeoffs when implementing real-world solutions with Claude."

The exam is intended for solution architects who design and implement production applications with Claude. The guide states that the candidate "typically has 6+ months of practical experience building with Claude APIs, Agent SDK, Claude Code, and MCP." It lists recommended experience in:

Building agentic applications with the Claude Agent SDK, including multi-agent orchestration, subagent delegation, tool integration and lifecycle hooks
Configuring Claude Code for team workflows with CLAUDE.md files, Agent Skills, MCP server integrations and plan mode
Designing MCP tool and resource interfaces for backend system integration
Engineering prompts that produce reliable structured output
Managing context windows across long documents, multi-turn conversations and multi-agent handoffs
Integrating Claude into CI/CD pipelines for code review, test generation and pull request feedback
Making escalation and reliability decisions, including error handling and human-in-the-loop workflows

Exam format

Item	Detail
Exam code	CCAR-F
Questions	60
Question types	Multiple choice and multiple response. Each question states how many answers to select.
Structure	4 scenarios, picked at random from a bank of 6
Time	120 minutes
Delivery	Proctored, online or at a test centre
Passing score	Scaled score of 720 on a scale of 100 to 1,000
Result	Pass or fail, scaled score, and percent correct by domain
Exam fee	US$125
Validity	12 months from the award date

A scaled score of 720 does not mean 72% of questions answered correctly.

What domain weights mean

The exam guide divides the exam content into five domains and gives each domain a weight. The guide explains the weights as follows:

"Weights reflect the relative importance of each domain to competent performance as determined through the job task analysis. The percentages indicate the approximate proportion of scored items drawn from each domain."

In practice, a domain weight tells you roughly what share of the scored questions come from that domain. Multiplying the weight by 60 gives an estimate of the number of questions. The actual number on your exam can differ.

Domain	Domain weight	Estimated questions
Agentic Architecture & Orchestration	27%	16
Claude Code Configuration & Workflows	20%	12
Prompt Engineering & Structured Output	20%	12
Tool Design & MCP Integration	18%	11
Context Management & Reliability	15%	9

Your result shows percent correct for each domain, so you can see which domains to study again if you need to retake the exam.

Task statements in each domain

The guide lists task statements under each domain. Each task statement has knowledge and skills listed beneath it. The task statements do not have separate weights. The second column below gives examples of what the guide lists for each one.

Agentic Architecture & Orchestration (27%)

Task statement	Examples from the guide
1.1 Design and implement agentic loops for autonomous task execution	Checking stop_reason ("tool_use" or "end_turn"), adding tool results to the conversation history, not using iteration caps as the main way to stop
1.2 Orchestrate multi-agent systems with coordinator-subagent patterns	A coordinator that routes all communication, subagents with isolated context, splitting research scope across subagents
1.3 Configure subagent invocation, context passing, and spawning	The Task tool, allowedTools, AgentDefinition, passing earlier findings in the subagent prompt, parallel Task calls
1.4 Implement multi-step workflows with enforcement and handoff patterns	Programmatic prerequisites instead of prompt instructions, structured handoff summaries for human agents
1.5 Apply Agent SDK hooks for tool call interception and data normalization	PostToolUse hooks, blocking tool calls that break a policy, choosing hooks when compliance must be guaranteed
1.6 Design task decomposition strategies for complex workflows	Prompt chaining or dynamic decomposition, per-file review passes plus a cross-file pass
1.7 Manage session state, resumption, and forking	--resume with session names, fork_session, starting a new session with a summary when tool results are stale

Tool Design & MCP Integration (18%)

Task statement	Examples from the guide
2.1 Design effective tool interfaces with clear descriptions and boundaries	Tool descriptions as the main input to tool selection, removing overlap between tools, splitting generic tools
2.2 Implement structured error responses for MCP tools	The isError flag, transient, validation, business and permission errors, retryable and non-retryable errors
2.3 Distribute tools appropriately across agents and configure tool choice	Giving each agent only the tools its role needs, tool_choice "auto", "any" and forced selection
2.4 Integrate MCP servers into Claude Code and agent workflows	Project-level .mcp.json and user-level ~/.claude.json, environment variable expansion, MCP resources
2.5 Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively	Grep for file contents, Glob for file paths, Read and Write when Edit cannot find a unique match

Claude Code Configuration & Workflows (20%)

Task statement	Examples from the guide
3.1 Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization	User, project and directory levels, @import, the .claude/rules/ directory, the /memory command
3.2 Create and configure custom slash commands and skills	.claude/commands/, .claude/skills/ with SKILL.md, the context: fork, allowed-tools and argument-hint options
3.3 Apply path-specific rules for conditional convention loading	Rules files with a paths field and glob patterns, so rules load only for matching files
3.4 Determine when to use plan mode vs direct execution	Plan mode for multi-file and architectural changes, direct execution for well-scoped fixes, the Explore subagent
3.5 Apply iterative refinement techniques for progressive improvement	Input and output examples, writing tests first, the interview pattern
3.6 Integrate Claude Code into CI/CD pipelines	The -p flag, --output-format json and --json-schema, an independent instance to review generated code

Prompt Engineering & Structured Output (20%)

Task statement	Examples from the guide
4.1 Design prompts with explicit criteria to improve precision and reduce false positives	Specific criteria instead of "be conservative", severity levels defined with code examples
4.2 Apply few-shot prompting to improve output consistency and quality	2 to 4 examples for ambiguous cases, examples for documents with different formats
4.3 Enforce structured output using tool use and JSON schemas	Tool use with JSON schemas, tool_choice settings, optional (nullable) fields, "other" plus detail fields
4.4 Implement validation, retry, and feedback loops for extraction quality	Retrying with the validation error included, knowing when a retry cannot help, detected_pattern fields
4.5 Design efficient batch processing strategies	Message Batches API (50% cost savings, up to 24-hour processing, no latency SLA), custom_id, resubmitting only failed items
4.6 Design multi-instance and multi-pass review architectures	Independent review instances, per-file passes plus cross-file integration passes

Context Management & Reliability (15%)

Task statement	Examples from the guide
5.1 Manage conversation context to preserve critical information across long interactions	A persistent "case facts" block, the "lost in the middle" effect, trimming tool output to relevant fields
5.2 Design effective escalation and ambiguity resolution patterns	When to escalate, honouring a request for a human, asking for more identifiers when several records match
5.3 Implement error propagation strategies across multi-agent systems	Structured error context, telling access failures apart from valid empty results
5.4 Manage context effectively in large codebase exploration	Scratchpad files, subagent delegation, state manifests for crash recovery, /compact
5.5 Design human review workflows and confidence calibration	Stratified sampling, accuracy by document type and field, confidence thresholds set with labelled data
5.6 Preserve information provenance and handle uncertainty in multi-source synthesis	Claim-source mappings, keeping conflicting figures with their sources, publication dates

Exam scenarios

The guide states that the exam uses scenario-based questions. Each scenario describes a production context and frames a set of questions. Four scenarios are picked at random from these six:

Scenario	Primary domains
Customer Support Resolution Agent	Agentic Architecture & Orchestration; Tool Design & MCP Integration; Context Management & Reliability
Code Generation with Claude Code	Claude Code Configuration & Workflows; Context Management & Reliability
Multi-Agent Research System	Agentic Architecture & Orchestration; Tool Design & MCP Integration; Context Management & Reliability
Developer Productivity with Claude	Tool Design & MCP Integration; Claude Code Configuration & Workflows; Agentic Architecture & Orchestration
Claude Code for Continuous Integration	Claude Code Configuration & Workflows; Prompt Engineering & Structured Output
Structured Data Extraction	Prompt Engineering & Structured Output; Context Management & Reliability

Because you do not know which four scenarios you will get, prepare for all six.

Example question

This is an original Timo practice question on task statement 1.5, in the style of the Customer Support Resolution Agent scenario. It is not an official exam question.

A support agent built with the Claude Agent SDK can close customer accounts through a close_account tool. Accounts with an unpaid balance must never be closed by the agent. Those cases must go to the billing team. The rule must hold every time.

Which approach should the team use?

A. State the rule in the system prompt and add three examples of accounts that must not be closed.

B. Add a hook that checks the balance before each close_account call, blocks the call when the balance is unpaid, and routes the case to billing.

C. Have the agent state its confidence before each closure, and send low-confidence cases to the billing team.

D. Have billing staff review a random sample of closed accounts each week, and reopen any that had an unpaid balance.

Answer: B. A hook runs in code on every close_account call, so the rule holds every time.

A relies on prompt instructions. The guide notes that prompt instructions alone have a non-zero failure rate when compliance must be deterministic.
C relies on a confidence rating from the model. The guide describes self-reported confidence as an unreliable measure of case complexity.
D finds the problem after the account is closed, so it does not meet the requirement that such accounts are never closed.

More questions in this format are in the free 20-question Claude Certified Architect practice exam for CCAR-F, which explains every answer option and does not require sign-up. For the exam format and registration steps, see the Claude Certified Architect Foundations exam guide on Timo Labs.

Official sources

Claude Certified Developer Foundations (CCDV-F): Exam Domains, Weights and Topics

Poorna Reddy — Sun, 27 Sep 2026 15:18:22 +0000

This article summarises the Claude Certified Developer Foundations (CCDV-F) exam guide published by Anthropic: what the certification validates, the exam format, what the domain weights mean, and the topics listed under each domain.

What CCDV-F validates

Anthropic's exam guide states that the certification "validates that an individual can build, integrate, and ship production-grade applications, agents, and workflows using Anthropic's Claude platform at a foundational level."

The exam is intended for technical professionals such as AI engineers, technical leads and senior software engineers. The guide recommends:

One to five years of software engineering experience
At least six months of hands-on experience with Claude or comparable LLM-based systems
Proficiency in Python and/or TypeScript
Fluency with REST APIs and CLI tools
A working understanding of LLM fundamentals, agents, context management and MCP

There are no mandatory prerequisites or required courses.

Exam format

Item	Detail
Exam code	CCDV-F
Questions	53
Question types	Multiple choice and multiple response. Each question states how many answers to select.
Time	120 minutes
Delivery	Proctored, online or at a test centre
Passing score	Scaled score of 720 on a scale of 100 to 1,000
Result	Pass or fail, scaled score, and percent correct by domain
Exam fee	US$125
Validity	12 months from the award date

A scaled score of 720 does not mean 72% of questions answered correctly.

What domain weights mean

The exam guide divides the exam content into eight domains and gives each domain a weight. The guide explains the weights as follows:

"Weights reflect the relative importance of each domain to competent performance as determined through the job task analysis and content validation surveys. The percentages indicate the approximate proportion of scored items drawn from each domain."

In practice, a domain weight tells you roughly what share of the scored questions come from that domain. Multiplying the weight by 53 gives an estimate of the number of questions. The actual number on your exam can differ.

Domain	Domain weight	Estimated questions
Applications and Integration	33.1%	17 to 18
Model Selection and Optimization	16.8%	9
Agents and Workflows	14.7%	8
Prompt and Context Engineering	11.0%	6
Tools and MCPs	10.6%	5 to 6
Security and Safety	8.1%	4
Claude Code	3.1%	1 to 2
Eval, Testing, and Debugging	2.6%	1 to 2

Your result shows percent correct for each domain, so you can see which domains to study again if you need to retake the exam.

Topics in each domain

The exam guide lists topics under each domain, each with its own weight. The descriptions below follow the guide's wording.

Applications and Integration (33.1%)

Topic	Weight	Covers
Claude Application Design	8.6%	How Claude interprets instructions across Claude Code, Desktop, claude.ai, the API and SDKs; content boundaries; schema design; session hygiene; plugin management
Software Engineering Foundations	7.4%	REST APIs, JSON, asynchronous programming, version control, SDLC integration, code review, refactoring
Claude API Mechanics	6.8%	Messages, tools, streaming, vision, thinking, caching, invoking Claude through third-party vendors, batch API use, and choosing between realtime and batch
Configuration Management	4.1%	CLAUDE.md files, settings.json, model version pinning, prompt versioning, plugin dependencies
Understanding Requirements	3.4%	Functional and infrastructure requirements based on business requirements and solution architecture
Systems Life Cycle	2.8%	Developing, implementing, operating and maintaining IT systems

Model Selection and Optimization (16.8%)

Topic	Weight	Covers
Technical Fundamentals	6.1%	Engineering practices such as integrating with SDKs that wrap REST APIs, and websockets
LLM Fundamentals	5.2%	Tokens, context windows, sampling, non-determinism, next-token generation; fast mode, extended thinking, adaptive thinking, effort levels; zero-shot, single-shot and multi-shot prompting
Cost and Token Management	2.8%	Token usage tracking, cost modelling, prompt caching, cache check-pointing
Model Selection and Tradeoffs	2.7%	Opus, Sonnet and Haiku use cases; quality, latency and cost tradeoffs; breaking behaviour changes across model releases

Agents and Workflows (14.7%)

Topic	Weight	Covers
Agent Construction with Claude	5.3%	Claude Agent SDK, custom agent loops and harnesses, self-hosted and Anthropic-hosted deployment, hooks for deterministic actions
Agent Patterns and Frameworks	4.9%	Tool-use loops, sub-agents, memory, context-window management; frameworks such as Strands, LangGraph and PydanticAI
Agent Architecture	4.5%	When to use a workflow or an agent, manager and supervisor hierarchies, subagents

Prompt and Context Engineering (11.0%)

Topic	Weight	Covers
Prompt Engineering	4.6%	Instruction clarity, few-shot examples, system and user placement, output constraints, iterative refinement, input sanitisation
Context Engineering	3.8%	Context window management, tool output pruning, compaction, context isolation through subagents
Output Handling	2.6%	Structured output, response validation, defensive parsing, skepticism toward confident output

Tools and MCPs (10.6%)

Topic	Weight	Covers
Tool Implementation	4.4%	Tool use and function calling, tool descriptions, error handling, client-side and server-side tools, approval patterns
Agentic Customization	4.1%	Choosing between built-in tools, custom tools, Skills and MCPs for a use case
MCP Server Development	2.1%	Server authoring and deployment, MCP resources, tools and prompts, stdio and other communication patterns

Security and Safety (8.1%)

Topic	Weight	Covers
AI Application Security	3.2%	Prompt injection, jailbreak defence, untrusted input, data leakage, PII handling, authentication and authorisation
Guardrails and Safe Deployment	2.3%	Content policy, guardrail layering, least privilege, identity and access management
Identity, Secrets, and Key Management	1.6%	Managing secrets, credentials and API keys across development and production
Claude Hooks	1.0%	Using hooks to prevent destructive actions

Claude Code (3.1%)

Topic	Weight	Covers
Claude Code Operation	3.1%	Rules, Skills, Commands, Agents, Agent Memory; session management, slash commands, headless mode, auto-mode; the CLAUDE.md hierarchy; settings.json

Eval, Testing, and Debugging (2.6%)

Topic	Weight	Covers
Debugging and Error Handling	2.6%	Identifying error types, choosing a recovery strategy, trace analysis, and isolating whether a problem comes from the integration layer or the model output

Largest topics

Six topics each carry more than 5% of the exam. Together they are 39.4%:

Claude Application Design: 8.6%
Software Engineering Foundations: 7.4%
Claude API Mechanics: 6.8%
Technical Fundamentals: 6.1%
Agent Construction with Claude: 5.3%
LLM Fundamentals: 5.2%

Example question

This is an original Timo practice question on Claude API Mechanics and Model Selection and Tradeoffs. It is not an official exam question.

A support team needs incoming customer emails classified into 12 categories. About 20,000 emails arrive each day, and results are needed within two days. The team has 500 emails that staff have already labelled. The chosen setup must agree with those labels at least 95% of the time. The team wants the lowest cost that meets these requirements.

Which approach should the team use?

A. Send each email as a standard request to the most capable model, and use its categories without further testing.

B. Send each email as a standard request to the smallest model, and accept categories the model marks as high confidence.

C. Choose the cheapest model that reaches 95% on the 500 labelled emails, and send daily emails through the Message Batches API.

D. Send the daily emails through the Message Batches API to the smallest model, and have staff check a random sample each morning.

Answer: C. It checks accuracy against the labelled emails before choosing a model, then uses the Message Batches API, which Anthropic charges at 50% of standard API prices. Most batches finish within an hour. Requests not processed within 24 hours expire, and the two-day requirement leaves time to resubmit them.

A does not test whether a cheaper setup reaches 95%, so it does not meet the cost requirement.
B does not measure accuracy against the labelled emails. A confidence rating from the model is not measured agreement with staff labels.
D does not check the 95% requirement before choosing the model.

More questions in this format are in the free 20-question Claude Certified Developer practice exam for CCDV-F, which explains every answer option and does not require sign-up. For the exam format and registration steps, see the Claude Certified Developer Foundations exam guide on Timo Labs.