Improve the agent while keeping the owner control contract fixed

A feedback-driven release should improve how an agent carries out the owner's direction while preserving who can change that direction. We propose a semantic contract review that sits beside behavioral evaluation. Its question is simple: does the candidate retain the same relationship between discussion, approved instructions, policy fields, and trading authorization?

The public DXAP chat guide describes these relationships directly. Chat can explore decisions and propose settings changes. The owner reviews and confirms a persistent instruction before it becomes active. Strategy context remains separate from configured trading policies and account authorization. The policy reference describes checks applied before an order reaches the venue.

Evaluate the permission transition

Imagine an illustrative feedback report: “The agent keeps asking me to confirm the same preference.” A candidate makes the conversation smoother by remembering the preference. That can be useful. If it also starts treating future discussion as permission to change entry limits, it has changed the control contract.

Our proposed review compares transitions rather than button labels. A discussion should produce a discussion record or a proposal. An owner confirmation should activate the specified instruction or settings change. A rejected or expired proposal should leave active configuration unchanged. A trading request should still encounter account authorization and the relevant policy checks. Evaluate those transitions against the same authenticated owner events for incumbent and candidate.

The October 3 release notes give a concrete boundary for memory: saved discussion context remains separate from strategy and settings. A candidate can use memory to avoid asking an owner to repeat an explanatory preference. It should still require the documented approval when the requested change affects strategy or settings. The distinction belongs in the expected outcomes of the release test.

A four-scene contract review

We would build an illustrative test sequence in which an owner discusses a larger entry limit, rejects the resulting proposal, later confirms a different limit, and then corrects a remembered preference. After the first discussion, the saved limit stays unchanged. After rejection, it remains unchanged. After the later confirmation, only the approved value becomes active. Correcting the remembered preference affects the relevant context while preserving that approved limit.

Record the active instruction version and policy fields after each scene, alongside the candidate's statements. A reassuring explanation with an unauthorized saved change fails the test. A correct configuration with an inaccurate claim that approval already occurred also creates a failure, because the owner relies on the conversation to understand state.

The release decision should report behavioral gains and contract results separately. A candidate that improves factual explanations but introduces a permission transition error remains a development candidate. A change that intentionally adds a new owner capability would need its own explicit product and authorization review, rather than entering through a learning release described as equivalent.

This proposed method gives the feedback loop a durable boundary. User contributions can improve recall, explanations, and decision support; evaluation can identify which advances deserve a release. The owner still controls the confirmed mandate and configured limits. Keeping that contract legible is part of making repeated improvements usable, because each new version remains understandable to the person whose account it serves.