Introduction: From Harness Engineer to Loop Engineer

Some time ago, the idea of the "Harness Engineer" gained traction in quantitative trading circles. Its core principle is not to pick an answer based on intuition, but to build a framework in which multiple candidates can compete under a unified set of evaluation criteria. Applied to trading, this means placing multiple instruments, parameter sets, and rule systems into the same backtesting or evaluation framework, then using historical data and a shared objective function to identify the relatively better combination.

This approach solves a horizontal selection problem: at a given point in time, choose the best-performing option from a pool of candidates. It is effective, but it also has an inherent limitation: the selected answer is only the "relative optimum within the historical sample." Once that round is complete, the framework itself does not actually become smarter. Run it again, and it is still essentially repeating the same scoring logic.

But what if the real question is not "Which one should I choose?" but rather "How can the system continuously accumulate its own experience while it is running?"

That is the direction I have become more interested in recently. For now, we can call it Loop Engineer.

Instead of building a one-off scoring framework that ends after a single run, build a closed loop of "decision → execution → review → update," allowing every signal, trade, and outcome to become experience that can be reused in the next decision.

The "evolution" discussed here is not online training in the strict machine-learning sense, nor does it involve updating the weights of a large language model. More precisely, it is the continuous updating of an external experience base: the system writes trade reviews into a database, summarizes them into a playbook, and then lets the next round of decisions read from that playbook. The model itself is not retrained. What changes is the experience available at runtime and a limited set of adjustable parameters.

If Harness Engineer is concerned with "space"—comparing candidates horizontally within a search space—then Loop Engineer is more concerned with "time"—continuously recording, reviewing, and correcting decisions along the trading timeline. The engineer no longer gives the strategy its final answer directly. Instead, the engineer designs the skeleton of the loop, the evaluation criteria, and the safety boundaries, then lets the system gradually accumulate experience through repeated operation.

This article discusses a single-instrument AI self-evolving trading system built around that idea. It does not attempt to cover hundreds of cryptocurrencies at once. Instead, it focuses on one instrument—for example, a BTC, gold, or crude-oil perpetual contract—and treats "experience" as the core asset that actually changes while the system is running.

Why Use a Single Instrument for a Closed-Loop Experiment

Harness-style frameworks are naturally suited to casting a wide net: the larger the candidate pool, the more meaningful horizontal comparison becomes. The trade-off is that the information accumulated for each candidate is usually shallow. Each coin may only end up with a few backtest scores, which is not enough to constitute meaningful "individual experience."

The Loop Engineer approach works in the opposite direction. It is better suited to beginning with deep observation of a single instrument. The volatility profile, sensitivity to news, false-breakout patterns, and trend-continuation behavior of a given market often have their own distinctive character. These traits are easily averaged away when mixed into a horizontal comparison across hundreds of instruments. But if the system continuously observes and reviews the same instrument, it may repeatedly encounter those traits and eventually turn them into reusable rules.

Of course, this does not mean that a single instrument naturally makes it easier to learn stable patterns. Quite the opposite: the biggest problem with a single-instrument system is that samples accumulate slowly, statistical evidence remains weak, and the system is especially prone to mistaking short-term noise for a genuine pattern during its early stages. A more accurate statement is that a single instrument provides a consistent trading context in which to observe how closed-loop experience accumulates, but it does not automatically make that experience reliable.

That is why this system should initially be treated as something to observe and iterate on, rather than as a mature live-trading system.

Architecture Breakdown: One Closed Loop, Five Stages

The system operates through five stages: "perception → decision → execution → review → update." There are two primary information channels in the middle: technical data and news data. The technical side comes from indicator snapshots, while the news side comes from search and caching. Both are passed to the decision layer.

1. Perception Layer: Translating the Market into Structured Language

The system first calculates a set of technical indicators covering trend, momentum, volatility, and volume, including EMA, MACD, RSI, Bollinger Bands, ATR, and KDJ. Instead of sending a loose collection of numbers directly to the model, it assembles them into a structured snapshot:

            python
            
            
snapshot = {
    "price": price,
    "trend": {
        "ema_fast": ema_fast,
        "ema_slow": ema_slow,
        "macd_hist": hist,
        "macd_hist_rising": hist > hist_prev,
    },
    "momentum": {
        "rsi14": rsi_v,
        "kdj_k": k_v,
        "kdj_d": d_v,
    },
    "volatility": {
        "boll_upper": boll_upper,
        "boll_lower": boll_lower,
        "atr_pct": atr_v / price * 100,
    },
    "volume": {
        "vol_ratio_to_ma20": vol_ratio,
    },
}

The point of this step is not to make the model "mysteriously understand the market." It is to translate the market state into structured language that the model can process more easily. The current conditions of trend, momentum, volatility, and volume are all explicitly represented in separate fields.

The news layer retrieves instrument-related news through a search interface and stores deduplicated results in a cache. It does not generate trading signals directly. Instead, it provides the raw material for evaluating the news environment.

2. Decision Layer: Technicals and News Must at Least Not Contradict Each Other

The indicator snapshot, recent news, current position status, and the system's active playbook are packaged together and passed to the large language model. The model must output a structured trading signal containing the action, direction, confidence score, technical view, news view, and rationale.

One hard rule applies here: the system may not open or add to a position when the technical and news views conflict. If the news environment is clearly bearish while the technical indicators suggest going long, the model should return a hold or close action rather than forcing a new position.

The prompt explicitly includes constraints such as:

            python
            
            
"1. Only return open_long/open_short/add_long/add_short when technical_view "
"does not conflict with news_view (news_view is neutral/no_data, or its "
"direction is consistent with technical_view).",
"2. If news_view points in the opposite direction from technical_view, "
"action must be hold or close.",
"4. confidence must honestly reflect the level of certainty (0-100). "
"Do not habitually assign high scores; use a low score when conviction is weak.",

It is important to note that "no conflict" is only a necessary condition for opening a position, not a sufficient one. In other words, the absence of conflict between technicals and news does not mean the system must trade. The model still needs to determine whether the signal is strong enough, and then output open_long, open_short, or hold. The execution layer performs an additional check to ensure that confidence exceeds the required threshold.

            python
            
            
if action in ("open_long", "open_short") and not has_pos:
    if decision["confidence"] < min_conf:
        return
    open_position(store, decision, ticker, add_mode=False)

Therefore, a case in which "the news view is bullish, the technical view is neutral, and the final action is still hold" is fully consistent with the system design. It means that the news has a directional bias, but the technical side does not provide enough confirmation, so the system remains inactive.

3. Execution Layer: Parameters Come from the Playbook, but Hard Boundaries Remain

One difference between this system and a traditional fixed-parameter strategy is that execution parameters are not completely hard-coded into the strategy logic. Position size, stop-loss percentage, trailing-profit activation threshold, and trailing giveback threshold are read from the current version of the playbook whenever possible.

That does not mean the AI can change parameters arbitrarily. Initial values, upper and lower limits, maximum position size, maximum number of additions, leverage, and other boundaries are still defined manually. The playbook can only provide the current parameter values within those boundaries.

            python
            
            
def playbook_param(store, key, config_default, lo, hi):
    v = store.get("current_playbook", {}).get("params", {}).get(key, config_default)
    try:
        v = float(v)
    except Exception:
        v = config_default
    return clamp(v, lo, hi)

Each time the system executes a decision, it reads the current playbook:

            python
            
            
hard_stop_pct = playbook_param(
    store,
    "hard_stop_pct",
    HARD_STOP_PCT,
    HARD_STOP_PCT_MIN,
    HARD_STOP_PCT_MAX,
)

Position size is not a fixed percentage either. It is calculated as "base position size × confidence for the current decision." The lower the confidence, the smaller the actual position. Only when confidence is high does the position approach the upper limit implied by the base position size.

            python
            
            
base_pos_pct = playbook_param(
    store,
    "base_pos_pct",
    BASE_POS_PCT,
    BASE_POS_PCT_FLOOR,
    BASE_POS_PCT_CEIL,
)

size_pct = base_pos_pct * clamp(decision["confidence"] / 100.0, 0.4, 1.0)

The key is not to let the model decide everything, but to give the system a controllable entry point for parameter updates. The AI may suggest adjustments, but the final values used for execution must always be clipped by the code layer.

4. Review Layer: Experience Is Generated Only After a Complete Trade Ends

After each complete open-to-close trade, the system passes the full trade context to the large language model for review, including the entry rationale, direction, profit or loss, and reason for closing. The model must output a specific lesson in Chinese rather than a vague summary such as "execution error" or "bad market conditions."

A better lesson would look like this:

Going long after RSI exceeds 70 while the news environment is bearish can easily lead to getting trapped. Wait for a pullback or skip the trade.

The review result is stored in the database together with a classification of the mistake:

            python
            
            
schema = {
    "outcome": "win|loss|breakeven",
    "mistake_type": "none|chased_move|ignored_news_conflict|"
                    "stop_too_tight|stop_too_wide|overleveraged|held_too_long|other",
    "lesson": "",
    "tags": [""],
}

One point needs to be emphasized: a review does not happen immediately after every model decision. It only happens after the trade has actually ended. Opening a position only records the decision. The system cannot know whether the trade was a win, a loss, or roughly breakeven until the position has been closed.

5. Update Layer: Turning Recent Reviews into a New Playbook

Once enough review records have accumulated, or a fixed time window has elapsed, the system triggers a playbook update. It reads recent reviews, the overall win rate, and profit-and-loss statistics, then asks the large language model to generate a new experience manual containing updated do/avoid rules and suggested adjustments to selected parameters.

However, suggested parameters are not accepted unconditionally. Each one is clipped to manually defined safety limits:

            python
            
            
bounds = {
    "min_confidence": (MIN_CONFIDENCE_FLOOR, MIN_CONFIDENCE_CEIL),
    "base_pos_pct": (BASE_POS_PCT_FLOOR, BASE_POS_PCT_CEIL),
    "hard_stop_pct": (HARD_STOP_PCT_MIN, HARD_STOP_PCT_MAX),
    "trail_activate_pct": (TRAIL_ACTIVATE_PCT_MIN, TRAIL_ACTIVATE_PCT_MAX),
    "trail_giveback_pct": (TRAIL_GIVEBACK_PCT_MIN, TRAIL_GIVEBACK_PCT_MAX),
}

for k, (lo, hi) in bounds.items():
    if k in suggested:
        new_params[k] = round(clamp(float(suggested[k]), lo, hi), 4)

The clipped parameters and new rules are written back to the database and become the current playbook used by the next round of decisions.

This is the real meaning of "self-evolution" in this system: the model weights do not change, but the external experience base and adjustable parameters are updated during operation. The next time the model makes a decision, it sees the new playbook, which can lead it to exhibit different behavioral tendencies while running the same underlying code.

Evolution Does Not Mean Losing Control: Hard Constraints Inside the Loop

Giving a system the ability to update its own experience also introduces obvious risks. Without boundaries, several consecutive losing trades could cause the model to derive the wrong lessons and push the system toward even worse parameters.

That is why this design includes several layers of constraints.

First, the AI cannot modify the code. It can only fine-tune parameters within manually defined numeric ranges. For example, the stop-loss percentage may only move within a specified upper and lower bound. The range itself is controlled by code or platform settings, and the playbook cannot exceed it.

Second, hard stop-loss rules, the maximum position size for a single instrument, and the maximum number of position additions are enforced at the code level. These are separate from the soft parameters stored in the playbook. The latter may be updated; the former cannot be relaxed by the AI.

Third, a new position requires the technical and news views to at least not conflict. A single signal source cannot independently trigger a trade.

Fourth, the system can run in "notification-only" mode by default, allowing users to observe its signals, reviews, and playbook changes before enabling live order execution.

For example, the maximum single-instrument exposure and the maximum number of additions are checked directly in the execution layer:

            python
            
            
max_qty = equity * MAX_SINGLE_POS_PCT * LEVERAGE / ticker["Last"] / market["ctVal"]

if cur_qty + qty > max_qty:
    qty = max(0, max_qty - cur_qty)

if pos.get("add_count", 0) >= MAX_TOTAL_ADD_COUNT:
    return

The underlying principle is simple: the closed loop may adjust "how to do better," but it may not relax the bottom line of "how much risk it is allowed to take."

How Far Is It from a Truly Mature Continual-Learning System?

This needs to be stated clearly: the system is still a long way from a truly mature continual-learning system.

The core difference can be summarized in one sentence: a mature continual-learning system asks, "Does this new lesson still hold on data the system has never seen?" This closed loop, in its current form, mostly summarizes a limited number of trades that have already happened.

That does not mean the system has no value. Its value lies in structuring activities that are often performed manually in trading systems: recording, reviewing, summarizing, updating, and reusing experience. Previously, those lessons might have been scattered across personal notes, chat records, or subjective memory. Now they are written into a database-backed playbook and become context that the next decision can actually read.

But this also means the early stages require great caution. A lesson produced by the system may reflect a genuine pattern, or it may merely reflect short-term noise. Especially when dealing with a single instrument, low-frequency trading, and a thin sample size, no "evolutionary result" should be trusted too quickly.

Conclusion: The Value of the Loop Lies Not in Getting It Right Once, but in Observing It Continuously

What attracts me most about the Loop Engineer idea is not the promise that "the system will become more accurate the longer it runs." It is that it turns "getting better" from a process of manual parameter tuning and strategy redeployment into something that can be recorded, reviewed, and updated as part of the system's normal operation.

Of course, improvement does not happen automatically. The system may learn useful lessons, or it may learn noise. It may make parameters more robust, or it may drift in the wrong direction because the sample size is too small. A human still needs to observe every playbook update, check whether the rules are specific, whether the parameters are oscillating too aggressively, and whether the signals are becoming more reasonable.

For that reason, this system is better treated as a starting point for observation and iteration than as a finished product that can immediately be trusted with leveraged live trading. A more prudent approach is to run it in "notification-only" mode for a period of time, observe the quality of its signals, reviews, and playbook evolution, and only then decide whether to move into small-position live trading.

Building the loop is only the first step. Whether it can truly accumulate useful experience must ultimately be tested through enough time, enough trading samples, and strict risk controls.

This article is a technical discussion of strategy design ideas only and does not constitute investment advice. Cryptocurrency and other financial-derivatives trading involve substantial risk. Please carefully assess your own risk tolerance.

Strategy Source Code: AI Self-Evolving LOOP ENGINEER Trading System