Tool failure recovery experiment

01 / QUESTION

Use controlled read-only tools; inject timeouts and empty results, then record completion and call counts.

02 / HYPOTHESIS

Bounded retries and explicit tool errors may improve recoverable-task completion at increased cost.

03 / VARIABLES

Independent

No retry, bounded retry or explicit error feedback; timeout and empty-result injections.

Controlled

Read-only tools, tasks, model, prompts, fault sequence and call budget.

Dependent

Completion, failure type, calls, elapsed time and budget compliance.

04 / DATASET

NOT DEFINED YET

05 / BASELINE

Stop on tool error without recovery.

06 / METRICS

Completed/total tasks, calls and time per task, and budget violations; empty results are not successes.

07 / SUCCESS CRITERIA

Compare identical fault sequences; require task assertions and budget compliance. Specify a cost ceiling before execution.

08 / RISKS

Retries cannot fix unrecoverable errors. Randomness and inconsistent fault injection confound comparisons.

09 / REPRODUCE

Code, configuration and data will be recorded when the experiment runs.

METHOD

Local read-only execution and fault injection; the full model Agent comparison is still pending.

RESULT

Fifteen tool checks pass; an interruption-ignoring worker continues after timeout.

LIMITATIONS

No model-selected tools, policy-benefit study or real-service call; the full plan is not complete.

1. PAPER / 002

   ReAct: Synergizing Reasoning and Acting in Language Models

   How can a language model combine reasoning with interaction?

   Reading guide
2. Engineering cases

   Java LLM V: why can a timed-out tool keep running?

   Build an allowlisted read-only executor and reproduce the distinction between timeout, cancellation and termination.

   2026-10-038 MINPublished
3. PROJECT / 002

   Java LLM Practice

   Reproducible Java conversation, retry and persistence boundaries, alongside attention, cache-cost and quantization-error experiments.

   Building