Study guide for the Claude Certified Architect – Foundations exam
Anthropic · October 2026 exam blueprint · 161 curriculum items
Start guide
0.1 Budget context before requesting an answer
About this guide
Each bite isolates one concept or one architecture decision. Read them in order to prepare for the exam, or come back to a single bite later as a reference — the shape is the same either way, so you always know where in a lesson an answer will be.
Lessons are made to fit into the gaps between real engineering work, including the time while your coding agent is running. There is no reading-time promise attached to that, only a deliberate scope: one decision per bite.
A Lab completes when you open its official exercise — and, if it ends with a knowledge check, once you have answered that too. Anything else that carries a knowledge check — a bite, a checkpoint, a mock exam — completes when you answer every question of it; a bite without one completes when you say so. Completion only accumulates — nothing here takes it back.
Prerequisites
Outside the exam blueprint0 of 6 items completed
- 0.1 Budget context before requesting an answerSeparate learned model behavior from supplied evidence and reserve token capacity for both input and output.
- 0.2 Read Messages as typed content blocksIdentify the Messages API request fields, conversational roles, response envelope, and typed content blocks, and resend the conversation history on every stateless call.
- 0.3 Separate required fields from nullable valuesDefine Claude client-tool input schemas that keep data types, property presence, and null values apart.
- 0.4 Tell async calls and batches from retriesDistinguish blocking calls, async clients, deferred batches, and failure recovery without multiplying retries.
- 0.5 Make command runs reproducible in CIInterpret command flags, Git state, configuration scope, environment variables, and exit status in automated Claude workflows.
- 0.6 Check availability before approving tool useSeparate tool exposure, pre-approval, explicit denial, and human confirmation in Claude Code workflows.
Agentic Architecture & Orchestration
27% of the exam0 of 36 items completed
Design and implement agentic loops for autonomous task execution
- 1.1.1 Drive execution from the stop reasonRoute Messages API responses to tool execution, turn completion, or explicit recovery using stop_reason.
- 1.1.2 Preserve every call and matching resultBuild valid Messages API history that preserves assistant content and resolves each requested tool call by its identifier.
- 1.1.3 Choose who decides the next toolDistinguish model-selected actions from decision trees and fixed sequences, and assign each to the work it can control reliably.
- 1.1.4 Separate completion signals from execution safeguardsReplace text-based and counter-based termination rules with protocol decisions and distinct incomplete outcomes.
- 1.1.5 Assign ownership of the execution loopChoose a Messages API loop or Agent SDK harness and place tool execution, permissions, hooks, and stopping policy with the right owner.
- LABBuild a Multi-Tool Agent with Escalation LogicBuild a stop_reason-driven agent over MCP tools with structured errors and a hook that escalates over-threshold operations.
Orchestrate multi-agent systems with coordinator-subagent patterns
- 1.2.1 Route worker outcomes through one coordinatorDesign coordinator-owned delegation, result aggregation, and failure handling without assuming subagents share conversation history.
- 1.2.2 Partition research without shrinking the questionAssign complementary investigations that preserve every decision criterion and expose missing coverage before synthesis.
- 1.2.3 Select specialists for the work requiredMatch task complexity to specialist delegation and avoid paying for a fixed multi-agent pipeline on every request.
- 1.2.4 Repair evidence gaps before accepting synthesisEvaluate research coverage, delegate targeted follow-up work, and repeat synthesis until the evidence supports a sufficient answer.
- LABDesign and Debug a Multi-Agent Research PipelineBuild a coordinator that runs research subagents in parallel, carries attributed findings and failures, and synthesizes conflicting evidence.
- LABMulti-Agent Research SystemRun an Agent SDK lead agent that delegates research, analysis and report writing to subagents, and trace each subagent's tool calls.
Configure subagent invocation, context passing, and spawning
- 1.3.1 Give each specialist an executable contractDefine subagents whose delegation descriptions, system prompts, output requirements, and tool sets match their assigned roles.
- 1.3.2 Delegate through the Agent toolEnable Agent-based specialist delegation while distinguishing tool availability, permission pre-approval, and application-owned API calls.
- 1.3.3 Pass the context each specialist needsConstruct self-contained subagent assignments with required instructions and prior findings while accounting for forks, resumption, and configured memory.
- 1.3.4 Keep evidence attached to its attributionDesign structured subagent handoffs that preserve supporting content separately from source identifiers, document names, and precise locations.
- 1.3.5 Launch independent investigations before awaiting synthesisArrange concurrent subagent calls and sequential dependent stages without confusing delegation with execution order.
- 1.3.6 Delegate outcomes with testable evidence criteriaWrite specialist assignments that define the result, supporting evidence, and acceptance criteria while preserving research adaptability.
- 1.3.7 Choose a fork or a fresh specialistSelect history-based session forks or fresh subagents according to the context an alternative investigation needs.
Implement multi-step workflows with enforcement and handoff patterns
- 1.4.1 Enforce prerequisites before executing a toolPlace mandatory workflow ordering in a tool dispatcher or blocking hook that checks trusted prerequisite state.
- 1.4.2 Check every condition before issuing refundsGate sensitive tool execution on trusted identity, authorization, and business-policy evidence rather than model-supplied approval claims.
- 1.4.3 Investigate each concern before resolving the casePartition a customer request into independent investigations, pass shared case facts explicitly, and synthesize one supported resolution.
- 1.4.4 Hand humans a case they can act onBuild a structured escalation that preserves customer identifiers, evidence-backed findings, distinct monetary amounts, and actionable recommendations.
Apply Agent SDK hooks for tool call interception and data normalization
- 1.5.1 Reject prohibited calls before tools executePlace a synchronous PreToolUse policy check before sensitive tool execution and return an explicit denial with a permitted next step.
- 1.5.2 Normalize results without breaking tool shapesReplace heterogeneous tool results through PostToolUse while preserving output contracts, timestamp meaning, and error evidence.
- 1.5.3 Test policy independently of model complianceSeparate tool access, deterministic business-policy checks, and prompt guidance, then verify prohibited operations never reach execution.
Design task decomposition strategies for complex workflows
- 1.6.1 Choose decomposition from what you knowSelect a fixed prompt chain or adaptive task decomposition by deciding whether evidence changes the work that must happen next.
- 1.6.2 Separate file reviews from integration checksBuild a focused review chain that carries file-level evidence into a distinct cross-file integration pass.
- 1.6.3 Revise the plan when evidence changesTurn intermediate investigation findings into targeted follow-up questions while preserving the original goal and verification criteria.
- 1.6.4 Map legacy behavior before choosing testsBuild a prioritized legacy-code testing plan from architecture, behavioral risk, existing tests, and dependencies discovered during exploration.
- LABBasic Multi-LLM WorkflowsImplement prompt chaining, parallelization and routing as small Python functions over the Messages API.
- LABOrchestrator-Workers WorkflowBuild an orchestrator that decides its subtasks at runtime and hands each one to a worker call with full context.
Manage session state, resumption, and forking
- 1.7.1 Resume the session your investigation needsResume a named Claude Code investigation or an identified Agent SDK session while checking that its saved context remains useful.
- 1.7.2 Fork peer sessions from one shared baselineFork Claude Code or Agent SDK conversation history into independently resumable alternatives without confusing history isolation with file isolation.
- 1.7.3 Recover a session from stale tool resultsChoose targeted re-analysis or a fresh session with a structured summary according to how much prior file evidence remains valid.
- LABBuilding a Session BrowserList, read, label, fork and resume stored Agent SDK sessions from their transcripts on disk.
Tool Design & MCP Integration
18% of the exam0 of 26 items completed
Design effective tool interfaces with clear descriptions and boundaries
- 2.1.1 Describe tools so selection becomes explicitWrite tool contracts that distinguish purpose, input formats, returned evidence, examples, edge cases, and alternative operations.
- 2.1.2 Repair tool ambiguity before adding routingDiagnose wrong-tool selection and repair names, descriptions, and responsibility boundaries before introducing a routing layer.
- 2.1.3 Choose tool granularity by the outcomeSplit unrelated tool responsibilities and consolidate redundant operations while preserving clear input and output contracts.
- 2.1.4 Remove keyword rules that misdirect toolsAudit system-prompt instructions and examples for accidental tool associations, then verify repairs through actual tool calls.
Implement structured error responses for MCP tools
- 2.2.1 Separate execution failures from protocol errorsChoose the MCP result or protocol error that preserves the meaning of a failed call or successful empty query.
- 2.2.2 Classify failures before choosing recoveryDefine structured tool error categories, retryability, and explanations that identify the next permitted recovery action.
- 2.2.3 Explain rejected requests without inviting retriesReturn final business-rule failures with non-retryable metadata and a customer-safe explanation of the permitted next step.
- 2.2.4 Distinguish no matches from inaccessible dataPreserve successful no-match evidence while directing access failures into the appropriate recovery path.
- 2.2.5 Bound retries and preserve unresolved evidenceKeep transient recovery local and bounded while propagating unresolved failures with attempted steps and partial results.
Distribute tools appropriately across agents and configure tool choice
- 2.3.1 Expose only tools each role needsDesign role-specific tool menus that reduce selection ambiguity and keep specialist capabilities within their assignments.
- 2.3.2 Replace arbitrary fetching with validated loadingDesign a document-loading operation whose schema, execution checks, and results keep retrieval within an approved evidence set.
- 2.3.3 Give synthesis one bounded verification toolSeparate frequent local fact checks from broader investigations that require coordinator routing.
- 2.3.4 Choose whether a turn requires toolsCompare the four tool_choice modes and distinguish optional calls, required calls, named calls, and tool-free responses.
- 2.3.5 Gate required first steps before enrichmentUse supported tool forcing for initial calls and preserve prerequisite order through application control flow when forcing is unavailable.
- LABTool choiceRun the same tools under the auto, named-tool and any settings of tool_choice and compare which calls Claude makes.
Integrate MCP servers into Claude Code and agent workflows
- 2.4.1 Choose project or personal MCP scopeChoose MCP installation scopes that share team tooling while keeping personal configurations private.
- 2.4.2 Expand credentials without committing their valuesConfigure MCP credential references and diagnose missing or protected environment variables without storing secrets in shared files.
- 2.4.3 Combine server capabilities without assuming readinessExplain multi-server tool discovery while separating configuration, connection status, schema loading, and permission.
- 2.4.4 Describe the evidence each search tool returnsDifferentiate MCP capabilities from local file search through precise tool descriptions, server instructions, and observed selection.
- 2.4.5 Expose catalogs before requesting detailed evidenceUse URI-addressed MCP resources to supply context catalogs while preserving the distinction between host-selected context and tool invocation.
- 2.4.6 Reuse integrations and own specialized contractsEvaluate existing MCP integrations against their actual capabilities and build custom servers for requirements the available contracts do not meet.
- LABDefining resourcesDefine a direct and a templated MCP resource with the Python SDK and inspect what a client receives.
Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively
- 2.5.1 Separate content searches from path discoveryChoose Grep or Glob from the evidence you need and interpret scoped, truncated, or ignored-file results correctly.
- 2.5.2 Match file operations to their effectsSelect Read, Write, Edit, or Bash by the required operation, preservation needs, and command side effects.
- 2.5.3 Recover ambiguous edits without widening intentResolve non-unique Edit anchors through fresh reads, precise matching, and a complete replacement only when the file can be preserved safely.
- 2.5.4 Follow exported names to indirect callersTrace a behavior across imports, re-exported aliases, and wrapper functions using a bounded sequence of searches and reads.
Claude Code Configuration & Workflows
20% of the exam0 of 31 items completed
Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization
- 3.1.1 Put team instructions where everyone receives themChoose user, project, local, and directory instruction files and diagnose conventions that never reach teammates.
- 3.1.2 Import the standards each package needsCompose package instructions with verified import paths while accounting for parsing, nesting, approval, and context cost.
- 3.1.3 Split standing conventions into focused rule filesReplace a monolithic instruction file with maintainable topic rules and distinguish automatic discovery from conditional loading.
- 3.1.4 Inspect instruction loading before rewriting rulesUse memory-file editing, launch-context inspection, and loading evidence to diagnose inconsistent Claude Code sessions.
- LABConfigure Claude Code for a Team Development WorkflowConfigure a shared Claude Code project with CLAUDE.md, path-scoped rules, a forked skill and MCP servers, then test plan mode.
Create and configure custom slash commands and skills
- 3.2.1 Share workflows without shadowing team skillsPlace shared commands and skills in the repository and give personal variants distinct names so a personal copy does not shadow the team’s skill on your machine.
- 3.2.2 Author SKILL.md and keep command files workingSeparate SKILL.md frontmatter from workflow instructions and preserve working command files while choosing a directory-based skill when it adds value.
- 3.2.3 Show arguments without assuming input validationUse argument-hint for autocomplete guidance and separate argument substitution from checks that determine whether a workflow can proceed.
- 3.2.4 Give forked skills self-contained research tasksUse context: fork to isolate extensive investigation while supplying the task, constraints, and result contract a fresh subagent needs.
- 3.2.5 Separate skill approval from tool restrictionConfigure temporary skill tool grants and explicit restrictions without treating allowed-tools as an exclusive tool list.
- 3.2.6 Choose between a skill and CLAUDE.mdKeep universal project guidance in CLAUDE.md and move task-specific procedures into skills with deliberate invocation controls.
- LABCreating your first skillWrite a personal SKILL.md that formats pull request descriptions and see how Claude Code matches and loads it.
Apply path-specific rules for conditional convention loading
- 3.3.1 Load conventions when matching files need themConfigure YAML paths frontmatter and distinguish conditional rule loading from unconditional instructions and parse failures.
- 3.3.2 Match conventions to dispersed file typesChoose path globs that reach scattered files, preserve intended exclusions, and keep extension and directory scopes distinct.
- 3.3.3 Centralize conventions that cross directory ownershipChoose path-scoped rules for shared cross-directory conventions while retaining directory CLAUDE.md files for locally owned guidance.
Determine when to use plan mode vs direct execution
- 3.4.1 Weigh four signals before choosing plan modeChoose planning or implementation from design uncertainty, affected scope, behavioral risk, and competing approaches.
- 3.4.2 Investigate in plan mode before multi-file editsUse Claude Code planning controls to discover dependencies and design complex changes while recognizing the limits of read-only enforcement.
- 3.4.3 Keep verbose discovery inside ExploreDelegate bounded codebase searches to Explore and preserve the findings the main conversation needs for design and implementation.
- 3.4.4 Implement only after reviewing the planReview a migration plan, select implementation permissions, and verify execution against the agreed design.
Apply iterative refinement techniques for progressive improvement
- 3.5.1 Show the transformation before rewriting instructionsClarify an inconsistently interpreted transformation with varied input/output pairs and explicit rules for unresolved cases.
- 3.5.2 Define passing behavior before implementing codeDrive Claude Code iteration with prewritten checks for normal behavior, edge cases, and relevant performance requirements.
- 3.5.3 Reproduce the failing edge case preciselyGive Claude Code a focused correction request containing the actual input, expected output, observed failure, and reproduction command.
- 3.5.4 Interview before choosing an unfamiliar designUse Claude Code's AskUserQuestion interview pattern to surface requirements, alternatives, and failure modes and produce a self-contained implementation specification.
- 3.5.5 Group corrections by how fixes interactGive Claude Code interacting fixes in one coherent request and verify independent issues in separate sequential rounds.
Integrate Claude Code into CI/CD pipelines
- 3.6.1 Bound unattended jobs with explicit controlsConfigure print mode, tool permissions, turn limits, and GitHub Actions inputs for unattended Claude Code jobs.
- 3.6.2 Return findings through a validated schemaDistinguish the JSON result envelope from schema-validated findings and gate automated consumers on a complete structured result.
- 3.6.3 Choose context loading for each CI jobPreserve automatic project instructions in ordinary print runs or supply explicit context when bare mode disables discovery.
- 3.6.4 Generate CI tests from standards, fixtures, and coverageGive CI test generation concrete standards, fixtures, and existing tests so it targets missing behavior instead of duplicate coverage.
- 3.6.5 Review changes without the authoring historyStart a separate review context with code and criteria while excluding generator reasoning and accidental session resumption.
- 3.6.6 Reconcile prior findings against changed codeSupply earlier review findings and the updated diff so repeat reviews distinguish unresolved issues from new defects and resolved comments.
- LABAuto-Retry Flaky TestsRun Claude Code in GitHub Actions after a failed CI run, classify the failure against a JSON schema, and retry only on a confident flaky verdict.
Prompt Engineering & Structured Output
20% of the exam0 of 31 items completed
Design prompts with explicit criteria to improve precision and reduce false positives
- 4.1.1 Define which defects deserve a findingWrite categorical review rules that distinguish reportable defects from style preferences, local conventions, and harmless comments.
- 4.1.2 Separate confidence filtering from defect detectionDiagnose why qualitative reporting thresholds can hide real bugs without correcting an ambiguous defect definition.
- 4.1.3 Anchor severity labels in observable effectsDefine a severity rubric with concrete code examples and contextual evidence so similar defects receive consistent classifications.
- 4.1.4 Pause noisy categories and verify their repairMeasure category-level review noise, temporarily suppress unreliable categories, and evaluate revised detection rules before restoring them.
- LABCode Review PluginRun Claude Code's /code-review plugin on a pull request and study how its parallel agents and validation step decide which findings survive.
Apply few-shot prompting to improve output consistency and quality
- 4.2.1 Teach decisions with targeted worked examplesSelect a small set of examples that resolves ambiguous choices and demonstrates judgment that transfers to unseen cases.
- 4.2.2 Contrast acceptable code with true defectsDesign paired review examples that reduce false positives while preserving detection of unfamiliar defects.
- 4.2.3 Show findings a developer can act onDemonstrate consistent review outputs with precise locations, evidence-backed issues, calibrated severity, and concrete suggested fixes.
- 4.2.4 Extract evidence across layouts and omissionsBuild extraction examples that recover embedded facts, preserve informal measurements, and distinguish absent values from overlooked evidence.
- LABBuild a Structured Data Extraction PipelineBuild an extraction pipeline with a tool schema, a validation-retry loop, few-shot examples, Message Batches and confidence-based human review.
Enforce structured output using tool use and JSON schemas
- 4.3.1 Read extracted records from tool inputsDefine an extraction tool contract and consume its typed response blocks without parsing a prose answer.
- 4.3.2 Choose native JSON, strict tools, or promptingCompare native JSON responses, strict tool inputs, and prompt-only JSON by enforcement and workflow fit.
- 4.3.3 Route documents before allowing enrichment callsChoose supported extraction-call forcing and enforce metadata prerequisites when model selection remains optional.
- 4.3.4 Make missing and uncertain evidence representableDesign nullable fields and category escape values that preserve absent, ambiguous, and unlisted source evidence.
- 4.3.5 Normalize source values without inventing evidencePair a strict output contract with explicit rules for dates, amounts, and unresolved source conventions.
- 4.3.6 Validate meaning after checking record structureSeparate schema conformance from source accuracy and identify checks for inconsistent totals, swapped values, and unsupported facts.
- 4.3.7 Route structured failures by their causeIdentify unsupported schemas, refusals, truncation, and missing tool calls, then choose a supported recovery path.
- LABExtracting Structured JSON using Claude and Tool UseDefine tools whose input_schema shapes the output, and read structured JSON from Claude's tool_use blocks.
Implement validation, retry, and feedback loops for extraction quality
- 4.4.1 Validate totals against their source evidenceWrite application validators that recompute totals, compare them with printed amounts, and verify reported source conflicts.
- 4.4.2 Retry extractions with precise error feedbackBuild correction requests that retain source evidence, failed values, and actionable validation errors, then validate the corrected record again.
- 4.4.3 Stop retries when source evidence is absentDistinguish overlooked evidence from unavailable evidence and route incomplete extractions without pressuring the model to invent values.
- 4.4.4 Diagnose failures with pattern and conflict fieldsUse detected_pattern and conflict_detected for separate diagnostic questions and turn reviewed outcomes into targeted quality improvements.
Design efficient batch processing strategies
- 4.5.1 Keep blocking work on synchronous MessagesChoose synchronous Messages requests or Message Batches from the workflow's blocking dependencies and tolerance for delayed results.
- 4.5.2 Know what the batch discount cannot buyExplain batch pricing, expiration, timing uncertainty, and the difference between client-tool round trips and server-tool execution.
- 4.5.3 Reserve recovery time before promising deliveryPlan batch cadence, expiration-risk buffers, and fallback cutoffs without turning a processing window into a completion guarantee.
- 4.5.4 Recover failed entries by their identifiersJoin unordered batch results by custom_id and choose targeted repair, retry, or separate resubmission from each entry's outcome.
- 4.5.5 Prove the sample before scaling submissionsRefine prompts on representative inputs and preflight document size, polling, and rerun behavior before submitting large batches.
- LABBatch Processing with Message Batches APISubmit, poll and read back a Message Batch, including mixed request types and every per-request result type.
Design multi-instance and multi-pass review architectures
- 4.6.1 Distinguish independent review from self-review and effortChoose an independent review context that checks generated code against requirements without inheriting the generator's reasoning.
- 4.6.2 Partition large reviews to prevent attention dilutionPartition large code reviews into focused per-file checks and a separate pass that traces contracts and data flow across files.
- 4.6.3 Verify findings before trusting confidence scoresRe-check candidate defects, calibrate confidence against labeled outcomes, and choose evidence-based thresholds for human review.
Context Management & Reliability
15% of the exam0 of 31 items completed
Manage conversation context to preserve critical information across long interactions
- 5.1.1 Replay history on every stateless requestAssemble stateless Messages requests that preserve relevant turns, typed content, and unresolved work across long conversations.
- 5.1.2 Preserve exact facts through every summaryKeep amounts, percentages, dates, statuses, and customer expectations in a persistent record supplied independently of summarized history.
- 5.1.3 Keep each concern in its own recordPreserve order identifiers, monetary values, and resolution status in separately structured issue records throughout a multi-concern session.
- 5.1.4 Trim results before they enter contextReduce tool output to decision-relevant fields while preserving identifiers, qualifications, errors, and supported output shapes.
- 5.1.5 Put findings where synthesis can use themArrange aggregated findings, labeled evidence, and the final query to reduce omissions in long inputs without claiming guaranteed recall.
- 5.1.6 Return findings with their decision metadataDefine concise upstream research outputs that preserve claim attribution, dates, methods, and relevance for downstream synthesis.
- LABContext Engineering for AI Agents: Memory vs. Compaction vs. Tool ClearingRun a long research agent with compaction, tool-result clearing and the memory tool, and compare what each keeps and loses.
Design effective escalation and ambiguity resolution patterns
- 5.2.1 Route cases by authority and progressDefine human-request, policy, and blocked-progress triggers without escalating solely because a case is complicated.
- 5.2.2 Honor human requests before investigatingSequence immediate human handoff ahead of lookups or resolution attempts and distinguish transfer acceptance from a promise.
- 5.2.3 Offer covered help to frustrated customersAcknowledge frustration, offer an authorized resolution, and switch to immediate handoff when the customer requests a person.
- 5.2.4 Route on evidence rather than scoresDistinguish customer sentiment and uncalibrated confidence from the policy, preference, and progress evidence that justifies escalation.
- 5.2.5 Teach escalation decisions with contrastive examplesWrite explicit routing criteria and targeted few-shot examples that separate authorized resolution, clarification, and human handoff.
- 5.2.6 Ask for identifiers before selecting recordsResolve multiple lookup matches through targeted identifier questions without guessing which customer or record should receive an action.
Implement error propagation strategies across multi-agent systems
- 5.3.1 Carry source outcomes intact to the coordinatorDistinguish unsuccessful source access from completed searches with no matches without turning missing evidence into negative findings.
- 5.3.2 Return failures the coordinator can act onDesign a failure handoff that preserves the cause, attempted query, partial findings, and viable recovery alternatives.
- 5.3.3 Recover locally before changing the research planAssign bounded transient recovery to the specialist and reserve modified queries, alternate sources, and partial completion for the coordinator.
- 5.3.4 Deliver useful findings with visible coverage gapsSynthesize supported partial findings while identifying unanswered topics and preserving the difference between failed access and completed empty searches.
Manage context effectively in large codebase exploration
- 5.4.1 Delegate searches and retain the coordination mapOffload narrow investigations to subagents and retain evidence-bearing summaries that keep the main exploration context compact.
- 5.4.2 Persist findings with their file evidenceMaintain scratchpads of verified symbols, dependencies, and open questions so later investigation phases can recover precise codebase facts.
- 5.4.3 Compact discovery and restore critical factsInspect context usage, preserve evidence before compaction, and verify and reload the facts needed to continue a codebase investigation.
- 5.4.4 Carry verified summaries into each phaseBuild task-specific phase handoffs that give successive explorations verified evidence and open questions without importing irrelevant discovery transcripts.
- 5.4.5 Restore investigations from indexed worker stateDesign per-agent state exports and a coordinator-readable manifest that recover verified progress and restart only the unfinished investigation work.
Design human review workflows and confidence calibration
- 5.5.1 Expose weak fields before reducing reviewMeasure extraction accuracy by document type, field, and their intersections before deciding which results can bypass human review.
- 5.5.2 Turn confidence scores into tested thresholdsCompare field-level confidence with labeled outcomes and choose review thresholds from measured accuracy and acceptance coverage.
- 5.5.3 Audit accepted results across every stratumSample high-confidence extractions within defined groups to measure accepted-set error rates and discover unfamiliar failure patterns.
- 5.5.4 Send unresolved evidence to targeted reviewPrioritize field-level human review using calibrated confidence, ambiguous evidence, and source conflicts without accepting contradictions on a high score.
Preserve information provenance and handle uncertainty in multi-source synthesis
- 5.6.1 Carry evidence through every synthesis stepPreserve the relationship between claims, excerpts, and source locations when research crosses agent boundaries.
- 5.6.2 Compare findings against their observation periodsDistinguish publication dates, observation periods, and retrieval times before classifying differences as conflicting evidence.
- 5.6.3 Return conflicting values for coordinator reviewPreserve credible incompatible values with their sources and methods so the coordinator can choose an explicit reconciliation.
- 5.6.4 Separate findings by their evidential supportDistinguish supported conclusions, unresolved disputes, and research gaps while preserving each source’s methodological qualifications.
- 5.6.5 Render financial, news, and technical findings differentlyChoose tables, prose, and structured lists that preserve comparability, chronology, and technical conditions in synthesis.