Agent harness method · October 8, 2026

A Tool Timeout Is an Unknown Outcome

If an agent loses a tool response, the action may have failed, may still be running, or may already have completed. Automatically saying “done” or repeating the action can both be wrong.

This is a practical design method for agent harnesses, connected to my tool-use work. It is not a benchmark result or a claim that every public application implements the method.

Separate the request from its outcome

Use explicit states: not started, pending, confirmed complete, confirmed failed, and outcome unknown. A timeout in the client establishes that the client stopped waiting. It does not by itself establish what happened in the external system.

Inspect before repeating an action

Suppose a publication request times out. Before posting again, look for the created item or query the existing operation identifier. If the item is present and matches the intended content, report the confirmed publication. If the service confirms rejection, record the failure. If neither is known, retain the unknown state and tell the user what remains unresolved.

Where a service supports idempotency keys, use its documented mechanism to associate retries with the original request. Do not assume every tool supports that feature. Repeating a read can be acceptable; repeating a message, deletion or other consequential action requires knowing the applicable retry and authorization rules.

Test ambiguous outcomes deliberately

Simulate rejection before execution: expect a failure report with no claimed completion.
Simulate execution followed by a lost response: expect state inspection rather than an immediate duplicate action.
Simulate a task still running: expect a pending report and continuation of the same operation.
Simulate an unreadable final state: expect an explicit unknown outcome, not an invented result.

These are proposed test cases. Record the actual request, operation identifier, observed external state and agent report when running them. Keep sensitive payloads out of public logs.

Make the report useful

Tell the user what was attempted, what is confirmed, what is unresolved and the next concrete step. Preserve the original operation identifier so later work can reconcile the outcome without guessing.

Human First AI means giving people an accurate account of what the system did and keeping consequential actions under their control. I am carrying this approach into ongoing systems work behind the scenes; this note shares a method without claiming private results.