NeoTrade adds agent memory updates while keeping capital controls outside the learning loop

NeoTrade’s Evolve update gives an agent a way to review previous runs and carry selected lessons into its next decision. Announced by NeoSoul on September 10, 2026, the feature changes what context the agent can consult. It creates a specific evaluation problem for developers: determine whether a memory change improves subsequent decisions while preserving the user’s authorization boundaries.

Start with the artifact Evolve actually changes

The release announcement describes reviewing past runs, retaining useful signals and writing them into memory. It provides no evidence that this feature retrains the underlying model on a user’s computer. A memory update is an inspectable artifact. A claim that the agent now understands markets better needs an additional test.

NeoSoul’s component documentation separates models, memory, playbooks, tools and harnesses. Memory carries context between tasks. Playbooks express repeatable procedures. The harness places those components inside a task, permission scope and evaluation process.

For an integration team, that distinction should shape acceptance criteria. Ask what changed, which runs supplied the evidence and where the new lesson applies. An entry derived from one market condition should not silently become a universal trading rule. Its scope and expiration need to be inspectable alongside its content.

This article evaluates the documented workflow. It does not report a hands-on performance test of Evolve.

Check current support before designing an integration

As checked on September 11, 2026, NeoTrade’s product documentation lists Paper, predict.fun and Polymarket as current environments. The desktop client supports macOS and Windows. Paper uses a simulated environment, so its results belong in a different evaluation category from live capital deployment.

The system status page lists broader exchange coverage and U.S. equities among planned markets. Parts of verifiable behavior and version-record infrastructure remain in development. Those labels matter when designing account connections, execution handling and audit requirements.

The official expansion diagram is a roadmap. It does not establish that every pictured market is available or that an agent’s behavior transfers across venues. A prediction market with a defined settlement event and a continuously traded asset present different evaluation problems.

The benchmark supplies a useful separation of responsibilities

RSI-Exam’s official leaderboard currently shows GPT-6-astra at 0.5126, GPT-5.6-sol at 0.4331 and GPT-5.5 at 0.3312. Astra’s mean is approximately 18.4% above Sol’s. That is a relative difference between normalized scores, not an increase of 18.4 percentage points in accuracy.

The 0.1 task bank contains 88 tasks: 35 public and 53 private. Public task availability is separate from the visible-versus-hidden data split inside a task. A public task can still reserve hidden data for evaluation.

The methodology report describes an agent submitting an executable method or harness for a sealed verifier to rerun on hidden data. The inherited baseline maps to zero; a valid upper bound maps to one where available. The initial report also specifies one rollout per model and task, which cannot estimate repeated-run variance within a model.

Evidence	What it establishes	What remains unproven
Evolve announcement	Previous runs can inform a memory update	Underlying model weights changed
RSI-Exam task bank	88 tasks, with 35 public and 53 private	Trading profitability
Astra versus Sol	0.5126 versus 0.4331 on the leaderboard	The same margin on every repeat run
NeoTrade current support	Paper, predict.fun and Polymarket	General availability across the roadmap

The useful lesson for NeoTrade integration is procedural. Generating a candidate change and accepting that change require different evidence. A persuasive explanation from the agent cannot substitute for evaluation on cases unavailable when it selected the update.

Preserve the decision before the outcome arrives

NeoSoul’s economic-decision data specification connects source timestamps, event definitions, assumptions, judgments, execution effects and outcomes. That structure supports error attribution. An outdated source, a badly calibrated forecast and a failed order can all produce disappointing results while requiring different fixes.

An implementation review can turn that principle into an explicit record contract. The following field names are a proposed integration design, not a claim about NeoTrade’s API. Give each run a unique run_id. Record model_version, memory_version, playbook_version and policy_version before execution. Keep observed_at separate from resolved_at so later knowledge cannot masquerade as information available at decision time.

Record the proposed action, authorization decision, submitted order and execution response separately. A recommendation is not a fill. A rejected order is not a deliberate decision to remain inactive. Preserve those distinctions when joining records for analysis.

The same record contract should cover runs that place no orders. Otherwise, evaluation excludes abstentions and cannot determine whether a candidate version merely increases activity. A higher count of successful trades may coexist with worse decisions or more failures elsewhere.

The archive also needs a retention policy. Keeping every raw artifact indefinitely creates storage and review costs. Deleting provenance while preserving a confident summary creates a different problem: nobody can audit the next memory update. Keep the evidence needed to reconstruct a decision and make access permissions explicit.

Keep the learner away from the permission boundary

NeoSoul’s risk-control documentation describes least privilege, user-defined capital limits, venue restrictions, action constraints and automatic pauses. These are stated design controls. An integration team still needs to establish that every execution path passes through them.

A practical architecture lets the agent propose a memory revision while a separate acceptance process decides whether to promote it. The order executor checks each action against the currently effective policy. It should not accept the model’s assertion that an action is authorized as proof of authorization.

One useful test supplies a candidate memory entry that requests a larger position without changing the account policy. The expected executor behavior is rejection of any action exceeding that policy, with a recorded reason. This is a proposed acceptance test, not a result from testing NeoTrade.

Also test what happens when a previously valid authorization is revoked between planning and execution. Versioned records should show which policy the executor used. Otherwise, a successful planning check can obscure an unauthorized later action.

The official controls diagram presents self-custody, deterministic controls and verifiable records as related product commitments. It should be read as an architectural claim requiring verification, rather than an audit certificate.

Promotion needs evidence beyond a good paper run

NeoSoul’s validation documentation specifies four stages: offline evaluation, Paper validation, constrained live execution, and audited outcomes with post-mortems. It also considers forecast quality, execution quality, rule compliance and generalization. Those categories supply a useful review structure without proving a particular update has passed them.

An evaluation design should freeze the current version and compare a candidate on a later period reserved in advance. Both versions need the same information cutoff. Settled answers must not enter the candidate’s memory before predictions are recorded. Data used to choose a winner should not also serve as the final acceptance sample.

Keep rejected tool calls, missing data and interrupted runs in the comparison. Removing operational failures produces a cleaner chart but changes the question being measured. The deployed service has to handle those failures, so the evaluation should preserve their cost.

Paper success leaves live execution unresolved. Liquidity, latency, fees and slippage can absorb a forecasting advantage. The service also pays for inference, data access, retained records and human exception handling. Trading profit alone does not describe the cost of running the agent.

Consider an illustrative group of resolved events assigned a 70% probability. Calibration asks whether the event occurs roughly that often across an appropriate sample. One failed forecast does not invalidate the probability. Correlated events also do not supply the same evidence as independent observations. This example is explanatory, not a reported NeoTrade result.

The public material reviewed for this article does not establish sustained Evolve gains in an independent live comparison after costs. Keep that gap visible in an adoption review. A large agent count or prediction count cannot fill it without definitions, sampling details and the results being measured.

Frequently asked questions

Does Evolve retrain the underlying model?

The September 10 announcement describes reviewing runs and updating memory. It does not establish model retraining. NeoSoul’s broader RSI documentation discusses changes across several system components, which should not all be attributed to this particular feature.

Is the RSI-Exam score an accuracy percentage?

No. The leaderboard reports mean normalized hidden-set scores derived from task-specific metrics and anchors. A score of 0.5126 does not mean 51.26% of questions were answered correctly, and it says nothing directly about trading returns.

Which markets does NeoTrade currently support?

The documentation lists Paper, predict.fun and Polymarket. Broader exchange and asset coverage remains planned. Confirm support for the relevant product version before building an integration around a roadmap item.

What should a development team validate first?

Require traceable memory versions and an evaluation on data excluded from update selection. Test execution permissions separately, including rejection, revocation and recovery. A successful simulated run still requires a separate assessment of live execution costs.

Authority Sources

• NeoTrade product landing page: product positioning and official workflow diagrams.
• Models, memory and playbooks: the roles of agent components.
• NeoTrade product documentation and system status: current support and planned capabilities.
• RSI-Exam leaderboard and methodology: scores, task splits and evaluation limits.
• Economic-decision data, risk controls and validation: evidence, boundaries and acceptance stages.
• Constrained recursive self-improvement: the broader system update process.

Author Insight

I would put Evolve in the process that proposes candidate versions and require a separate process to approve them. That keeps a rollback target and an evidence trail for every promoted memory change. If a team can show a better retrospective but no comparison on unseen cases, the adoption case is still incomplete.