AI in trading strategy management: which decisions can be automated

Suppose you ask an assistant to investigate why a strategy has been slipping into drawdown more often. It studies the report, changes the entry rules and produces an impressive backtest. But it also increases the position size. The metric has improved, yet the task itself has changed without your decision.

The problem starts with the word “improve.” It says nothing about what may be changed, how much risk is acceptable or when to stop. When working on a trading strategy, it helps to define permissions in advance: analysing, preparing changes, carrying out agreed work and asking for a new decision. Here is one way to organise that work. These are recommendations, not a description of a released EasyTrading AI controller.

What you can delegate without constant supervision

Start with tasks whose results you can check before changing the strategy. An assistant can collect compilation errors, compare reports, identify drawdown periods and prepare a list of differences between versions. It needs access to the relevant tools and a clearly defined data source. The model’s output is still an explanation that needs to be checked against the program’s results.

The next step is a bounded research task. For example, test a few preselected parameter values in a copy of the project. A person sets the range, test conditions and completion criterion. The assistant runs the agreed series without switching to a new market, a different commission rate or a more convenient period along the way.

The public description of XTester MCP lists working with strategy files, compiling, running a backtest and retrieving trades and metrics. These capabilities provide a basis for delegating routine research work. Having the tools does not, by itself, define which decisions the user has authorised the agent to make.

Instead of confirming every identical run, you can approve a batch of work. Specify the project, permitted changes, number of attempts or another limit on the work, and a stopping condition. Going beyond those boundaries requires fresh approval.

Where a task ends and a new decision begins

It helps to define permissions in terms of an action’s consequences. Reading a report and increasing risk may take equally short requests, but they need different controls.

Action	A reasonable permission boundary
Read reports and explain the differences	Allow within the selected project
Run an agreed series of tests	Allow up to the set limit, without changing the conditions
Prepare a new code version	Work in a separate copy or branch
Replace the accepted strategy version	Show the changes and request confirmation
Change leverage, position size or risk limits	Obtain a separate human decision
Approve a strategy for live execution	Agree this separately from the research task

This is a proposed framework, not a table of existing EasyTrading settings.

It is especially important to separate a recommendation from its application. An assistant may suggest increasing position size or removing a protective condition. It should present the proposal together with the reason, the change in risk and the alternative: what happens if nothing changes. A higher backtest return does not authorise the assistant to make that replacement on its own.

Confirmation also needs to be specific. “Continue” after reviewing a report can easily be interpreted too broadly. Agree on a particular version and action instead: save a variant for the next check, replace the research copy or prepare execution parameters. If the code changes after approval, permission for the earlier version should not automatically carry over to the new one.

What a clear assignment looks like

Return to the drawdown example. Instead of asking the assistant to “fix the strategy,” you could give it this assignment:

Analyse the drawdown in the selected version. First show which trades contributed the most and propose an explanation. Do not change the working version. Once the hypothesis is approved, prepare a separate variant and test it over the same range with the same costs. Do not change position size, leverage or protective limits. When finished, show the differences and stop.

This is an illustrative example, not a command from the product documentation. It sets out a sequence of decisions: understand the problem first, then choose a hypothesis, then authorise an experiment. The assistant has room to analyse, but no permission to redefine the research goal.

It also helps to decide in advance what should happen when something goes wrong. If historical data is missing, a test fails or a proposed change would exceed the permitted scope, the agent should report it. It must not extend the period, substitute a data source or relax a constraint on its own just to finish the report.

A language model may not be needed at all for a routine check against predefined conditions. Ordinary code can compare a metric with a set threshold. AI is more useful for formulating a hypothesis, explaining differences or preparing a change to test. Hard limits are better enforced by the execution system than by a request in chat alone.

Manual control must remain usable

A “stop assistant” button is not enough if it is unclear what stops with it. In research, you need to distinguish between stopping new tasks, cancelling a calculation already in progress and keeping changes already made. Test this on a copy of the project with the specific application and client you intend to use before starting a long session.

The XTester MCP security documentation explicitly warns that approval enforcement cannot be considered verified without testing the particular client and host. The assignment states a rule, but does not replace a technical restriction. If the tools cannot enforce the permission limits, it is more sensible to let the agent prepare proposals and apply them manually.

In live trading, stopping new actions, cancelling open orders and closing a position are separate operations. Each has its own consequences. A manual intervention plan should name the required action and explain how to check the account state afterwards. Ending the conversation with the model does not, by itself, confirm any of this.

XTester’s public MCP interface is not advertised as a channel for live trading. Permission to research a strategy must not be treated as permission to manage an account. After a stop or an error, it is also better to agree explicitly on how work will resume: from which version, under which limits and towards which result.

Before giving the assistant its next task, write down four things: what it may read, what it may change, when it must ask and how you will stop the work. If the answers are vague, it is too early to expand automation. Make the boundaries verifiable first. This does not guarantee a profit or rule out losses, but it lets you identify which decision the person made and exactly what the tool carried out.