What is an embedded conversational trading agent?

Traders already ask questions all day. They ask what moved the market, what a funding rate means, how much margin a position needs, or what happens if they close half of it. Today most of those questions leave the exchange: they go to a search engine, a social feed, or a general-purpose AI chat that has no view of the trader’s account or the venue’s live order book.
An embedded conversational trading agent brings that conversation back inside the exchange. This guide covers what one is, how it works, what separates it from the tools it gets confused with, and what an exchange or broker should check before embedding one.
A plain-English definition
An embedded conversational trading agent is a chat interface, built into an exchange’s or broker’s own app, that can do three things:
- Answer market and trading questions using live data from that venue.
- Explain concepts, positions and order mechanics in plain language.
- Draft orders from a natural-language instruction, then wait for the trader to confirm.
“Embedded” is the important word. The agent runs inside the exchange’s product, under the exchange’s account system, connected to the exchange’s market data and order API. The trader never leaves the venue, and the trade never leaves it either.
How it works, step by step
A typical exchange might run the flow like this:
- The trader asks. “Why is ETH down today?” or “Sell half my SOL at market.”
- The agent gathers context. It pulls live prices, recent moves, the trader’s balances and open positions through the exchange’s APIs.
- It answers with evidence. A research answer arrives as a card: the facts, the key numbers, the sources, and a timestamp showing when the data was taken.
- It drafts, it does not execute. For an instruction, the agent fills in an order ticket: market, side, type, quantity, estimated fill and fees. “Half my SOL” resolves to an exact quantity, echoed back so the trader can check it.
- The trader confirms. Only when the trader presses Confirm is the order submitted to the exchange through its order API.
The confirmation step is not a nice-to-have. It is what keeps the trader in control and keeps the agent on the information side of the line. We cover that in depth in how an AI trading agent avoids giving investment advice.
What it is not
Three categories get confused with embedded trading agents. The differences matter when you evaluate vendors.
| Embedded trading agent | Support chatbot | General-purpose AI chat | Consumer trading copilot | |
|---|---|---|---|---|
| Lives inside the exchange app | Yes | Yes | No | No |
| Sees live venue data and the trader’s account | Yes | Rarely | No | Through a connection, sometimes |
| Drafts orders | Yes, for trader confirmation | No | No | Some do, sometimes off-venue |
| Who owns the trader relationship | The exchange | The exchange | The AI provider | The copilot |
| Main job | Research and order drafting | Tickets and account issues | General questions | Trading, often across venues |
A support chatbot is the closest neighbour, and the easiest to mistake for an agent. Traders do not raise support tickets to learn what open interest is. They search for it, or ask a general AI. That is why a trading agent is a different product from a support assistant, even when both appear as a chat bubble.
Consumer copilots validate the demand, but they sit outside the exchange and compete with it for the trader’s attention. Some route trades elsewhere. An embedded agent is structurally on the exchange’s side: it exists to make trading on that venue easier.
The building blocks
Most embedded agents share the same parts, whatever the vendor.
- A client surface. Usually a docked chat panel delivered through an SDK. In a thin-client design the panel is the only thing added to the app; it does not modify the exchange’s charts, forms or navigation.
- Server-driven cards. Answers and order tickets render as structured cards defined on the server. New card types can ship without an app release.
- A reasoning model. A language model that interprets the question, decides which data it needs, and writes the answer. Larger models handle multi-step research; smaller, faster models handle routing and simple lookups.
- Data and execution connectors. Read access to market data and account state; a write path to the order API that only fires after confirmation.
- Guardrails. Tested behaviour that stops the agent from giving advice, predicting prices or acting without consent.
Why exchanges and brokers are adding one
The argument is about where the trader’s attention goes. Every question a trader takes elsewhere is a moment when the exchange is not part of the decision. An embedded agent keeps the research and the action in one place, on the exchange’s own surface.
For product and growth teams, the questions worth tracking are concrete:
- Do new traders reach their first trade faster when they can ask how things work? See exchange growth for how to measure activation.
- Do traders try more of the product, such as limit orders, alerts or derivatives, once someone explains them in context?
- How many questions currently go to search engines or third-party AI, and what does that cost the venue in engagement?
These are measurable in a controlled pilot. The answer depends on the venue, which is why a pilot with clear metrics beats a slide-deck promise.
What to check before you embed one
A short checklist for exchange and broker teams evaluating vendors:
- Confirmation is mandatory. Can the agent ever submit an order without an explicit trader confirmation? The right answer is no, with no setting to turn it off.
- The advice boundary is tested. Ask how the vendor tests that the agent does not give advice, and at what scale. Ask for the pass rate and how failures are handled.
- Your surfaces stay yours. Does integration require changes to your native screens, or does the agent arrive as a self-contained panel?
- Integration time. Weeks or quarters? What does the vendor need from your API?
- Data provenance. Do answers show their sources and the time the data was taken?
- Who owns the relationship. Is the agent loyal to your venue, or does it route traders elsewhere?
For a direct comparison with publishing an API endpoint for external AI tools, read MCP endpoint vs embedded agent.
Where Hippo fits
Hippo is an embedded conversational trading agent built for exchanges and brokers. It arrives as a docked chat panel with server-driven cards, so it integrates without touching the Host’s native screens. Traders share an idea, get the evidence, and confirm a trade on Hippo’s own order ticket; Hippo then submits it through the exchange’s API. Hippo explains. It never advises.
If you run product or growth at an exchange or broker, askthehippo.com has more on how a pilot works.
Frequently asked questions
Is a conversational trading agent the same as a support chatbot?
No. A support chatbot resolves account and ticketing issues. A conversational trading agent answers market and trading questions with live data and drafts orders for the trader to confirm. It sits next to the trading workflow, not the help desk.
Does an embedded trading agent place trades on its own?
A well-designed one does not. It drafts the order, shows the exact effect, and waits. The trader confirms, and only then is the order submitted to the exchange through its API.
Does the exchange have to rebuild its app to embed one?
Not with a thin-client design. The agent arrives as a docked chat panel delivered by an SDK, so the exchange's existing charts, order forms and screens stay as they are.
Does a conversational trading agent give investment advice?
It should not. The agent explains what the data shows and what an order would do. It does not tell traders what to buy, sell or hold, and it does not predict prices.
Hippo provides information, not investment advice.