Thin-client SDK vs deep integration for trading agents

There are two main ways to embed an AI trading agent. A thin-client SDK adds it as a docked chat panel with server-driven cards and leaves the exchange’s native screens untouched. Deep integration wires the agent into existing charts, order forms and navigation. Thin-client is faster to ship and easier to update; deep integration offers tighter placement at the cost of more engineering and slower change.

This guide explains both patterns, compares them, and lists what the exchange’s engineers provide in each case.

The thin-client pattern

In a thin-client design, the agent arrives as one new element in the app: a docked chat panel. A small SDK adds the panel and handles the session. Everything else lives on the server.

• The panel is self-contained. It opens beside the trading screen. It does not modify charts, order forms or navigation.
• Cards are server-driven. A research answer, a comparison or an order ticket arrives as a structured card. The client knows how to draw card types; the server decides content and layout.
• Most changes ship server-side. New card types, wording fixes and guardrail updates do not need an app-store release.

The panel is the only new surface. The exchange’s existing screens keep working exactly as before.

The deep-integration pattern

In deep integration, the agent’s output appears inside native screens. An “explain this” button might sit on the chart. The agent might pre-fill the exchange’s own order form. Answers might render in native components.

• Placement is tighter. The agent can appear exactly where a trader is looking.
• Each touchpoint is custom work. Every screen the agent touches needs design, engineering and QA from the exchange.
• Changes travel with app releases. Updating behaviour in a native screen usually means a client release on every platform.

Trade-offs side by side

	Thin-client SDK, docked panel	Deep integration into native screens
Changes to native screens	None	Many; each touchpoint is modified
Time to first launch	Shorter; integration work is mainly APIs and auth	Longer; per-screen design and build
Shipping updates	Mostly server-side, via cards	Often tied to app releases
Placement	Beside the trading workflow	Inside the trading workflow
Engineering load on the exchange	Lower, concentrated at the start	Higher, ongoing
Regression risk to core screens	Low; core screens are untouched	Higher; core screens change
Consistency across web and mobile	Same cards render everywhere	Each platform built separately
Where confirmation happens	On the agent’s own ticket in the panel	Often in the native order form

The last row matters more than it looks. When the agent pre-fills a native order form, there are two places a detail can drift: the agent’s reading of the instruction, and the form’s handling of it. With the ticket inside the panel, the trader confirms the exact order the agent drafted. See why confirm-by-default matters.

What the exchange’s engineers provide

Whichever pattern you choose, the agent needs access to your venue. The usual list:

1. Market data APIs. Prices, order books, recent trades, funding and open interest, with timestamps.
2. Account and position APIs. Balances, open positions and open orders for the logged-in trader, read-only.
3. An order API. A write path for submitting orders, used only after the trader confirms. Error and rejection responses need to be clear.
4. Authentication. A way to tie the agent’s session to the trader already logged in, so the agent sees only that trader’s data. Common approaches include short-lived tokens issued by your backend; the exact method depends on the vendor.
5. Product metadata. Symbols, contract specifications, tick and lot sizes, and fee schedules, so drafted orders are valid.
6. A place in the app. For thin-client, a mount point for the panel. For deep integration, the screens and components involved.

Thin-client integration is mostly items 1 to 5 plus a mount point. Deep integration adds item 6 at much larger scale, plus ongoing work as native screens evolve.

Questions that point to one or the other

• Can your native screens change in the next quarter, or are they frozen?
• Do you need the agent on web and mobile at the same time?
• How often do you expect the agent’s behaviour to change after launch?
• Who will maintain each touchpoint inside native screens?
• Is the agent a core product bet, or a capability next to the core?

If the screens are frozen, both platforms matter, and change will be frequent, the thin-client pattern usually fits. If the agent is the product’s centre and engineering capacity is available, deep integration becomes a real option. Weigh this alongside the wider build vs buy decision.

How Hippo embeds

Hippo uses the thin-client pattern. It arrives as a docked chat panel delivered by a thin-client SDK, with server-driven cards, and integrates without touching the Host’s native screens. Traders confirm on Hippo’s own order ticket inside the chat; Hippo then submits through the exchange’s API. Integration is measured in weeks, not quarters.

Related

For definitions, read what an embedded conversational trading agent is. For an alternative to embedding at all, see MCP endpoint vs embedded agent. Integration questions to ask any vendor are in the vendor checklist. More at askthehippo.com.