AnthropicClaude Certified Architect – Professional2026-101.5 Apply decomposition techniques for complex problem solving
Size subtasks around verifiable completion
Completed by the knowledge check
Learning objective
Decompose outcomes into independently verifiable subtasks with explicit completion criteria, sized to context and attention limits.
Core idea
A useful subtask ends at a result you can inspect without reconstructing the worker’s entire investigation. For an architect, the additional design question is whether that result remains verifiable when document volume, prompt size, and concurrent work grow. A clearly worded assignment can still be too large to perform reliably.
Anthropic describes context as a finite attention budget: adding material can reduce retrieval and reasoning precision before a request reaches its capacity limit. Size the work around the evidence and decisions it must preserve, rather than filling every available token. Keep the original outcome as the acceptance baseline, so smaller tasks do not quietly discard difficult obligations.
How it works
Give each cut an acceptance test
Anthropic’s prompt-chaining pattern supports programmatic gates between calls. Use a boundary where a gate can establish something useful: an extraction is attributable, all requested categories have an outcome, or the next analysis has the inputs it needs. Do not split a task merely because its prompt contains several verbs.
For a document review, distinguish these completion checks:
| Check | What your application verifies | What it does not establish |
|---|---|---|
| Identity | The result belongs to the assigned document version | The interpretation is correct |
| Coverage | Every required question has a returned outcome | A reported absence is true |
| Evidence | A quoted passage exists at the supplied location | The passage supports the conclusion |
| Interpretation | The conclusion follows the review rubric | The whole enterprise decision is complete |
These are proposed application checks, not Anthropic response fields. Implement exact identity and coverage comparisons in code. Use a rubric-based evaluator or qualified reviewer for interpretation. Use Anthropic’s research-system rubric as the documented basis for those judgments; see 1.5.4.
An independently verifiable subtask need not be independent to execute. An interpretation can depend on an accepted extraction while still having its own inputs, expected result, and test. See 1.5.3 for scheduling dependencies. Here the boundary earns its place because you can localize a defect and decide whether to accept or repair that result.
Preserve explicit unsuccessful outcomes
Define completion as accounting for the assigned questions, including uncertainty. In an example extraction contract, use application statuses such as found, not_found, and unresolved. A missing category is a contract failure; not_found is a substantive result requiring validation. unresolved accounts for the question without pretending the business decision is settled.
Attach the input identity and version through application code. Ask Claude for evidence locations and explanations that only analysis can supply. A worker should not invent the trusted identity of the material it received. Keep the output’s claims separable, so a reviewer can reject one unsupported interpretation without throwing away unrelated accepted evidence.
Place these expectations in the task’s prompt and test them after the call. A prompt is the specification; the gate is the acceptance mechanism. See 1.2.3 for structured interfaces and their validation. This lesson’s completion record does not replace that interface design.
Measure input fit, then test attention fit
For supported request inputs, POST /v1/messages/count_tokens estimates input size. The Python SDK exposes client.messages.count_tokens(...); the response includes input_tokens. Count the assembled request with the intended model, including instructions and evidence, rather than estimating from document count alone.
Respect the endpoint’s boundary: client tools are supported, while server tools other than the advisor tool return an error. It also rejects the MCP connector and image or document blocks using url or file sources; images and PDFs need base64 for counting. The count is an estimate, so it is not a proof that a subsequent request fits exactly. For server-tool or MCP workloads, use the Messages response’s usage for observed consumption.
Token fit is only the first check. Compare candidate task sizes on representative inputs with known answers. Measure omitted obligations, incorrect attribution, and unsupported conclusions at each size. A task that fits but repeatedly misses a schedule referenced elsewhere in the document is too broad or incorrectly partitioned for this workload. There is no universal attention threshold to copy from another application.
Preserve semantic dependencies while reducing size. Splitting a policy by page count can separate an exception from the rule it qualifies. A better assignment includes the rule, its definitions, and relevant exceptions even when that produces unequal token counts across workers. Partition by evidence needed to answer a question, then measure the resulting request.
Size the returned artifact as well
Anthropic’s context-engineering account describes focused subagents returning distilled results while keeping detailed exploration outside the coordinator’s context. Its research-system account also recommends persistent artifacts with lightweight references to reduce information loss and repeated copying.
Apply that pattern to your task contract: return a concise verdict and coverage summary, plus an accessible artifact holding accepted claims, excerpts, and source locations. Do not compress away the evidence needed for the acceptance check. If synthesis must reread every full source because the handoff contains only conclusions, the decomposition has transferred rather than reduced the context burden.
Key distinctions and trade-offs
Small versus sufficient: A smaller prompt helps only when it retains the evidence needed for the assigned question. Removing definitions to meet a token target can make the task unsound.
Local completion versus overall completion: A worker can complete its assignment while the original outcome still has unassigned requirements. Integration checks belong to 1.5.4.
More boundaries versus better diagnosis: Additional calls provide inspection points but add latency and handoffs. Keep a cut when evaluation shows better defect detection or focused reasoning that justifies its cost.
Architecture / decision scenario
A healthcare technology team must review 180 internal operating policies before a quarterly release. Two reviewers can inspect exceptions, but cannot reread every generated report. The architect must choose between one large review per department and smaller evidence-based assignments.
The architect defines one policy-question result with document version, outcome, passage location, and interpretation. Code checks identity and required-question coverage; a reviewer checks consequential interpretations against the policy rubric. unresolved results remain visible rather than passing as absent requirements.
The team uses client.messages.count_tokens(...) on its text-only requests, then evaluates several task sizes on policies with known cross-references. Department-sized prompts fit but miss exceptions; page-sized prompts lose definitions. Policy-sized assignments including referenced definitions preserve the deciding evidence and meet the team’s acceptance criteria. Workers return compact coverage summaries with evidence artifacts, so reviewers inspect the disputed records directly. The architect accepts that granularity because it makes completion testable within the available attention and review capacity.
Common exam traps
- Equating a request below the context limit with reliable attention to every requirement.
- Defining completion as a finished call or a count of searches.
- Treating an omitted question as a verified negative finding.
- Splitting by equal page counts while separating rules from exceptions.
- Sending only a compressed verdict when the next stage must verify its evidence.
What to remember
Cut where a result can be independently checked. Measure input size with the documented counting mechanism where supported, then evaluate attention and attribution on realistic tasks. Preserve semantic context and return enough evidence to accept or repair each result.
Knowledge check
A legal-operations team reviews 300 vendor contracts against twelve required questions. Each department-sized request is below the model’s context window according to count_tokens, but on contracts with known answers the workers repeatedly miss exceptions that qualify rules defined in other sections. Which change should the architect make?
A worker reviewing one contract must return an outcome for each of twelve required questions. Its result contains eleven outcomes with valid evidence locations; the data-residency question is absent. How should the application’s acceptance gate treat the result?
not_found for that contractnot_found is a substantive result that itself needs validation, so writing it in for an omitted question turns silence into a verified negative. Identity and evidence checks establish other properties and cannot show that every required question was accounted for.Workers in a policy-review pipeline return only a final verdict per policy. The synthesis stage must verify each verdict before release, so it rereads every full policy document and has become the slowest, most expensive stage. Which handoff change addresses this?
Before choosing a task size, a team counts the input tokens of its assembled Claude API requests with POST /v1/messages/count_tokens. The requests attach PDF policies as document blocks that reference uploaded files by file source, and the counting call returns an invalid_request_error. How should the team measure input size?
document blocks in the counting requestfile source to a url source in the counting requestimage and document blocks with a url or file source; images and PDFs must be sent as base64 to be counted. A url source is rejected exactly as a file source is, and estimating the PDFs separately abandons the documented measurement. Even the base64 count is an estimate, so attention fit still needs testing on known answers.References
- Anthropic, Building effective agents
- Anthropic, Effective context engineering for AI agents
- Anthropic, How we built our multi-agent research system
- Anthropic, Token counting