AI Ops Layer on Exchanges: Vercel AI SDK, Temporal & MCP

Most "AI on top of exchanges" demos look the same: an LLM reads a tweet, places a market order, and a paper wallet dies of inspiration. That pattern is a liability with an API key.

What holds up for desks, brokers, and exchange-adjacent fintechs is quieter: an AI ops layer on exchanges. Agents parse desk intent, call exchange tools through a typed contract, and keep 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 designed this for teams that already have exchange connectivity and need intelligence on top of it, without another black-box trading bot. For 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 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_approval Signal. Desk clicks approve in UI. Workflow resumes.
For each slice: place_order Activity with client order id = intentId:sliceN. Retries use same id. Fills ledger into ExecutionLedgerWorkflow.
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 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 exchange APIs as production workflows.

Read the case study → · Book a Discovery Call → · AI Agent Development → · 51-Hour Sprint →