AnthropicClaude Certified Architect – Professional2026-103.3 Evaluate accuracy-latency trade-offs and justify configuration decisions
Bound thoroughness by the task deadline
Completed by the knowledge check
Learning objective
Apply latency budgets and time awareness to agentic tasks so thoroughness stays within user tolerance
Core idea
For an architect operating an interactive agent, useful thoroughness ends where the user’s task tolerance ends. A careful answer delivered after the user abandons the workflow has failed the service requirement. Define the deadline for an accepted outcome, reserve time to produce it, and let optional investigation consume only the remaining allowance.
The deadline belongs to the complete task. output_config.effort influences token spending, and the TypeScript Agent SDK’s maxTurns bounds tool-use round trips. Neither quantity expresses elapsed seconds, and neither does the model-visible output_config.task_budget. Combine model guidance with runtime controls instead of treating effort, turns, or tokens as a clock.
How it works
Turn the user tolerance into a task budget
Anthropic’s evaluation guidance includes acceptable latency as a success criterion and recommends multidimensional evaluation. Translate that criterion into two concrete artifacts: a task latency budget and a completion policy. The budget assigns time to the actual stages; the policy defines which outcomes count as useful and what the user receives when time expires.
For an interactive Agent SDK workflow, include admission delay, retrieval, agent reasoning, tools, and final response handling. Start the application clock when the request enters the user journey, rather than when the first model call starts. A task waiting in a queue has already spent part of its allowance.
Budget required work before optional work. If a recommendation needs a policy lookup and a safety review, reserve their time plus response assembly before admitting another exploratory agent. Otherwise the agent can exhaust its allowance gathering material and leave no time to return a usable result. The resulting artifact should name the owner of each required stage and the explicit deferred or incomplete outcome.
Use a remaining-time test when considering another step:
remaining = task deadline - elapsed time
optional work fits only when:
remaining >= estimated step duration + required finishing reserveThis is an application scheduling rule, not a Claude request field. Estimate stage duration from workload measurements, including the tail under expected load. A percentile estimate supports admission decisions; it does not guarantee the next operation will finish in that time. Keep runtime cancellation available even when the estimate says the step fits.
Give the agent actionable time information
For a Claude API agentic loop on a supported model, the documented model-visible countdown is output_config.task_budget: {"type": "tokens", "total": N} with anthropic-beta: task-budgets-2026-03-13; see 2.4.1 for its token mechanics. It is beta on Claude Sonnet 5.5, for example, and unsupported on Sonnet 5. It is a soft hint, not a hard cap, and its minimum accepted total is 20,000 tokens. A budget too small for the task can make Claude decline, scope down aggressively, or stop early. Do not force a short interaction into the feature by supplying an invalid smaller value.
To use that countdown for latency planning, estimate a token allowance from measured throughput after reserving time for tools and required finishing work. Tokens and seconds do not convert at one universal rate: compare the allowance against the task’s measured duration distribution. max_tokens remains the enforced per-request output limit, while host cancellation still enforces the elapsed-time deadline. The API field is separate from the TypeScript Agent SDK controls described next.
Put task priorities, the time allowance, and required stopping behavior in the instruction supplied to query(). Name optional investigations, mandatory checks, and the acceptable incomplete outcome. Refresh remaining time through host-provided context at tool-result boundaries, keeping changing time values outside the cached stable prefix; see 2.5.1. These instructions complement the token countdown where supported and give the host’s measured seconds a meaning in the task.
Time awareness guides allocation. Runtime enforcement remains necessary because a tool or inference operation can outlast the allowance before another instruction boundary arrives. Measure whether pacing reduces unnecessary round trips without damaging required coverage.
Pair guidance with the deployed controls
The TypeScript Agent SDK provides abortController as an AbortController option for cancelling operations. Have the host trigger cancellation when the task deadline is reached. This connects the application’s measured wall clock to a documented runtime control rather than relying on the agent to volunteer a stop. The host refreshes remaining time at tool-result boundaries and triggers cancellation when the task deadline is reached.
Use maxTurns as an additional bound on tool-use round trips. A three-turn run with slow tools can exceed a ten-second deadline; a ten-turn run with fast tools can finish inside it. The two controls address different failure modes. See 1.3.3 for agent-loop limits; this lesson adds the elapsed-time decision around them.
The SDK’s maxBudgetUsd bounds a client-side cost estimate, not seconds. Its documentation warns that the estimate can pass the configured value. Do not use a spend threshold as a precise latency or billing cutoff. Cost, turns, and time can all belong to one task policy while retaining their separate meanings.
For streaming input mode, the query object’s interrupt() is another documented control. Its receipt depends on the CLI’s advertised capability and version, so a deployment that uses it must follow the SDK’s documented receipt behavior. Prefer the control whose scope matches the application lifecycle; do not assume an interruption receipt means external business actions were undone.
Define the outcome when the clock expires
Cancellation does not itself supply a helpful product response. The completion policy should state whether verified partial findings can be displayed, whether the user receives a deferred-job identifier, or whether the workflow returns an incomplete outcome. Required checks remain required. A shorter deadline cannot silently turn an unreviewed result into an accepted recommendation.
For a tool whose action has already been dispatched, the application must establish its outcome before retrying or representing the task as canceled. The agent’s stop and the external operation’s completion are different observations. Keep this boundary visible in the task result, especially where the agent can initiate a business write.
Watch which bound terminated the run. Repeated maxTurns termination suggests a loop or insufficient round-trip allowance; repeated host deadline cancellation suggests the critical path does not fit. Increasing effort or turns is not an automatic remedy. Diagnose and measure a different configuration with 3.3.4.
Key distinctions and trade-offs
Thoroughness is optional only where the task permits it. An extra exploratory source might be optional; a mandatory review before a financial action is not. Reduce scope or defer the action when required work cannot fit, rather than redefining acceptance after the clock starts.
A completion percentile and a per-task deadline also differ. A target of p95 within ten seconds permits some slower observations; an application deadline determines the terminal behavior for an individual run. Test both successful completion latency and the proportion of tasks that expire, because aggressive cancellation can make the survivors look fast while users receive less useful work.
Architecture / decision scenario
An education helpdesk targets verified enrollment-policy answers within nine seconds at p95 and separately sets a ten-second per-task cancellation deadline. An illustrative stage budget reserves one second for admission, two for the required policy read, four for analysis, and one for final handling, leaving two seconds for optional investigation. The enrollment owner requires the policy read on every accepted answer.
The tempting design gives the agent eight turns at high effort and asks it to “finish quickly.” The platform architect rejects that as the timing mechanism: turn count does not bound tool duration. Instead, the host supplies task priorities to query(), reports remaining time after the policy read, and uses TypeScript abortController cancellation at the deadline, with maxTurns as a separate loop bound.
If admission and lookup consume five seconds, only five remain. A follow-up estimated at four seconds cannot fit alongside the required analysis and final handling, so the agent receives instructions to finish from the available policy or return an incomplete outcome. The helpdesk owner approves that user-facing fallback; the platform owner measures deadline expiries and accepted-answer coverage. Raising the deadline requires their explicit service decision, not an unrecorded change to the prompt.
Common exam traps
- Interpreting
maxTurnsormaxBudgetUsdas an elapsed-time setting. - Treating
task_budgetas an enforced wall-clock or spend cap. - Starting the task clock after queueing and retrieval have already consumed time.
- Asking for speed without naming optional work or the finishing reserve.
- Letting optional investigation crowd out a mandatory review.
- Reporting latency only for tasks that survived cancellation.
- Treating agent interruption as proof that a dispatched external action was rolled back.
What to remember
Give the agent priorities and measured remaining time, then enforce the task deadline in the host. Time, turns, and spend are different bounds. Reserve required completion work first and define the incomplete or deferred outcome before the deadline is reached.
Knowledge check
A helpdesk agent built on the TypeScript Agent SDK has a 10-second per-task deadline. Runs configured with maxTurns: 3 still exceed it, because one billing tool sometimes takes nine seconds to answer. Which control enforces the deadline?
maxTurns to 2 for every taskmaxBudgetUsd to the cost of a typical runabortController from the host at the deadlinetask_budget sized to a typical run’s tokensabortController is the documented control for cancelling the run. maxTurns bounds tool-use round trips, so one slow tool call still overruns; maxBudgetUsd bounds a client-side cost estimate that can pass its value; and task_budget is a soft token hint the model sees, not a cap on time.An enrollment agent has a 12-second task deadline. Admission and the required policy read have used 6 seconds. At measured p95, the required analysis takes 3 seconds and final handling 1 second; an optional cross-check of a second source, which would have to finish before the analysis starts, is estimated at 3 seconds. The enrollment owner accepts answers from the policy alone. What should the host tell the agent?
A host cancels an agent at its task deadline. An issue_credit tool call had already been sent to the billing service, and no response had arrived; the credit API takes no idempotency key. The customer immediately retries the request. What should the application do before acting on the retry?
References
- Anthropic, Define success criteria and build evaluations
- Anthropic, TypeScript SDK reference
- Anthropic, Effort
- Anthropic, Prompt caching
- Anthropic, Task budgets