Upgrading an AI‑Native MQL5 EA: Nemotron, Order Flow Proxies and Asymmetric Consensus
Introduction: why this update matters
A mature Expert Advisor is not defined only by its entry logic. In a production environment, the real difference comes from how the system manages model selection, prompt quality, confidence calibration, risk context, and decision authority. When an EA begins to rely on AI for trade orchestration, the architecture must evolve beyond a single static model call and a fixed prompt template.
This is exactly the point reached by VANTH. The latest development cycle is not a cosmetic refactor, but a structural upgrade of the AI layer: higher token budgets for reasoning models, model-specific temperature control, explicit support for new Nemotron variants, order-flow context in the AIRequest, a regime-edge memory signal, and a more intelligent consensus mechanism between orchestrator and validator.
The objective is simple: improve decision quality without increasing noise. In an AI-native EA, every added field must justify its existence. If a signal is weak, mostly empty, or semantically redundant, it should not be pushed into the prompt just because it can be computed. The new architecture follows a strict rule: add only what changes the decision.
From static prompts to model-aware execution
One of the most common mistakes in AI-assisted trading systems is to treat all models as if they behaved the same way. In practice, this is not true. Some models are optimized for deterministic instruction following, others for reasoning depth, and others for broader orchestration with longer internal chains of thought. A single fixed max_tokens value and a single temperature setting are often acceptable for a simple classification task, but they become fragile when the model must generate reasoning before returning a structured JSON decision.
This is particularly relevant for OpenRouter-native reasoning models such as the Nemotron family. A large reasoning model can easily spend a meaningful part of its output budget on internal analysis before producing the final object. If the budget is too small, the JSON can be truncated, and the EA will fail to parse the response correctly. In an execution system, that means the difference between a valid trade decision and a silent fallback to WAIT.
The upgrade solves this by making token and temperature policy model-aware. Instead of hard-coding one universal value, the AI engine can now assign a dedicated budget and an appropriate sampling profile per model class. That gives the reasoning model enough room to think while keeping the final structured answer intact.
Nemotron as a first-class model family
A serious AI-native EA should not treat every new model as a temporary exception. If a model becomes part of the operational stack, it must be represented cleanly in the type system, in the provider routing layer, and in the model-to-slug mapping logic. That is why the new Nemotron variants are introduced as first-class enum entries rather than as ad hoc strings hidden inside configuration files.
This approach has three benefits. First, it keeps the code self-documenting: the model name in the enum communicates role and expectation directly. Second, it reduces routing mistakes, because provider selection and string mapping remain centralized. Third, it allows different operational roles to be assigned to different models, such as using one model as orchestrator and another as validator.
The practical implication is important. A model like Nemotron Ultra can be used as the main reasoning orchestrator, while Nemotron Super can be used as a faster validator. That division of labor is far more robust than asking two different models to co-decide the trade in a symmetric way.
Dynamic tokens and temperature
The next improvement is deceptively small but highly impactful: max_tokens and temperature are now computed per model. This matters because reasoning models do not behave like standard deterministic chat models.
For example, a large model used for orchestration may benefit from a much larger output budget than a compact validator model. If the output budget is too low, the model may produce a detailed preamble but fail to finish the final JSON object. Conversely, if the temperature is too low for a model that relies on exploratory reasoning, output quality can degrade because the model is forced into overly conservative sampling.
The correct engineering response is not to tune once and hope for the best. It is to formalize the model policy in code. The EA can then assign a higher token ceiling to the orchestrator model and a slightly warmer temperature to the reasoning-oriented validator, while preserving the existing deterministic settings for traditional models. This keeps backward compatibility while allowing modern reasoning models to operate correctly.
Order flow without overengineering
Many retail EAs fail because they try to ignore auction context entirely. Others fail because they attempt to add too much microstructure complexity without a proper data foundation. The right approach is in the middle: add only the order-flow proxies that are robust enough to be useful and cheap enough to maintain.
The new AIRequest design follows this principle. Instead of pretending to have full footprint or DOM infrastructure where it does not exist, it uses lightweight proxies derived from bar volume and candle direction. That means the EA can still express useful auction information such as directional pressure, imbalance, and possible absorption, without overclaiming precision.
The fields are intentionally simple: a slope of cumulative directional pressure, current-bar delta, three-bar delta context, imbalance side, and a coarse absorption score. These are enough to tell the model whether the current move is being supported or rejected by recent activity. They are not enough to replace a dedicated volume profile or tick-true footprint system, and that limitation is correctly acknowledged in the design.
This is a critical distinction. In a trading system, a proxy that is honest about its limits is better than a “rich” field that is always noisy.
Why suppress empty context
A major rule in the new architecture is that zero-data sections should not be emitted into the prompt. This is not only about token savings. It is about model attention.
If a section is present on every candle but contains mostly zeros, the model learns to treat that section as background noise. Over time, the prompt becomes larger but not more informative. The correct behavior is therefore conditional emission: if there is no meaningful order-flow signal, the section should be omitted entirely.
This makes the prompt cleaner and improves the information density of the remaining sections. The same principle applies to any future extension: if the EA cannot populate a field with meaningful signal quality, the field should remain out of the prompt rather than filled with placeholder values.
Regime edge as a trading signal
One of the most valuable upgrades in this development cycle is the transformation of historical memory into an active decision signal. Many systems already track performance by regime, but they leave that data buried inside summaries. The AI sees it as text, but not as a clear instruction.
The new regime-edge concept changes this. Instead of merely exposing a large historical block, the memory layer now produces a short, focused line describing how the current regime has historically performed. That line can be read immediately by the decision engine and used as an explicit weight in the entry decision.
This is especially important because market regime matters more than many traders admit. A setup that works well in a trending environment may be structurally weak in a ranging one, and vice versa. If the current regime has a negative expectancy, the AI should not need to rediscover that fact from scratch on every trade. It should be able to read it directly from memory and elevate the threshold for entry.
The logic is straightforward: positive edge means trade normally, marginal edge means require stronger confluence, negative edge means stand aside unless the setup is exceptional, and sparse sample means no special adjustment. This converts memory from a passive archive into an active policy input.
Why the consensus model needed a redesign
A second important change concerns consensus. A symmetric consensus architecture is convenient, but it is not always correct. If two models are treated as equals, the system tends to collapse into the most conservative common denominator. That can be acceptable in some contexts, but it is not ideal when one model is clearly the orchestrator and the second one is acting as a validator.
The new asymmetric consensus pattern is a better fit for production trading. In this design, the primary model owns the decision. The secondary model acts as a validator, not as a co-author. If the secondary model mildly disagrees, the primary decision can survive with reduced confidence. If the secondary model strongly disagrees and is more confident in the opposite direction, the decision can be vetoed and converted into WAIT.
This is a much more realistic control architecture. It reflects how institutional systems often operate: one component proposes, another component validates, and only strong disagreement blocks execution. The advantage is that the validator can catch obvious mistakes without forcing every minor disagreement into paralysis.
Why this is better than symmetric consensus
Symmetric consensus is safe, but it can be too blunt. It treats disagreement as a binary event and often discards useful nuance. In a trading environment, nuance matters. A mild disagreement between two competent models does not necessarily mean the setup is invalid. It may simply mean the confidence should be reduced.
Asymmetric consensus preserves that nuance. The orchestrator remains responsible for the overall reasoning chain, while the validator contributes a quality-control layer. This architecture is especially suitable when one model is optimized for deeper reasoning and the second for faster confirmation. The result is a cleaner decision hierarchy and a more transparent operational logic.
Architectural principle: add signal, remove noise
The broader lesson in this update is that AI-native trading systems should evolve like good research systems, not like feature dumps. Each added field, each new model, and each new prompt section must earn its place. If the field is noisy, zero most of the time, or impossible to interpret reliably, it should not be added just because it is fashionable.
The architecture therefore follows four principles. First, compute only what can be justified by the available data. Second, emit only what can influence a decision. Third, assign clear roles to models rather than making them compete blindly. Fourth, keep the final output structured and parsable, because execution systems need certainty more than verbosity.
This is why the update matters technically. It does not simply make the EA “smarter”. It makes the AI layer more disciplined, more modular, and more compatible with production trading constraints.
Development roadmap
This update also defines a useful roadmap for the next stage of VANTH. The natural continuation is to improve the quality and granularity of context without inflating prompt size. That means better signal selection, better regime classification, and more precise confidence calibration. If future work introduces richer auction data, it should still respect the same principle: only add fields that are compact, meaningful, and stable enough to improve decisions.
The next logical expansion is not “more AI”. It is better AI governance. That includes stronger role separation between orchestrator and validator, more careful memory weighting, and tighter logic for when a signal should be allowed to survive in a historically weak regime.
Conclusion
This development cycle is a good example of how an AI-native MQL5 EA should evolve. The goal is not to pile on features. The goal is to refine the decision architecture so that the EA can reason with more context, more discipline, and less noise.
By introducing model-aware token and temperature control, first-class Nemotron routing, lightweight order-flow proxies, regime-edge memory, and asymmetric consensus, VANTH moves closer to a true production-grade agentic system. The result is not just a more advanced EA, but a more coherent engineering framework for future development.
