Retries, limits and cancellation

The mechanism

Agent execution has several nested budgets: one provider response, one loop invocation, individual tool calls and the surrounding request. A limit at one level does not automatically constrain the others. A response-token cap does not limit the number of tool calls; an HTTP timeout does not undo a completed write; model retry behavior does not make a business operation idempotent.

The current SDK accepts invocation limits for turns, output tokens and total tokens. The official lifecycle guide states that checks occur at loop boundaries. A model turn can overshoot a token budget, and previously requested tools complete before the next check. Treat these limits as loop controls, not precise billing enforcement.

A worked policy

Optional inference. This fragment uses documented Python 1.58 interfaces. model and lookup_incident come from chapters 3 and 5.

from strands import Agent, ModelRetryStrategy

agent = Agent(
    model=model,
    tools=[lookup_incident],
    callback_handler=None,
    retry_strategy=ModelRetryStrategy(
        max_attempts=3, initial_delay=1, max_delay=4
    ),
)
result = agent(
    "Explain INC-104 from the lookup result.",
    limits={"turns": 4, "output_tokens": 1200, "total_tokens": 6000},
)
print(result.stop_reason)

max_attempts counts the initial attempt. The built-in retry strategy targets model throttling by default; it does not promise to retry every network or application error. Keep retryable categories explicit, and account for time spent backing off within your request deadline.

Cancellation is also cooperative behavior with a scope. The current lifecycle API includes agent.cancel(), but an already completed external action remains completed. Your tool implementations still need timeouts and reconciliation. A user-facing “cancelled” status should explain whether any approved effects occurred before cancellation.

Practice: compute a worst-case envelope

Offline. Suppose a request allows three model attempts, two backoff waits and a tool that can take five seconds. Write the maximum planned time for one call before adding queueing and network uncertainty. Then multiply by the maximum number of loop turns only where those operations can actually repeat. Label assumptions rather than presenting the result as a measured latency.

Expected observation: independent defaults can combine into a request much longer than the frontend timeout. Choose an outer deadline first, then allocate smaller budgets to model and tool operations. Add a “budget exhausted” output that preserves partial evidence instead of claiming success.

Create fixtures for normal completion, a turn limit, a token limit, cancellation, content filtering and an unexpected exception. Your handler should distinguish them. Increasing a budget may be appropriate for a legitimate long task; retrying a safety intervention blindly is not.

Troubleshooting and trade-offs

Repeated throttling can indicate excessive concurrency or insufficient quota. Adding retries may worsen both latency and load. Use bounded admission control and monitor retry rates. A limit that consistently stops useful work too early should be adjusted using evidence from representative tasks, not removed globally.

Do not infer a cost guarantee from token counters alone. Provider prices, cached-token billing, auxiliary model calls and external tool costs may differ. Record the actual billed categories available from your provider and use account-level controls for financial governance.

Interview practice

Completion check

Explain your outer deadline, retry count, turn budget and tool timeout as one coherent policy. Show how your handler reports a partial result and how it reconciles an uncertain write.

Sources and version notes

Checked 6 October 2026. Python examples target strands-agents==1.58.0 unless labelled otherwise. Live documentation can change; compare your installed version before adapting an example.

• Invocation limits and cancellation
• Model retry strategies