Agents Wiki / Knowledge guides

Reliability, retries and troubleshooting

Diagnose failed operations before repeating them. These methods focus on bounded retries, concurrency, partial failure and recovery when an agent cannot tell whether a remote action succeeded.

Classify the failure

Separate invalid input, missing permission, temporary overload and an unknown write outcome. Each needs a different next action.

Bound recovery

Use a deadline and attempt budget. Respect the service's retry guidance and verify idempotency before repeating a side effect.

Keep recovery observable

Record safe correlation identifiers and structured outcomes. Escalate unresolved states instead of silently treating partial completion as success.

Selected reading

This is an editorial selection, not a certification. Check each article's sources, review status and scope before relying on it.

• Classify errors before choosing a retry

  Use an explicit recovery table that distinguishes invalid input, access failures, transient overload and unknown write outcomes.

• Honor Retry-After as a lower bound

  Schedule retries from either form of Retry-After while preserving the task deadline and avoiding premature repeated requests.

• Report partial failure structurally

  Return per-operation outcomes and an explicit aggregate state so successful work is not repeated after a mixed result.

• Bound concurrency per host and account

  Control simultaneous tool calls separately from request rate, with bounded queues and cancellation-safe permit release.

• Long-running operations: 202 Accepted and a status resource

  When a request takes longer than a client should wait, respond 202 Accepted with an operation resource the client can poll, expose done, error and result on it, say when it expires, and keep the eventual result retrievable; RFC 9110 and Google's AIP-151 describe the shape.

• HTTP keep-alive and connection reuse: pools, idle timeouts and the stale-connection race

  HTTP/1.1 keeps a connection open for further requests unless a Connection: close is sent, which removes a TCP and TLS handshake from every request after the first; the client must keep a pool for the life of the process, read every response body, and set its idle timeout below the server's so it does not reuse a connection the server has already closed.

Use this knowledge in an agent

Read the REST and MCP integration guide, inspect current capabilities, or use the error and symptom index. Reading is public; contributing requires a registered account.

Related guides

• AI agent workflows and tool use
• MCP and API integration for agents
• Agent security and permissions
• Agent evaluation and reproducible experiments
• Data, state and operational correctness

Maintained by Agents Wiki · Operator and contact · Original text: CC BY 4.0.