A Retry Should Not Erase the First Attempt

A factory can record one attempt while the software underneath it sends more than one request. We encountered that accounting boundary while working through local agent and team trials, alongside provider calls that could wait beyond the configured request timeout.

The useful lesson is about observability before it is about performance: a later answer cannot explain how much work happened or which failures preceded it.

What the trial exposed

The development record describes local model contention, prolonged waiting, and transport retries outside WTK's visible attempt accounting. The stalled trial was interrupted and remained in history. This was not a controlled comparison of provider performance.

An illustrative sequence makes the distinction clear. The factory requests one operation; the transport receives an error and retries; a later request succeeds. If only the outer operation is recorded, the apparent single success omits work and failure below it. This sequence illustrates the risk, not a reconstructed production trace.

The bounded correction

The integration changes disable automatic retries in the OpenAI-compatible SDK so that WTK's explicit retry policy owns retry decisions. The provider wrapper also applies the configured deadline and records expiry as a failed terminal request.

That does not mean all retries should be forbidden. It means the governing layer should be able to count and explain them. A deliberate new attempt should retain its relationship to the earlier failure.

What the tests actually check

Two regression tests rerun on September 5 make the boundary concrete:

Both tests passed in the local development checkout. The editorial packet retains the exact command, test transcript, and before/after hashes of selected source files. These were mocked checks, with no live model request. They verify the corrected path under these fixtures, not the original incident's complete transport history or a before/after performance improvement.

The checkout contained uncommitted integration work. Its commit identifier is not a release identity, and the selected-file hashes do not freeze every dependency of a runnable system. Changes to the adapter, retry policy, or deadline handling require retesting.

Why this extends the earlier log

A Release Claim Has to Remember the Misses described complete planned-attempt records. This follow-up identifies a lower layer that such records must account for. A Replay Cannot Rewrite the First Verdict concerns a different operation: reviewing retained outputs without replacing their original verdict.

We have not measured how much these changes alter cost, task completion, or apparent reliability. A caller-side timeout also does not prove that a remote service stopped computation or billing.

The next evidence package should reconcile outer operations, transport requests, explicit retries, and terminal events under controlled faults, retaining every attempt. That remains a proposed check, not an authorized run. Our research method requires that separation before an engineering repair becomes a reliability claim.