An order acknowledgement is not a fill receipt

What an acknowledgement can establish

We label each stage of this trace by the evidence it supplies to the next agent action.

An autonomous agent can receive a successful order response without acquiring the requested asset. This matters when the next action depends on a balance, position, or completed trade. A tool response saying that a request was accepted must not silently become evidence of execution.

Bybit's order creation documentation states that its acknowledgement indicates acceptance and that the request is asynchronous. It directs clients to confirm order status through the WebSocket. This is a route-specific example of why an execution trace needs several kinds of evidence.

An illustrative trace with no fill

At time T0, an agent requests a purchase of five units at a limit of 100. At T1, the API acknowledges the request and returns an order identity. At T2, the order becomes open. At T3, it is canceled with zero confirmed executed quantity.

The trace contains a submitted instruction, an accepted request, an open order, and a completed cancellation. It contains no purchase. If an evaluator labels the T1 response as a five-unit fill, it invents both exposure and execution price. Any later profit estimate based on that invented position is invalid.

Now change the example so that two units execute before cancellation. The outcome is a partial purchase of two units and cancellation of the remaining three. The acknowledgement is identical in kind, but the economic receipt differs. All quantities and times here are illustrative.

Give each event a precise role

Record submission evidence with the request payload and intent identity. Record acknowledgement with the venue response and order identity. Track lifecycle evidence through the venue's status stream or supported queries. Store executions as separate ledger events. Finally, reconcile order totals, balances, and any unresolved gaps.

A user-facing tool result can state the last confirmed stage in simple language: accepted, awaiting execution; partially filled, remainder open; or canceled after partial execution. That wording follows evidence available at the moment. It does not require the model to infer the venue outcome from an optimistic response string.

Latency also needs a named interval. Request-to-acknowledgement latency measures transport and acceptance. Request-to-first-fill latency includes matching delay. Request-to-terminal-reconciliation latency measures a broader operational completion path. Comparing these intervals as one number hides the actual system behavior.

A fixture that catches invented positions

Provide an accepted response followed by an open event and a zero-fill cancellation. Assert that acquired quantity remains zero. Then provide a partial-fill variant and verify that only confirmed execution quantity enters the position ledger. A missing terminal event should leave completion unresolved.

The meaning of statuses varies by venue. A terminal state can indicate cancellation, rejection, expiration, or full execution; some APIs encode these through additional fields. Spot and derivative positions also have different reconciliation needs. Map those semantics explicitly rather than treating every terminal event as a trade.

For agentic trading research, this distinction protects the evidence chain from reasoning through execution. It tests whether the system reports what happened, rather than whether the model can produce a convincing description of what it hoped would happen.

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.