A workflow for trading with an AI copilot
Most writing about AI and trading argues about whether a model should be allowed to trade. That is the least interesting question, because the answer for almost everyone is no and the useful work is elsewhere.
Here is where a model actually fits in a process, step by step, and what stays yours.
1. Before the session: the limits
Decided in advance, written as code, not revisited during trading.
- Risk per trade, from your losing streak arithmetic.
- A daily loss limit.
- Position caps, per trade and per account.
- A cooldown after consecutive losses.
The model is not involved in this step and should not be. These are the constraints it operates inside. A limit the model can discuss is a limit the model can be argued out of — the whole point is that it is not a participant in that conversation.
2. Reading the market: the model is genuinely good here
Read-only tools, no order path, almost no risk. This is where most of the value is:
- Summarising exposure across positions in a way exchange UIs generally do not.
- Answering “what would it take for this to get uncomfortable”.
- Catching what you did not check — funding accrued, how close liquidation is, whether fees are eating a thin edge.
- Explaining why a position is behaving oddly, which is a mechanical question models answer well.
Note what is absent: asking it what will happen. It cannot, and asking anyway produces confident text that reads like an answer — see can AI predict the market.
Keep this session separate from anything that reads news or external pages. That separation is the primary defence against prompt injection, and it costs nothing to maintain if you set it up that way from the start.
3. Drafting a plan: proposal, not action
You have an idea. The model turns it into something concrete:
- Entry, stop, size, and a stated rationale.
- The stop where the idea is invalidated — see how to choose a stop-loss level.
- Size derived from the stop and your risk budget, not chosen — the position size calculator is the arithmetic.
The value here is not the model’s opinion. It is that a structured plan forces the parts you were leaving implicit into the open. Where exactly is this wrong? What does that make the size? What is the R? Half the benefit arrives before the model says anything, in having to specify the question.
4. Approval: the boundary
The plan becomes an order only when you say so, and what you approve is the actual parameters rather than a summary of them.
MCP’s own specification recommends clients “show tool inputs to the user before calling the server” — for an order, the tool inputs are the trade. The full argument for why this boundary exists, and why the protocol recommends it without requiring it, is in why MCP needs an approval layer.
The design details that make an approval step keep working past its two hundredth appearance — computed risk on the card, limits rejecting before display, no batch approvals, no timeout defaults — are in designing an approval workflow.
5. Execution: no retries
The order goes out. If it fails ambiguously, stop.
A timeout on an order call means the outcome is unknown, not that it failed, and a model looking at an error will naturally try again. Reconcile against open orders and positions before sending anything — and do not rely on a client order ID to save you, because on some venues its uniqueness is narrower than the advice assumes. See retrying a failed order is not safe.
6. Review: the step people skip
The model is good at this and it is where compounding improvement lives.
Read your decision log back with it. Useful questions:
- Were the trades I rejected systematically worse than the ones I approved? If not, the approval step is costing time and adding nothing — worth knowing.
- Is my realised R below my planned R, and by how much? That gap is fees, slippage and early exits, and it is measurable.
- Did any limit actually fire, or do I only believe it protected me?
- Which setups carry the expectancy, and which are being subsidised?
None of this works without records. What to capture is in logging tool calls for a trading audit trail.
What never gets handed over
The limits. Code, not conversation.
The approval. A human decision on specific parameters.
The judgement about whether an idea is right. A model can tell you what a position is doing and what a plan implies. Whether the thesis holds is yours, and outsourcing it produces trades you cannot evaluate afterwards because you never held the reasoning.
The decision to break your own rules. This one is not about AI at all. It is just the step where the damage happens, and having a model agree with you does not make it a better idea.
The honest summary
An AI copilot makes you faster at the parts of trading that are clerical — reading state, checking costs, structuring a plan, reviewing a log. It does not make you better at the part that is judgement, and setups that assume otherwise tend to fail in the way described in why AI backtests do not survive live trading.
Most of the benefit is available with read-only access and no order path at all. That is not a compromise position; it is where the value is.
FAQ
Should I let an AI place trades automatically?
For almost everyone, no — and the more useful observation is that most of the value does not require it. Reading exposure, explaining position behaviour, checking costs and drafting structured plans all work with read-only access and carry essentially no risk. Order placement adds a large new failure surface for a small increment in convenience.
What is the AI actually adding if it cannot predict?
Speed and coverage on the clerical parts: summarising state, catching costs and margin details you did not check, turning a vague idea into a plan with a stop and a size, and reviewing your own record afterwards. These are real improvements to a process, and none of them require knowing what happens next.
Where does the approval step go?
Between the plan and the order, showing the actual parameters — symbol, side, quantity, stop — rather than a summary. Hard limits should run before it, so orders that violate a cap are rejected outright rather than presented for review. Spending attention on decisions a function could have made is how approval fatigue sets in.
Do I need a separate session for research?
It is the single most effective control against prompt injection, and it costs nothing if you set it up that way. Anything the model reads sits in the same context as your instructions, so a session that fetches external pages should not also hold order-placement tools.