An AI agent can call the right tool and still be wrong about the outcome. The order lifecycle starts after submission.<\/p>\n
A trading assistant says, \u201cDone. I bought\u00a0BTC.\u201d<\/p>\n
What it may actually mean is, \u201cThe server accepted my request.\u201d<\/p>\n
Those are not the same\u00a0event.<\/p>\n
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 \u201csuccess,\u201d the conversation stops matching the\u00a0account.<\/p>\n
That is not a language problem. It is an order-state problem.<\/p>\n
Submitted means the order request reached the trading system. Filled means a matching trade actually occurred.<\/strong><\/p>\n 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\u00a0open.<\/p>\n The agent should report the state returned by the account or venue. It should not infer a fill from a successful tool\u00a0call.<\/p>\n Before an order reaches a venue, the trading system may\u00a0check:<\/p>\n Whether the account is authenticatedWhether trading is\u00a0enabledWhether the market is available to the\u00a0accountWhether the order is inside an account\u00a0limitWhether the symbol, side, size and order type are\u00a0validWhether the account has enough available balance or\u00a0margin<\/p>\n A request can fail at any of these\u00a0checks.<\/p>\n 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\u00a0rule.<\/p>\n Submitted means the request has passed the initial path far enough to receive an order identifier or acknowledgement.<\/p>\n It does not prove that the order\u00a0traded.<\/p>\n 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.<\/p>\n The order identifier is the beginning of the audit trail, not the\u00a0outcome.<\/p>\n An open order is resting and waiting for a\u00a0match.<\/p>\n The account has accepted it, but the requested quantity has not fully traded. The order may remain open, fill later or be cancelled.<\/p>\n 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.<\/p>\n Before placing another order, the agent should check\u00a0both.<\/p>\n A partially filled order has traded some, but not all, of the requested quantity.<\/p>\n The result should include the filled amount, the remaining amount and the average fill price so\u00a0far.<\/p>\n Calling this state \u201cdone\u201d 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\u00a0user.<\/p>\n A partial fill is an ongoing state, not a footnote.<\/p>\n Filled means the full requested quantity has\u00a0traded.<\/p>\n Even then, the final result may differ from the instruction in ways the user needs to\u00a0see.<\/p>\n 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\u2019s estimate before submission.<\/p>\n A useful fill report names the instrument, side, total filled quantity, average fill price, fees and resulting position.<\/p>\n Rejected means the order did not enter the\u00a0market.<\/p>\n 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\u00a0trading.<\/p>\n The agent should preserve the reason. It should not quietly reduce the order, switch instruments or claim that the request completed.<\/p>\n If the user asked for $700 and the account cap is $500, the correct result is not a smaller order. It is a rejection.<\/p>\n Cancelled means an open remainder has been removed before it\u00a0filled.<\/p>\n 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.<\/p>\n The final report therefore needs both facts: how much filled and how much was cancelled.<\/p>\n This distinction is easy to miss in an AI interface.<\/p>\n A tool call can succeed at the protocol level because the server returned a valid response. That response may contain a rejected\u00a0order.<\/p>\n 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.<\/p>\n A green check beside a tool call should not be interpreted as a filled trade unless the returned order state says\u00a0so.<\/p>\n After an order request, the agent should be able to\u00a0answer:<\/p>\n Which exact instrument was\u00a0used?What side, size and order type were submitted?Was the request blocked before the\u00a0venue?What order identifier came\u00a0back?Is the order rejected, open, partially filled, filled or cancelled?How much filled and at what average\u00a0price?Is any quantity still\u00a0open?What changed in the\u00a0account?<\/p>\n 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\u00a0final.<\/p>\n Submit one small limit order away from the current\u00a0market.<\/p>\n 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\u00a0active.<\/p>\n Then submit a small order that can execute and verify the final fill against the\u00a0account.<\/p>\n This test separates three capabilities that often get blurred together: submitting an order, reading its state and reporting the outcome accurately.<\/p>\n Natural language makes the front of the workflow easier. It does not change the venue\u2019s order lifecycle.<\/p>\n The agent can translate an instruction into a tool call. The account and venue still decide whether the request is allowed, accepted and\u00a0filled.<\/p>\n 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 \u201cdone\u201d as the\u00a0answer.<\/p>\n Explore Fensory<\/a><\/p>\n Coinbase Advanced Trade API: order management<\/a>Hyperliquid API documentation<\/a>Fensory MCP<\/a><\/p>\n Why order submitted does not mean order filled<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":" 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, \u201cDone. I bought\u00a0BTC.\u201d What it may actually mean is, \u201cThe server accepted my request.\u201d Those are not the same\u00a0event. An order can be submitted, rejected, left open, partially filled, filled […]<\/p>\n","protected":false},"author":0,"featured_media":241065,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-241064","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/241064"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=241064"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/241064\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/241065"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=241064"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=241064"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=241064"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}What happens before submission<\/h3>\n
Submitted<\/h3>\n
Open<\/h3>\n
Partially filled<\/h3>\n
Filled<\/h3>\n
Rejected<\/h3>\n
Cancelled<\/h3>\n
Tool success is not trading\u00a0success<\/h3>\n
What an agent should\u00a0report<\/h3>\n
A simple\u00a0test<\/h3>\n
How this applies to agentic\u00a0trading<\/h3>\n
Sources<\/h3>\n