Agents On The Trading Desk: The Autonomy Ladder, Pre-Trade Guardrails And Kill-Switches That Regulators Now Expect

There is a specific moment in every agentic AI project on a trading desk where the demo stops being impressive and starts being frightening. It is the moment someone asks the obvious question: what happens if it is wrong? Not wrong in the harmless way - a mediocre summary, a clumsy sentence - but wrong in the way that submits a child order, moves a limit, cancels a hedge or calls a broker API twice. In 2026 that question stopped being hypothetical. Agents are genuinely in production across the buy and sell side, ingesting tick data, filings, news and alternative signals, and acting inside latency and compliance boundaries. And in the same year, the supervisory position hardened: in February, ESMA published a supervisory briefing on algorithmic trading in the EU that explicitly tells firms to recognise the AI in their algorithmic trading systems when complying with RTS 6, and to manage the risk that a series of small recalibrations accumulates over time into a material change in model output. That sentence is aimed squarely at machine-learning systems that drift, and it lands on engineering teams.

We build trading platforms, charting systems and quant infrastructure for financial firms, and the agentic work we are asked to do now is overwhelmingly not 'build an AI that trades'. It is 'build an AI that does the ninety per cent of the desk's work that is not the trade decision, and make absolutely certain it cannot cause a trade we did not authorise'. That is a much more interesting engineering problem, and it has a shape. This playbook is that shape: the autonomy ladder that defines what an agent may do, the deterministic pre-trade risk layer that sits below it, the tool-call authorisation that happens before the side effect rather than after, the audit trail that makes the whole thing explicable to a regulator eighteen months later, and the kill-switch that - crucially - you have actually tested under load.

The Autonomy Ladder: Say What The Agent May Do, In Code

The single most valuable artefact in an agentic trading project is not the prompt, the model choice or the orchestration framework. It is a written ladder of autonomy levels, agreed with the desk and with compliance, where every rung is a machine-checkable predicate rather than an adjective. 'The agent assists the trader' is an adjective. 'The agent may call read-only tools and may draft an order object that is rendered in the UI but is not transmitted until a human clicks Send, and the click is bound to the exact order hash the agent produced' is a predicate. You can test the second one. You can put it in a control document. You can point at the line of code that enforces it.

The ladder we use on desk engagements has five rungs, and almost all real production systems in 2026 sit on rungs one through three. The interesting engineering is in making each rung a hard boundary rather than a convention:

1. 01L0 - Read-only research. The agent may query market data, filings, internal research and position data. It has no tools with side effects at all. The permission surface is enforced by the tool registry, not by the prompt: there is simply no write tool registered in this agent's session.
2. 02L1 - Draft and propose. The agent may construct a structured order or workflow object and surface it to a human. The object is validated against the same schema the OMS uses, and a content hash is computed. Nothing transmits. The human approves the hash, not the prose.
3. 03L2 - Bounded execution inside a hard envelope. The agent may transmit orders, but only within a pre-trade envelope defined outside the agent: instrument allow-list, maximum notional per order and per day, maximum participation rate, permitted venues, permitted order types, and a time window. The envelope is evaluated by a deterministic service the agent cannot call, argue with or modify.
4. 04L3 - Supervised autonomous operation. The agent runs continuously inside the envelope with human-on-the-loop rather than human-in-the-loop: every action is executed and simultaneously streamed to a supervision UI with a mandatory cooling-off window for cancellable actions, and any breach of a soft threshold pauses the agent and escalates.
5. 05L4 - Autonomous. Reserved, in our experience, for non-consequential internal workflows - reconciliation, data quality triage, documentation - and essentially never granted on order flow. If someone is proposing L4 on a trading path, the correct engineering response is to ask which control at L2 they think is unnecessary, and why.

The Deterministic Pre-Trade Risk Layer

Every desk already has pre-trade risk controls, because RTS 6 has required them since MiFID II. The mistake teams make when adding an agent is to treat the agent as a new kind of client that needs a new kind of control. It does not. The agent is a client of the existing control plane, and the correct architecture puts the agent strictly above the existing pre-trade risk service, with no path around it. If your agent can reach the broker API directly, the architecture is already wrong, no matter how good your prompt is.

Here is the gate we implement, deliberately boring and deliberately synchronous. Note what is absent: there is no model call anywhere in this file. The risk layer must be reviewable by a compliance officer who does not read Python fluently, reproducible from inputs alone, and fast enough to sit on the hot path.

from dataclasses import dataclass
from datetime import datetime, time, timezone
from decimal import Decimal

@dataclass(frozen=True)
class Envelope:
    """The autonomy envelope. Loaded from config, versioned, signed off by
    the desk head and compliance. The agent cannot read or modify it."""
    instruments: frozenset[str]
    venues: frozenset[str]
    order_types: frozenset[str]
    max_notional_per_order: Decimal
    max_notional_per_day: Decimal
    max_participation_rate: Decimal   # of trailing ADV
    window_start: time
    window_end: time

@dataclass(frozen=True)
class Decision:
    allowed: bool
    reasons: tuple[str, ...]
    envelope_version: str

def evaluate(order, envelope, envelope_version, state, now=None) -> Decision:
    """Pure function of (order, envelope, state, now). No I/O, no model call.
    Every rejection reason is a stable machine-readable code so that the
    downstream audit record is queryable, not a free-text string."""
    now = now or datetime.now(timezone.utc)
    reasons: list[str] = []

    if order.instrument not in envelope.instruments:
        reasons.append("INSTRUMENT_NOT_PERMITTED")
    if order.venue not in envelope.venues:
        reasons.append("VENUE_NOT_PERMITTED")
    if order.order_type not in envelope.order_types:
        reasons.append("ORDER_TYPE_NOT_PERMITTED")

    notional = order.quantity * order.limit_price
    if notional > envelope.max_notional_per_order:
        reasons.append("MAX_NOTIONAL_PER_ORDER_BREACH")
    if state.notional_today + notional > envelope.max_notional_per_day:
        reasons.append("MAX_NOTIONAL_PER_DAY_BREACH")

    adv = state.trailing_adv(order.instrument)
    if adv > 0 and (order.quantity / adv) > envelope.max_participation_rate:
        reasons.append("PARTICIPATION_RATE_BREACH")

    if not (envelope.window_start <= now.timetz().replace(tzinfo=None) <= envelope.window_end):
        reasons.append("OUTSIDE_TRADING_WINDOW")

    # Fat-finger guard: reject prices far from the prevailing mid, which is
    # the single control that most often catches a hallucinated decimal place.
    mid = state.mid(order.instrument)
    if mid and abs(order.limit_price - mid) / mid > Decimal("0.05"):
        reasons.append("PRICE_COLLAR_BREACH")

    if state.kill_switch_engaged:
        reasons.append("KILL_SWITCH_ENGAGED")

    return Decision(
        allowed=not reasons,
        reasons=tuple(reasons),
        envelope_version=envelope_version,
    )

Pre-Action Authorisation: Stop The Side Effect Before It Happens

The second architectural pillar is that authorisation happens before the tool executes, not after the agent decides. This sounds obvious and is routinely got wrong, because most agent frameworks are built around a loop that calls the tool and then hands the result back to the model. In that design, the side effect has already happened by the time anything inspects it. For a read-only tool that is fine. For anything that touches money, order flow or client data, you need an interception point between 'the model emitted a tool call' and 'the tool ran'.

In practice this is a middleware layer in the agent runtime. Every tool declares a risk class; every call in a consequential class is routed through a policy engine that can allow it, deny it, or suspend it pending human approval. The pattern in TypeScript, which is where most of our agent runtimes sit because they live next to the trading UI:

type RiskClass = "read" | "write" | "consequential";

interface ToolDefinition {
  name: string;
  riskClass: RiskClass;
  // Tools declare their own schema; the runtime validates arguments against
  // it BEFORE the policy engine sees them, so policy reasons about typed
  // values rather than model-generated strings.
  schema: JSONSchema;
  execute(args: unknown, ctx: SessionContext): Promise<unknown>;
}

type PolicyVerdict =
  | { kind: "allow" }
  | { kind: "deny"; code: string }
  | { kind: "require_approval"; approvalId: string; renderable: OrderPreview };

export async function authorizeAndExecute(
  tool: ToolDefinition,
  rawArgs: unknown,
  ctx: SessionContext,
): Promise<ToolResult> {
  // 1. Schema validation first. A tool call that does not typecheck never
  //    reaches the policy engine, and never reaches the desk.
  const parsed = validate(tool.schema, rawArgs);
  if (!parsed.ok) {
    return auditable(ctx, tool, { status: "rejected", code: "SCHEMA_INVALID" });
  }

  // 2. Autonomy level gate. An L1 session simply has no consequential tools
  //    registered, so this is defence in depth rather than the primary control.
  if (rankOf(tool.riskClass) > rankOf(ctx.maxRiskClass)) {
    return auditable(ctx, tool, { status: "rejected", code: "AUTONOMY_LEVEL" });
  }

  // 3. Deterministic policy. For order tools this delegates to the same
  //    pre-trade gate the human traders go through - one implementation,
  //    not a parallel "AI risk" path that drifts out of sync.
  const verdict: PolicyVerdict = await policy.evaluate(tool, parsed.value, ctx);

  if (verdict.kind === "deny") {
    return auditable(ctx, tool, { status: "rejected", code: verdict.code });
  }

  if (verdict.kind === "require_approval") {
    // The side effect has NOT happened. We park the call, render a preview
    // bound to a content hash of the exact arguments, and return a result
    // that tells the model it is waiting - not that it failed, which would
    // otherwise send it off to find a creative workaround.
    await approvals.park(verdict.approvalId, { tool: tool.name, args: parsed.value });
    return auditable(ctx, tool, {
      status: "pending_approval",
      approvalId: verdict.approvalId,
      modelVisibleMessage:
        "This action is queued for human approval. Do not retry or attempt an alternative route.",
    });
  }

  const output = await tool.execute(parsed.value, ctx);
  return auditable(ctx, tool, { status: "executed", output });
}

Model Drift Is Now A Documented Supervisory Concern

ESMA's February 2026 supervisory briefing contains a point that engineering teams should read literally: firms should manage the risk that a series of minor or small changes due to recalibrations could accumulate over time into a material change in the model output. For a classical algo with hand-tuned parameters, that means change control on the parameters. For an AI-driven component it means something much more demanding, because the things that change are not only your parameters. Your model provider ships a new version. Your retrieval corpus grows. Your prompt gets a clarifying sentence added by someone fixing an unrelated bug. Each change is individually immaterial. The composition is not.

The engineering answer is to treat the entire decision-making configuration as one versioned, hashed artefact, and to make the annual self-assessment RTS 6 already requires a matter of querying your own telemetry rather than reconstructing history from memory. Concretely, every agent action we emit carries a decision fingerprint:

import { createHash } from "node:crypto";

/**
 * Everything that can change the agent's output, collapsed into one hash.
 * Stored on every action record. When the desk asks "did anything change
 * between the good week and the bad week?", this is a GROUP BY, not an
 * archaeology project.
 */
export interface DecisionConfig {
  modelId: string;          // pinned, e.g. a dated snapshot - never a floating alias
  modelParams: { temperature: number; topP: number; seed?: number };
  promptTemplateHash: string;
  toolRegistryHash: string; // names + schemas + risk classes
  envelopeVersion: string;
  retrievalIndexVersion: string;
  policyBundleVersion: string;
}

export function fingerprint(cfg: DecisionConfig): string {
  // Stable key order matters: an unstable stringify silently produces a new
  // fingerprint for an unchanged config and destroys the whole signal.
  const canonical = JSON.stringify(cfg, Object.keys(cfg).sort());
  return createHash("sha256").update(canonical).digest("hex").slice(0, 16);
}

• Pin the model to a dated snapshot, never a floating alias. A provider upgrading an alias underneath you is an unlogged, unreviewed change to a system in your regulatory perimeter.
• Version the prompt template as code, in the same repository, behind the same review as the risk gate. If a prompt change can change order behaviour, it is trading logic and should be reviewed as trading logic.
• Store the fingerprint on every action record, alongside the pre-trade decision and its reason codes. Sudden shifts in the distribution of rejection reasons are the earliest drift signal you will get, and they cost nothing to monitor.
• Run a fixed replay set - a frozen basket of historical scenarios - against every configuration change before it ships, and diff the resulting action sets. Behaviour changes you did not intend show up here rather than in production.

The Kill-Switch You Have Actually Tested

Back to the finding that should worry everyone: nearly three in four banks cannot confirm they can shut down a malfunctioning AI model. In our experience this is rarely because no stop button exists. It is because the stop button was specified as a boolean and implemented as a boolean, and a boolean does not describe the actual problem. When you engage a kill-switch on an agentic trading system, there are at least five distinct things happening at once, and a naive flag addresses one of them.

1. 01New agent turns must stop being scheduled. Easy, and the part everyone builds.
2. 02In-flight tool calls must be handled. A call already dispatched to a broker API will complete. You need to know which ones were in flight, and to reconcile their outcomes after the stop - which means the kill-switch has to read the same in-flight ledger the runtime writes to.
3. 03Parked approvals must be invalidated, not left sitting in a queue for a trader to approve twenty minutes later, long after the reason for the stop has been forgotten.
4. 04Working orders already in the market must be dealt with by an explicit policy decision - cancel all, cancel unfilled, or leave and hedge. This is a desk decision that must be made in advance and encoded, because nobody makes it well at 14:32 during an incident.
5. 05The stop must be effective even if the agent runtime itself is the thing that is unhealthy. A flag the runtime checks is useless when the runtime is wedged. The authoritative stop belongs at the gateway - the pre-trade gate rejects everything from agent sessions, and it is a separate process with a separate deployment.

Where Agents Are Genuinely Earning Their Place On The Desk

It is worth being precise about where the value is actually landing, because the popular framing - autonomous AI traders generating alpha - is not what the successful production systems we see are doing. Engineers trust agents most where the environment is instrumented, the task is well-scoped, and the success signal is machine-checkable. That describes a great deal of desk work, and almost none of it is the trade decision:

• Pre-trade research assembly: an agent that gathers the filings, the recent news, the current positioning, the borrow availability and the venue analysis into one reviewed brief before the human decides. Read-only, L0, immediately useful, no regulatory drama.
• Earnings and disclosure extraction at scale: ingesting hundreds of transcripts a quarter, extracting guidance changes into a structured schema with citations back to the source span. Machine-checkable, because a human can verify the span in two seconds.
• Execution monitoring and exception triage: an agent that watches fills against expectation and escalates the outliers with an explanation, rather than one that chooses the execution strategy. The bar for a false negative is low because the deterministic alert still fires.
• Post-trade reconciliation and break investigation: high-volume, rules-heavy, pattern-shaped, chronically under-staffed. This is where the clearest ROI in the whole agentic category sits, and it never touches order flow.
• Compliance evidence assembly: collecting the artefacts for an RTS 6 self-assessment or an internal audit into a structured pack. Tedious for humans, well-suited to agents, and the output is fully verifiable.

“The teams shipping agents successfully in 2026 are not the ones with the best models. They are the ones with the best evaluation infrastructure - and on a trading desk, the pre-trade risk layer is part of that infrastructure.”

What The FCA's Live Testing Programme Signals For UK Teams

For firms building in the UK, the FCA's AI Live Testing programme is the most useful signal available, and it is worth reading as an engineer rather than as a policy watcher. The second cohort - announced in April 2026, comprising Aereve, Coadjute, Barclays, Experian, GoCardless, Lloyds Banking Group (Scottish Widows), UBS and Palindrome - is testing agentic payments, AML detection, KYC and AI-enabled investment support in supervised production, with the FCA supported by the assurance specialist Advai. The programme runs to the end of 2026 with results published in early 2027, and a good and poor practice report on AI in financial services due later in 2026.

The engineering read is this: the UK regulator's revealed preference is for firms that can demonstrate controls empirically, in live conditions, with a technical assurance partner looking at the evidence. That is an enormous advantage for teams who have built the instrumentation described in this playbook, and a serious problem for teams whose controls exist only in a policy document. If you are building agentic systems in UK financial services, the artefacts to prioritise are the ones that produce evidence: the decision fingerprint, the reason-coded pre-trade record, the replay set and its diffs, and the timed kill-switch drill. Those are exactly what a live-testing conversation consumes.

A Reference Architecture, End To End

Pulling it together, the shape that works looks like this, from the top down. It is not complicated, and that is the point - the complexity in agentic trading systems belongs in the evaluation and the observability, not in the control path:

1. 01Agent runtime. Model pinned to a dated snapshot, prompt templates versioned in the repository, tool registry assembled per session from the operator's autonomy level. No credentials for anything consequential exist in this process.
2. 02Tool authorisation middleware. Schema validation, risk-class check, policy evaluation, approval parking. Emits an audit record for every call including the rejected ones - the rejections are the most valuable telemetry you will have.
3. 03Deterministic pre-trade gate. The same service human order flow traverses. Pure, fast, reason-coded, versioned envelope. Owns the authoritative kill-switch state.
4. 04OMS/EMS and venue connectivity. Entirely unaware that an agent exists; it sees an order with a session identifier and a decision fingerprint attached, exactly like any other client.
5. 05Immutable action log. Append-only, one record per tool call, carrying the fingerprint, the pre-trade decision with reason codes, the approval identity if any, and the resulting order identifiers. This is the artefact that answers every question anyone will ask you later.
6. 06Supervision plane. Live view of agent actions, soft-threshold alerting, one-click stop wired to the gate rather than the runtime, and the drill results from the last time you tested it.

The Bottom Line

Agentic AI on the trading desk is real, it is in production, and in 2026 it acquired a supervisory context that engineering teams cannot delegate to a policy function. The architecture that survives is not the one with the most sophisticated agent; it is the one where autonomy is a property of the tool registry rather than the prompt, where a deterministic pre-trade gate sits below the agent with no path around it, where authorisation happens before the side effect, where the whole decision configuration is fingerprinted so drift is a query rather than an investigation, and where the kill-switch has been pulled in a drill with a stopwatch running. The firms getting value from agents on the desk are not the ones taking more risk with them. They are the ones who made the risk boundary explicit enough that they could safely stop worrying about it, and then pointed the agent at the enormous volume of desk work that never needed to touch order flow in the first place. That is the work we do as a trading systems and AI automation developer in London, and if there is one sentence to take away, it is this: build the boundary first, and the agent becomes the easy part.

References & Further Reading

• ESMA - Supervisory Briefing on Algorithmic Trading in the EU, 26 February 2026. esma.europa.eu/sites/default/files/2026-02/ESMA74-1505669079-10311_Supervisory_Briefing_on_Algorithmic_Trading_in_the_EU.pdf
• Macfarlanes - Algorithmic trading and artificial intelligence: ESMA supervisory briefing. macfarlanes.com/insights/102mpep/algorithmic-trading-and-artificial-intelligence-esma-supervisory-briefing
• Hogan Lovells - ESMA publishes Supervisory Briefing on algorithmic trading under MiFID II: what firms need to know. hoganlovells.com/en/publications/esma-publishes-supervisory-briefing-on-algorithmic-trading-under-mifid-ii-what-firms-need-to-know
• FCA - AI Live Testing: second cohort announced (April 2026). fca.org.uk/news/press-releases/fca-announces-second-cohort-ai-live-testing
• FCA - AI Lab. fca.org.uk/firms/innovation/ai-lab
• TechTimes - Bank AI oversight expands to every exam: generative AI bypasses SR 26-2 as kill-switch gap grows (June 2026). techtimes.com/articles/318340/20260613/bank-ai-oversight-expands-every-exam-generative-ai-bypasses-sr-26-2-kill-switch-gap-grows.htm
• Linklaters - MiFID II: ESMA issues supervisory briefing on algorithmic trading. financialregulation.linklaters.com/post/102mknu/mifid-ii-esma-issues-supervisory-briefing-on-algorithmic-trading
• Reed Smith - FCA multi-firm review of algorithmic trading controls: implications and next steps. reedsmith.com/articles/fca-multi-firm-review-of-algorithmic-trading-controls
• Confident AI - LLM agent evaluation metrics in 2026: tool calling, task completion, reasoning and trace-based evals. confident-ai.com/blog/llm-agent-evaluation-complete-guide

Code in this guide is illustrative and supplied without warranty. Review and test it before production use. Nothing here is investment advice. Important information