Why confirm-by-default matters for AI order flow

The moment an AI agent can turn “sell half my ETH” into an order, a design question appears: who presses the button? The answer we hold to is simple. The agent drafts. The trader confirms. Nothing executes until they do.

This post explains why confirmation should be mandatory rather than a preference, and what a good confirmation step looks like.

Three reasons confirmation is mandatory

1. It keeps the decision with the trader. An agent that executes on its own interpretation has made a trading decision. Even when it was asked, the gap between what a person said and what they meant is where losses happen. Confirmation makes the trader the one who acts, every time. This is also why confirmation sits inside the advice boundary rather than next to it; see how an AI trading agent avoids giving investment advice.

2. It catches the misread before it costs money. Natural language is ambiguous. “Close half” of which position? “Buy 5” — five units, or five dollars’ worth? Market or limit? A confirmation step that echoes the resolved instruction turns ambiguity into a visible, checkable ticket.

3. It protects the exchange. An exchange that embeds an agent is responsible for what happens on its venue. A clean record that every AI-drafted order was explicitly confirmed by the account holder is far easier to stand behind than “the model decided”.

Why it should not be a setting

It is tempting to offer an “auto-execute” toggle for power users. We think that is a mistake for three reasons:

• The failure modes do not depend on experience. Experts mistype and misspeak too.
• A setting becomes a support and compliance question: who enabled it, when, and did they understand it?
• Once confirmation is optional, the claim that “the trader always decides” is no longer true across the product.

One tap is a small price. Confirmation should be designed to be fast, not to be skippable.

What a good confirmation step shows

A confirmation step is only as good as the information on it. Every AI-drafted ticket should show:

Field	Why it matters
Market and symbol	Spot or perpetual, and exactly which pair
Side	Buy or sell, long or short, stated in words
Order type	Market, limit or stop, with the price where relevant
Quantity, echoed	The resolved amount in the trader’s own terms: “Sell 0.5 ETH (50% of your 1.0 ETH)”
Estimated fill	What the trader can expect to pay or receive
Fees	Estimated trading fees, included in the total
Margin and estimated liquidation	For leveraged orders, always shown and labelled as estimates

And one line, every time: nothing executes until you confirm.

Where confirmation happens

Where the confirmation lives matters as much as whether it exists. A flow that hands the trader to a separate order modal, or to another app, adds a step and a chance for the details to drift. On Hippo, the trader confirms on Hippo’s own order ticket inside the chat, and Hippo then submits the order through the exchange’s API. The trader sees one ticket, with every field, in the place they gave the instruction.

How confirmation differs from consumer AI trading tools

Many tools now offer some form of approval. The useful questions for an exchange evaluating them are:

1. Is confirmation mandatory for every order, or can it be disabled?
2. Does it happen on the exchange’s own surface, or in a third-party app?
3. Does the ticket echo the resolved quantity in the trader’s own terms?
4. Are leverage, margin and estimated liquidation shown before confirmation?
5. Is there an audit record of each confirmation?

For the wider comparison between embedding an agent and exposing an API for external AI tools, see MCP endpoint vs embedded agent. For how order types themselves work, read market, limit, stop and stop-limit orders explained.