Onboarding questions expose ambiguity in a trading mandate

An onboarding question is useful when its answer changes an agent's mandate in a way the owner can inspect. It becomes a research instrument when repeated uncertainty reveals a missing distinction in the product. We propose studying those distinctions before treating abandoned setup as a demand problem.

DXAP's creation guide describes Guided setup through four short questions and a starting proposal, alongside a Custom path. Both lead to Review and launch. The owner can refine a draft, save card changes, or start the agent. This creates a visible place to check whether a general intention became a specific configuration.

One phrase, two possible configurations

Take the illustrative request “Keep each trade small.” One person means a small amount of margin; another means a small total exposure. A setup question that merely asks whether the person prefers small or large trades preserves the ambiguity. A better question identifies the quantity and unit the resulting card uses.

The settings reference distinguishes configured policy fields from strategy text. The creation guide tells users to set enforced limits through actual settings. That separation matters: a sentence about caution and a saved entry limit play different roles in the decision path.

The study should avoid turning this observation into suggested trading settings. Present hypothetical cards and ask which quantity the limit controls. A user can understand the field without being asked to choose a financial exposure for a live account.

For example, show an illustrative card with a $100 entry-notional limit and ask whether it describes total opening exposure, deposited funds, or a guaranteed loss ceiling. Review the explanation against the documented field semantics. The important outcome is comprehension of the configured boundary, rather than agreement with the example value.

Find the question that removes the ambiguity

Recruit participants who have yet to launch and ask them to translate the same written intent through two candidate question wordings. Freeze the rest of the builder. Compare the resulting card with the participant's explanation of what it will permit. This reveals whether the interface produces a confident mismatch between intended and configured behavior.

Record how often participants revise their answer at Review and launch. A revision can be a healthy result of a clearer review card. Treating every revision as friction would reward a smooth path to misunderstood settings. Ask what changed their understanding, and classify the specific field or phrase responsible.

Our proposed measurement contract separates question completion, field comprehension, and mandate consistency. Launch rate is a later outcome influenced by funding, access, and willingness to run an agent. It should be reported alongside those constraints rather than used as a substitute for understanding.

The useful product change may be small: a unit beside an input, a clearer comparison in the review card, or a question that asks when the agent should wait. Each change can be evaluated on saved draft cases before its effects on live behavior are studied. Onboarding then becomes a way to discover what owners mean, with the approved card preserving the decision they made.