Reduce-only orders and the agent position they reference

Closing intent needs an execution constraint

Our example follows a changing position to show why closing intent needs a serialized execution constraint.

An autonomous agent can intend to close a position while submitting an order that is capable of opening one. The difference becomes visible when another order changes the position before the closing instruction executes. Reduce-only semantics are one venue mechanism for expressing a narrower economic effect.

Bybit's order documentation describes its reduce-only flag as restricting an order to reducing position size. It also distinguishes position modes and limits the flag to particular product categories. Those details make it inappropriate to treat the same field as a universal spot or derivative behavior.

An illustrative position change

Suppose an agent observes a long position of five units and sends a sell order for five to close it. Before that order executes, a different closing order sells three units. The remaining long position is two.

An unrestricted five-unit sale could, in a simple one-way position model, close the remaining two and create a short of three. A closing intent has become an opening exposure. A venue-enforced reduce-only constraint is intended to prevent that position increase under its documented rules. The exact treatment of excess quantity, rejection, resizing, or cancellation still belongs to the venue contract.

These quantities are illustrative. Platform implementation and fill outcomes require their own receipts.

Bind the order to the right position

The runtime needs the instrument, account, side, position mode, and applicable position identifier. A hedge-mode account can hold separate directional positions, so a generic sell instruction may not identify the intended position without an additional field. An account-level net quantity loses distinctions when the venue treats those positions separately.

Capture the observed position version in the intent record. Immediately before submission, validate the current position and the order's intended economic effect. Preserve the reduce-only flag in the serialized request rather than leaving it only in the agent's explanation.

If the observed position is already zero, the system should represent that fact explicitly in its decision trace. Creating a normal sell order because the original natural-language request said close would contradict the current state. When the current state is unresolved, record the uncertainty instead of inventing a position quantity.

Test the constraint and its limits

A useful offline fixture starts with five long units, applies a concurrent three-unit close, and then evaluates the remaining close request. Additional cases include zero position, wrong side, wrong position identifier, and partial execution followed by another position update.

The expected result must follow the specific adapter contract. A simulation that clips quantity tests internal arithmetic; the live venue behavior requires separate verification. Actual order and execution receipts are needed to verify external behavior.

Reduce-only is also separate from a price guarantee. An order can fail to execute, execute partially, or remain open, subject to its type and constraints. Fees and margin effects remain separate accounting concerns.

This note gives agent evaluators a narrow question: did a closing instruction preserve its intended exposure boundary as the position changed? Current DXAP support and investment performance require separate evidence.

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.