Login
Why order submitted does not mean order filled
An AI agent can call the right tool and still be wrong about the outcome. The order lifecycle starts after submission.
A trading assistant says, “Done. I bought BTC.”
What it may actually mean is, “The server accepted my request.”
Those are not the same event.
An order can be submitted, rejected, left open, partially filled, filled at several prices or cancelled before anything trades. If an AI agent collapses all of those states into “success,” the conversation stops matching the account.
That is not a language problem. It is an order-state problem.
The short answer
Submitted means the order request reached the trading system. Filled means a matching trade actually occurred.
Between those two states, the venue may validate the request, reject it, accept it into the order book, fill part of it or leave it open.
The agent should report the state returned by the account or venue. It should not infer a fill from a successful tool call.
What happens before submission
Before an order reaches a venue, the trading system may check:
- Whether the account is authenticated
- Whether trading is enabled
- Whether the market is available to the account
- Whether the order is inside an account limit
- Whether the symbol, side, size and order type are valid
- Whether the account has enough available balance or margin
A request can fail at any of these checks.
If an account rejects an order above its limit, no order was submitted to the venue. The useful response is a rejection that names the failed rule.
Submitted
Submitted means the request has passed the initial path far enough to receive an order identifier or acknowledgement.
It does not prove that the order traded.
A limit order away from the current market may remain open. A market order may be rejected for insufficient balance. A venue may accept the request and only fill part of the requested size.
The order identifier is the beginning of the audit trail, not the outcome.
Open
An open order is resting and waiting for a match.
The account has accepted it, but the requested quantity has not fully traded. The order may remain open, fill later or be cancelled.
This matters for an agent because open orders still affect the account. A second instruction can duplicate exposure if the agent reads positions but forgets to read outstanding orders.
Before placing another order, the agent should check both.
Partially filled
A partially filled order has traded some, but not all, of the requested quantity.
The result should include the filled amount, the remaining amount and the average fill price so far.
Calling this state “done” creates several problems. The agent may assume the full position exists, place an offsetting order for too much or leave the unfilled remainder active without telling the user.
A partial fill is an ongoing state, not a footnote.
Filled
Filled means the full requested quantity has traded.
Even then, the final result may differ from the instruction in ways the user needs to see.
A market order can fill across several prices. Fees can change the final account balance. A futures position may use margin rather than the full notional value. The report should come from the execution record, not from the model’s estimate before submission.
A useful fill report names the instrument, side, total filled quantity, average fill price, fees and resulting position.
Rejected
Rejected means the order did not enter the market.
The rejection may come from the account control layer or the venue. Common reasons include an invalid market, an order above the account limit, insufficient funds, an invalid price or quantity, or disabled trading.
The agent should preserve the reason. It should not quietly reduce the order, switch instruments or claim that the request completed.
If the user asked for $700 and the account cap is $500, the correct result is not a smaller order. It is a rejection.
Cancelled
Cancelled means an open remainder has been removed before it filled.
A cancellation may happen because the user asked for it, the agent changed the plan or the venue expired the order. If part of the order filled first, cancellation applies only to what remained.
The final report therefore needs both facts: how much filled and how much was cancelled.
Tool success is not trading success
This distinction is easy to miss in an AI interface.
A tool call can succeed at the protocol level because the server returned a valid response. That response may contain a rejected order.
The model has to read the business result inside the response. The product also has to return that result clearly enough for the model to understand it.
A green check beside a tool call should not be interpreted as a filled trade unless the returned order state says so.
What an agent should report
After an order request, the agent should be able to answer:
- Which exact instrument was used?
- What side, size and order type were submitted?
- Was the request blocked before the venue?
- What order identifier came back?
- Is the order rejected, open, partially filled, filled or cancelled?
- How much filled and at what average price?
- Is any quantity still open?
- What changed in the account?
If the state can change after the first response, the system also needs a way to read the order again rather than treating the initial acknowledgement as final.
A simple test
Submit one small limit order away from the current market.
The expected result is not a fill. It should appear as open. Ask the agent to read it back, cancel it and confirm that the remaining quantity is no longer active.
Then submit a small order that can execute and verify the final fill against the account.
This test separates three capabilities that often get blurred together: submitting an order, reading its state and reporting the outcome accurately.
How this applies to agentic trading
Natural language makes the front of the workflow easier. It does not change the venue’s order lifecycle.
The agent can translate an instruction into a tool call. The account and venue still decide whether the request is allowed, accepted and filled.
At Fensory, the useful first step remains an account read. Check the balance, positions and open orders before requesting any action. After an order, ask for the returned state rather than accepting “done” as the answer.
Sources
Why order submitted does not mean order filled was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
