How We Build Better AI Trading Agents: Harness, Runtime, and Guardrails

The practical goal is to make agents better at trading. In our published evidence, that means improving mandate fidelity, action validity, runtime reliability, and the quality of the feedback used in the next evaluation. In our work at DXRG, those improvements have required treating the model as one component inside a trading system.

The mandate has to be compiled clearly. Market and portfolio state have to be correct, actions have to use a typed schema, and the runtime has to validate what reaches execution.

We call that surrounding system the harness. Its decision path contains the mandate compiler, state assembler, memory policy, and tool schemas. Its action path contains deterministic controls, the execution adapter, and the evaluation trace that turn a model response into a bounded market action. A stronger model can improve reasoning. The right harness makes that reasoning usable, measurable, and correctable under repeated trading.

Evidence boundary: The deployment measurements below are historical observations from DX Terminal Pro, a bounded 21-day real-capital event, and the before-and-after results come from controlled pre-launch tests. The 87%/96%/99.9% comparison belongs to a separate internal EVM evaluation. These results support our harness design and evaluation method, not a promise of returns or universal transfer.

Download the versioned trading-agent guardrail matrix as JSON or as CSV. Version 1.1 maps twelve deterministic controls inside the harness to their objective, minimum evidence, failure signal, enforcement point, and runtime response.

The Short Answer: What Actually Improves a Trading Agent?

An agent improves when the full loop improves. Better market reasoning matters, but the model cannot compensate for a buried mandate, stale portfolio state, a broken order payload, or missing settlement feedback.

We evaluate four properties separately:

1. Decision quality: does the agent interpret the mandate and current state well enough to choose a sensible action or abstain?
2. Action validity: does the proposed action satisfy the schema, permissions, limits, and venue requirements?
3. Runtime reliability: does a valid action reach the intended venue once, settle correctly, and reconcile into the next state?
4. Learning value: does the trace identify which part of the loop caused an outcome and supply a useful case for the next evaluation?

These properties interact without collapsing into one score. Profit can coexist with a malformed process. A valid order can express a poor decision. A strong decision can fail during submission. The harness should expose each failure at the stage where we can fix it.

One Model, Thousands of Different Traders

DX Terminal Pro made this concrete. For 21 days, 3,505 user-funded agents traded real ETH inside a sealed onchain market. The deployment produced 7.5 million agent invocations and roughly 300,000 onchain actions across about $20 million in volume, with more than 5,000 ETH deployed.¹

Every agent shared the same model, hardware, harness, and market rules. Owners supplied a natural-language strategy and five structured controls. On each invocation, the agent read that mandate with current market and portfolio state, then returned buy, sell, or observe. The user could pause the vault or trigger liquidation, while the agent alone placed trades during the event.

That setup let us see the harness at population scale. Trading Activity produced a sixfold spread in action frequency, from 2.8% to 16.8% of invocations. Trade Size mapped from about 2% of available ETH at the lowest setting to about 95% at the highest. The same base model produced opposite trades in the same five-minute token windows because mandates, settings, positions, and state differed across agents.¹

The scene we keep returning to happened before launch. A 2.3% trading fee was present in every prompt, yet agents cited it in only 3% of reasoning traces when the sentence sat in paragraph eight. Moving the unchanged sentence to paragraph one raised citation to 74%. The model and market data stayed fixed. Reading order changed observed behavior.¹

That is why our architecture work begins around the model. The model had the fact in both cases. The compiler determined whether the fact shaped the decision.

The Harness Around the Model

The operating layer has seven linked stages. Each stage has its own test and evidence.

The model is essential, but it occupies one row. Model comparisons that omit the other six rows cannot tell us whether an improvement came from reasoning, context construction, state quality, validation, or execution.

Compile the Mandate Before the Model Sees It

Natural-language strategy is useful because users can express goals and conditions that a fixed form cannot anticipate. It is also easy to miscompile. The runtime needs an explicit source of truth when free text conflicts with structured controls or with an older instruction.

In Pro, small prompt changes created measurable population effects. Some sell traces invented labels such as “Hierarchy rule #2” after treating prior reasoning as precedent. Marking old reasoning as context and forbidding fabricated named rules reduced that behavior from 57% to 3% in the controlled test.¹ Presenting a market mechanic as structured context with its payoff order leading moved capital deployment in the affected test population from 42.9% to 78%.¹

The mandate compiler should therefore do more than concatenate text. It should preserve authenticated user intent, establish precedence, insert current structured controls, and render important market mechanics where the model can use them. We freeze that compiler with the rest of the evaluated configuration because a reordered sentence can change behavior even when the model version stays fixed.

Structured controls deserve the same attention. In Pro, users who specified exit conditions or parameter changes were 4.2 times as likely to close profitably as users who asked the agent to “outperform” or “pick winners.” That association is observational inside the bounded event. It supports a design lesson rather than a universal strategy claim: a checkable mandate gives the agent a clearer job.¹

State Is Part of the Strategy

A trading decision only has meaning relative to the state that produced it. Price, liquidity, open orders, and balances can change between inference and submission. Positions, fees, and venue status can change too. The state assembler should create one versioned snapshot for the decision and make freshness visible to the validator.

Portfolio state matters just as much as market state. Two agents seeing the same price can rationally take opposite actions because one already holds the asset and the other does not. During Pro, 92.9% of trades fell inside five-minute token windows where some agents bought and others sold the same token.¹ Shared model and shared market tape did not erase the distinct portfolio and mandate state carried by each vault.

Memory belongs inside this state design. Long context alone did not obviously help in our controlled work. Agents behaved better when memory was recent, structured, and source-labeled. Prior reasoning remained context rather than precedent. A useful memory record says what was observed, when it was observed, and which decision it informed. It does not silently become a new rule.

The failure tests follow directly from the mechanism: stale timestamps, missing balances, crossed feeds, unresolved fills, and portfolio snapshots that disagree with venue records. If required state cannot be reconciled, the runtime should withhold new exposure until a fresh snapshot exists.

The Runtime Must Bind Decisions to Actions

The model should propose from a bounded action schema. In Pro the action space was buy, sell, or observe. A broader deployment can support more actions, but every field still needs a type, unit, range, and explicit abstention path.

Deterministic policy then checks the proposal against the current mandate and state. Permissions establish which assets or venues are reachable. Limits bound order size, exposure, loss, and activity. Validation should happen on the final venue-ready payload so symbol normalization or quantity conversion cannot change the action after approval.

This boundary is also where retries become a trading concern. The runtime needs stable request identifiers and venue acknowledgements so a timeout does not become a duplicate order. Submission, fill, fee, and balance records must reconcile before the next portfolio state is trusted.

In the historical Pro deployment, 99.9% of policy-valid submissions settled successfully.¹ In a separate internal EVM swap-construction evaluation, a model-version change moved aligned successful transactions from 87% to 96%. Adding the Pro-style harness to the stronger model moved the same internal measure to 99.9%.¹ That comparison concerns transaction construction under its stated protocol. It does not measure open-market profitability.

The useful conclusion is specific: improving the runtime closed failure modes that remained after the model upgrade. We should test model and harness changes as separate interventions so their contributions stay attributable.

Use the Trace as the Improvement Loop

We define a mandate-to-settlement trace as the linked record from authenticated user intent through rendered context, model decision, policy result, submitted action, venue response, and portfolio effect. Every later use of the trace should answer a mechanism question: which stage transformed the mandate incorrectly, rejected a valid action, duplicated a submission, or failed to update state?

DX Terminal Pro preserved that record at the invocation level. It let us separate a buried fee fact from a model reasoning error. It distinguished fabricated policy from an execution failure. It also made the 24 prompt revisions before launch evaluable against replayed scenarios rather than intuition.¹

The same record supplies the feedback loop for future work. A failed action can become a regression case at the exact stage that failed. A sequence can be replayed across model versions while the harness stays frozen. A policy change can be tested against the same proposed payloads. Longer-term training can use verifiable execution outcomes while retaining the mandate and state that produced them.

This is the part of agent improvement that disappears in a text-only benchmark. An answer can sound reasonable while the action violates the mandate or fails at settlement. The trace makes those differences measurable.

Where Guardrails Fit

Guardrails are mechanisms inside the harness. They keep agent improvement bounded enough to evaluate under real execution. Identity ties an action to a principal and policy version. Capital isolation limits reachable funds. Transaction rules reject actions outside the mandate. Monitoring detects policy denials, state drift, execution failures, and reconciliation breaks.

Interruption and recovery complete the runtime. A kill switch should revoke execution authority without asking the model to cooperate. Restart should follow reconciliation, a bounded root cause, regression tests, and explicit reauthorization. FINRA guidance for firms using algorithmic strategies discusses lifecycle testing, retrievable code versions, rapid-disable mechanisms, and heightened scrutiny for new code within its scope.² We use that source as scoped operational guidance, not as a universal trading-agent rule.

The downloadable matrix keeps each mechanism testable. It names where the check runs, what evidence remains, which failure signal matters, and what the runtime should do next. That is more useful than labeling a system “safe” without a deployed-path test.

A Practical Evaluation Sequence

Freeze the model and harness as one versioned evaluation subject, then change one component at a time. Our preferred sequence is:

1. Replay mandate-compilation cases and confirm that structured controls produce the intended gradient.
2. Test state assembly with stale data, missing fields, unresolved fills, and conflicting portfolio records.
3. Run decision evals with the action schema fixed, including abstention and repeated near-identical states.
4. Exercise policy and execution boundaries with limit edges, timeouts, retries, and payload mismatches.
5. Reconcile every submitted action into the trace before promoting the configuration to a higher evidence class.

The Agentic Trading Evidence Ladder keeps replay, paper, shadow, and live claims separate. The DXRG Benchmark Card records the full evaluation subject, costs, baselines, controls, and artifacts. Our technical definition of agentic trading explains why delegated decisions and market actions distinguish an agent from an ordinary analysis tool.

No single stage proves trading skill. The sequence gives us a way to find regressions before increasing authority and a way to attribute improvements when behavior changes.

The Deployment Standard

A model is ready for more authority when the surrounding runtime produces inspectable evidence. We want a frozen mandate compiler, current reconciled state, a typed action contract, deterministic policy results, and a complete mandate-to-settlement trace. We also want lower-risk regression cases for every known failure and an operator-tested interruption path.

That standard serves the larger research goal: make agents better at trading through a loop we can measure. Better prompts, memory, models, controls, and training all have a place. The harness tells us which intervention helped, the runtime carries the decision into the market, and the trace brings the result back into the next evaluation.

DX Terminal Pro was one bounded market with one base-model family. It demonstrated that thousands of user-funded agents could operate through a shared harness while producing different behavior from different mandates and state. The next work is to test which improvements transfer across models, venues, assets, and longer horizons without stretching the original evidence beyond its setting.

The page's central question is practical: What system around the model makes the next trading decision clearer, the resulting action more reliable, and the outcome easier to learn from?

---

Version 1.1. Materially revised July 20, 2026. Corrections: poof@dxrg.ai. This article is research and educational material, not financial, investment, legal, compliance, or security advice.

Footnotes

1. DXRG, DX Terminal Pro. See “The Big Result,” “What Broke Before Launch,” “What the Production Run Looked Like,” and “Why the Trace Matters.” The linked technical paper contains the architecture, methodology, and evidence boundaries. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

2. FINRA, “Regulatory Notice 15-09: Guidance on Effective Supervision and Control Practices for Firms Engaging in Algorithmic Trading Strategies”, March 26, 2015. The notice applies to FINRA firms within its stated scope. ↩