Most "AI on top of exchanges" demos are the same movie: an LLM reads a tweet, places a market order, and the author's paper wallet dies of inspiration.
That is not a product. That is a liability with an API key.
The use case that actually holds up for desks, brokers, and exchange-adjacent fintechs is quieter: an AI ops layer on exchanges — agents that understand desk intent, call exchange tools through a typed contract, and never lose mid-flight state when a worker dies at 03:14 UTC. The stack that makes that real in 2026 is the Vercel AI SDK for the agent loop, Temporal for durable execution, and MCP for the tool boundary.
We've been designing this pattern for teams that already have exchange connectivity and need intelligence on top — not another black-box trading bot. For the measured desk outcomes, read the Exchange AI Ops case study. The same spine applies to banking ops with maker-checker instead of desk dual control. Below is the architecture we'd actually ship.
The use case that wins: desk ops, not autonomous gambling
Pick one of these. They share the same architecture; only the tools change.
| Use case | Buyer | Agent job | Why durability matters |
|---|---|---|---|
| Order-intent desk copilots | Prop desks, OTC brokers | Translate natural language → validated order tickets → HITL approve → place/amend/cancel | Mid-approval crash must not double-submit |
| Post-trade exception handling | Exchange ops, prime brokers | Triage failed fills, reconcile positions, open tickets | Long-running investigations across systems |
| Treasury / inventory sweeps | Market makers, payment rails | Propose rebalances across venues; execute with dual control | Multi-step, multi-venue, rate-limited APIs |
| Surveillance explainers | Compliance | Summarize anomalous order patterns with tool-backed evidence | Auditable replay of every tool call |
We'd start with order-intent desk copilots for most exchange overlays. The ROI story is clear: senior traders waste hours on ticket formatting, venue-specific quirks, and status chase. The agent owns the busywork; humans own the risk.
If your instinct is "fully autonomous alpha," stop. Build the ops layer first. You will need every durability and audit primitive anyway — and agentic enterprise deployments that skip HITL pay for it twice.
Architecture: three agents, one durable spine
Steal the pattern Temporal's own ambient-agent writing popularized for crypto stacks, then harden it for institutional ops:
- Broker agent — user-facing. Parses intent ("reduce BTC inventory 15% across Binance + OKX, TWAP over 40 minutes"), starts workflows, answers status queries.
- Execution agent — owns venue interaction. Never invents tools — only calls MCP tools backed by Temporal Activities/Workflows.
- Judge agent — LLM-as-judge on a schedule. Reviews execution quality (slippage vs. plan, reject rates, policy violations) and proposes prompt / policy updates — never silent rewrite of risk limits.
Cross-cutting workflows:
- Market / account data fan-in
- Order placement + amend/cancel
- Execution ledger (fills, fees, positions)
- Approval gates (signal when a human signs off)
Operator (Slack / web UI)
│
▼
┌───────────────────┐
│ Broker Workflow │ ← Vercel AI SDK generateText / streamText
└─────────┬─────────┘
│ starts / signals
▼
┌───────────────────┐ MCP tools ┌─────────────────────┐
│ Execution Workflow│ ─────────────────► │ Temporal Activities │
└─────────┬─────────┘ (place, cancel, │ getBalance, placeOrder│
│ getPositions) │ reconcileFill, ... │
│ └─────────────────────┘
│ signals
▼
┌───────────────────┐
│ Judge Workflow │ (schedule + on-demand)
└───────────────────┘
This is the same mental model we use in Xenith Agents deployments: orchestrator + specialists + evaluators, with irreversible tools behind policy gates.
Why this three-technology sandwich
Vercel AI SDK — the agent loop you already know
Use generateText / streamText with tool() definitions and Zod schemas. The TypeScript ergonomics matter: desks want typed tickets, not free-form JSON the model "kinda" produced.
With Temporal's AI SDK integration, you keep AI SDK code shape while LLM calls become durable Activities under the hood. Rate-limit 429s become retries instead of lost turns. Worker restarts don't wipe the in-progress tool loop.
Opinionated rule: the model proposes; Temporal decides what is persisted; MCP decides what can touch money.
Temporal — the spine exchanges forgot to ask for
Exchange APIs fail. Workers OOM. Deployments roll. A naive Node process that was "waiting for fill" dies and your book lies.
Temporal gives you:
- Durable agent turns — resume from last completed Activity
- Signals / Queries — "approve ticket #4812", "what's position vs. plan?"
- Schedules — judge every N minutes; sweep idle inventory nightly
- Replay — compliance can reconstruct what the agent saw and did
If a step can move capital or change a book, it is a Temporal Activity with timeouts, retries, and heartbeats — not a fire-and-forget fetch.
MCP — the tool contract that keeps models honest
MCP (Model Context Protocol) turns exchange capabilities into a discoverable, schema'd tool surface:
| MCP tool | Backed by | Notes |
|---|---|---|
get_balances | Activity | Read-only; cache aggressively |
get_open_orders | Activity | Venue-normalized schema |
place_order | Workflow | Idempotency key required |
cancel_order | Activity | Dual-control optional above size |
subscribe_market | Long-running Workflow | Stream → signal execution agent |
get_execution_report | Query | Desk UI polling without re-prompting the LLM |
request_approval | Signal wait | HITL; no place until approved |
Critical design choice: implement write tools as Temporal Workflows/Activities behind the MCP facade, not as raw REST calls inside the LLM context. MCP alone is not durable. MCP + Temporal is.
That is the difference between a demo and a system that still reconciles after a regional blip.
Platform MCP: let the next product plug into the desk layer
Southbound MCP is the Execution agent talking to venues. Northbound / platform MCP is the desk layer exposing those capabilities to another product — risk UI, treasury app, or a partner agent — via the same schemas (get_balances, staged place_order + approve, get_execution_report).
Product #2 should not open its own exchange API keys. It connects to your MCP server; Temporal, policy, and audit stay central. Same multi-product play as conversational banking exposing rules via MCP.
A concrete flow: "TWAP down 15% of BTC inventory"
- Operator says: Cut BTC inventory 15% across Binance and OKX, TWAP 40 minutes, max 8 bps vs mid.
- Broker agent (AI SDK) extracts a structured Intent object (Zod). Invalid → ask clarifying questions. Valid → start
DeskIntentWorkflow. - Workflow loads balances/positions via MCP
get_balances/get_positions. - Execution agent proposes a child plan: slices, venues, limits. Plan stored in workflow state.
- If notional > policy threshold →
request_approvalSignal. Desk clicks approve in UI. Workflow resumes. - For each slice:
place_orderActivity with client order id =intentId:sliceN. Retries use same id. Fills ledger intoExecutionLedgerWorkflow. - Mid-run crash? Temporal replays; completed slices are not re-sent.
- Judge schedule wakes: compares realized slippage to 8 bps budget, writes eval, optionally Signals broker with "tighten slice size."
Zero romance. Full audit trail. That is the product.
Failure modes we design for on day one
Double submit after retry.
Every place_order carries a deterministic client order id derived from workflow id + slice index. Venue duplicates become no-ops.
Model invents a venue method.
MCP tool list is the allowlist. No free-form HTTP. Schema validation before Activity execution.
Silent policy override by Judge.
Judge may propose prompt changes and alert humans. Risk limits live in code / config signed by compliance — not in an evolving system prompt.
Hot-path hallucination on sizes.
Size math happens in Activities (decimal-safe), not in LLM arithmetic. The model chooses intent; TypeScript computes quantity.
MCP tool storms.
Per-run tool budgets (same discipline as our agentic production checklist). Alert at 15, hard stop at 25 for desk copilots.
Key material in the agent context.
Exchange API secrets stay in the Activity worker environment. The LLM never sees them — only tool results.
What to build in the first 51 hours vs. the first 51 days
Sprint-shaped vertical slice (51-Hour MVP Sprint):
- One venue (sandbox/testnet)
- Broker + execution workflows
- Three MCP tools: balances, place, cancel
- Slack or thin web UI + approve Signal
- Temporal Cloud or self-hosted Temporal with UI
Production slice (weeks):
- Multi-venue adapters behind the same MCP schemas
- Ledger + reconciliation jobs
- Judge schedule + eval store
- Policy engine (size, venue, symbol allowlists)
- Immutable audit export for compliance
- Kill switch that cancels open agent orders and parks workflows
Don't start with seven venues and a "strategy marketplace." Start with one painful desk workflow that currently lives in a spreadsheet and a group chat.
When this is the wrong architecture
- You need sub-10ms reactive market making — agents don't belong in that loop; keep them for overlay decisions.
- You have no exchange API discipline (shared keys, no IP allowlists) — fix that before adding an LLM.
- Leadership wants "the AI will trade" as the pitch — reframe to ops layer or walk away.
Agents are extraordinary at orchestration and exception handling. They are mediocre at inventing edge. Build accordingly.
How we'd scope it with you
At Xenqube this lands as AI Agent Development for exchange-adjacent and fintech teams — often paired with our Web3 and rails work when venues, wallets, and fiat on/off-ramps sit in the same book. The AI surface sits on Xenith Agents patterns when you want reusable specialists (broker / execution / judge) instead of a one-off script.
If you already feel the pain — manual ticket chaos, reconciliations that wake people up, or a previous "trading bot" that nobody trusts — the stack is ready. Vercel AI SDK for the loop. Temporal for survival. MCP for the boundary. Humans for the risk.
Xenqube designs durable agentic systems for desks and fintech platforms that sit on top of exchange APIs — production workflows, not paper-trading demos.
Read the case study → · Book a Discovery Call → · AI Agent Development → · 51-Hour Sprint →