Deploying and Monitoring RL Agents
Why a reinforcement-learning trading agent that performs well in backtests needs extra safeguards before and after going live, since it keeps acting on live data rather than just predicting once.
A supervised model that goes live just makes predictions; a reinforcement-learning agent that goes live keeps acting, and each action changes the state it sees next. That feedback loop is exactly what makes RL agents risky to deploy without extra guardrails: a bug or distribution shift doesn't just produce one bad prediction, it can send the agent into a self-reinforcing sequence of bad decisions, since it's still "learning" from the consequences of its own mistakes.
Production RL deployments typically wrap the agent in hard constraints the policy cannot override — position limits, maximum order size, a kill switch — precisely because the policy itself was trained to optimize a reward function, not to respect real-world limits it never saw during training. Monitoring focuses less on any single decision and more on drift: is the distribution of states the agent is encountering live starting to diverge from what it saw in training or backtesting, which is often the earliest sign the policy is heading somewhere it wasn't tested for.
Worked example. An RL execution agent trained on historical order-book data starts encountering a market regime with 5x its historical volatility. A hard position-size cap prevents it from scaling up an aggressive strategy that its reward function alone would have encouraged, buying time for a human to intervene before the drift compounds.
An RL agent's live actions feed back into what it sees next, so deployment requires hard external limits the policy cannot violate and ongoing monitoring for state-distribution drift — not just accuracy checks on individual predictions, which is what supervised-model monitoring focuses on.
Related concepts
Further reading
- Industry practice notes on production RL systems, adapted from robotics and trading deployments