Order retries after a timeout: preserve one economic intent

A timeout does not identify the exchange outcome

We treat transport recovery as an execution problem with its own evidence, separate from a fresh model decision.

When an order submission times out, an autonomous agent knows the client did not receive a usable response. Whether the venue created the order remains unresolved. Retrying with a fresh identity can turn one intended action into two economic orders.

Bybit's order creation documentation provides an example of a client-supplied order identifier and requires uniqueness. That field can support correlation. Repeated-request guarantees require additional documented semantics; the adapter needs the documented behavior for its exact route.

An illustrative lost response

An agent has an authorized instruction to buy three units. The runtime persists intent I-42, creates client order identifier C-42, and sends the request. The venue accepts an order, but the response is lost.

A worker restart sees the pending intent. If it generates C-43 and submits the same three-unit buy, both orders may exist. The resulting six-unit exposure arises independently of a new model decision. It is a recovery error.

An evidence-aware recovery instead searches for C-42 through supported order queries and reconciles any executions. If the original order exists, it resumes tracking that order. If evidence establishes rejection or noncreation under documented semantics, the same economic intent can move through the adapter's supported retry path. If the outcome remains unknown, that uncertainty remains explicit.

Separate identifiers with different jobs

Use an intent identity for the economic action, an order identity for each venue order, and an attempt identity for each transport attempt. Persist the intended instrument, side, size, price constraint, and authorization version before sending. That record allows recovery to determine whether a later request is the same action or a deliberate revision.

A changed price or quantity may alter the economic intent. It may be a new child order or amendment requiring another policy check. Conversely, an agent evaluation dataset should identify repeated network attempts as attempts under the original decision.

Coordinate workers around the durable intent record. An in-memory flag can disappear during a crash. A durable claim or transaction can make concurrent recovery observable, while the venue's guarantees remain a separate dependency. The external outcome must still be reconciled.

An offline recovery fixture

Construct cases where the response is lost after acceptance, the request never reaches the venue, a duplicate request receives an error, and the query temporarily returns incomplete evidence. Include a restart between persistence and submission. Assert that no new economic intent appears merely because transport failed.

The expected outcome in an unresolved case may be a pending reconciliation record. That is a valid test result describing the remaining recovery dependency. A runtime that invents certainty can produce incorrect exposure while appearing operationally responsive.

Query retention, client identifier lookup, duplicate handling, and route-specific guarantees vary across venues. Some endpoints provide stronger idempotency semantics than others. Record those differences in the adapter contract before assuming a generic retry wrapper is sufficient.

This procedure contributes a boundary between autonomous reasoning and execution recovery. Current DXAP retry implementation and reliability measurements require source and runtime evidence of their own.

Fit the receipt into the full trace

Our execution and settlement framework connects these mechanics to recorded outcomes. The operating-layer controls paper explains why the machinery around an agent deserves its own evaluation.