Risk Must Be Enforced, Not Requested
AutoHedge's risk problem is not that its prompts forget risk; they name position size, drawdown, exposure, stop loss, and take profit explicitly. The harder question is what happens after a model recommends those values and before a transaction can be signed. This chapter treats that gap as a control-plane problem, so the reader can translate AutoHedge's requested fields into enforceable conditions, identify the portfolio state a model cannot own by itself, and distinguish a risk opinion from authorization to act.
A risk score is an opinion until something can reject it
The Risk Manager's prompt asks for a recommended position size, maximum drawdown risk, market-risk exposure, correlation risk, and an overall risk score. The Execution Agent's prompt asks for order type, quantity, entry price, stop loss, take profit, and time in force. These are the right subjects to discuss around a trade. They are not yet a control system.
A recommendation answers a question such as, “Given this thesis, what exposure might be reasonable?” A control answers a different question: “Given the actual portfolio, venue, limits, and current state, is this exact action permitted?” The first question allows judgment and uncertainty. The second needs a rule that can return pass, reject, or require review. AutoHedge's prompts clearly describe the first kind of work. In the visible worker configuration, the Quant, Risk, and Execution agents return strings, and the repository does not show a local schema or numeric validator that turns their responses into enforceable decisions.
Consider a position-size recommendation. The Risk Manager might return a small percentage of capital, but the meaning of that percentage depends on what “capital” refers to, which wallet or account is in scope, what positions already exist, and whether other orders have reserved funds. A numerical value can look precise while omitting the denominator and the state needed to interpret it. The same problem applies to maximum drawdown. A model can state a threshold, but a threshold becomes a control only when a system measures current and projected exposure against it and stops or changes the order when the condition is breached.
The prompt's overall risk score has a similar limitation. A score compresses several judgments into one number, but compression can hide the reason for uncertainty. A high score might reflect strong technical signals while ignoring an unresolved instrument mapping or missing holdings data. A low score might reflect incomplete evidence rather than a measured expectation of loss. Unless the score carries its inputs, time basis, and failure status, a downstream component cannot know whether it should compare, display, or disregard it.
Order fields are not safer merely because they are concrete. Quantity needs a unit and an asset. An entry price needs a quote currency and a freshness boundary. A stop loss needs a direction and a relationship to the entry. A take-profit level needs a direction, and both levels need to remain meaningful for the venue that will receive the order. Time in force needs an interpretation that matches the venue's behavior. AutoHedge's Execution prompt asks a model to provide these fields, but the source does not show code that checks their relationships before the signing surface is reached.
This does not make the specialist roles pointless.