Support reports can reveal where the agent system becomes hard to understand

A support report begins with a user's expectation meeting an observed result. That mismatch can expose a fault in the agent, a confusing explanation, or an expectation the interface helped create. We propose treating support as a sensor for those distinctions, with a known sampling bias: people who write in are a selected part of the population.

DXAP already exposes a useful starting point. Its activity guide asks users to select a turn, read the decision and action details, and compare the outcome with Positions and Trades. A completed turn may have decided to wait. A submitted order requires an order-status check. Those distinctions let support identify the stage that confused the user instead of reducing every complaint to whether a trade occurred.

A quiet inbox can mean two things

Consider an illustrative comparison between two explanations of a rejected opening request. Version A says “Action failed.” Version B names the configured entry limit and directs the user to the saved setting. Suppose complaints fall from 20 to 10 across 100 affected turns in each version. That reduction alone supports several explanations: better understanding, lower willingness to ask, or an easier path to resolve the issue independently.

Add a small comprehension check to a separately recruited sample. Ask users whether the order reached the venue and which setting constrained the request. Record correct answers and unresolved confusion, with participation rates for both versions. If complaints decline while correct answers increase, the explanation has stronger evidence of usefulness. If both complaints and comprehension decline, silence is a poor success measure.

These numbers describe a study fixture, rather than product results. The same design could examine account readiness or missing market evidence. Keep the underlying agent decision unchanged during an explanation test so the intervention has a clear object.

Locate the mismatch before choosing the fix

Each consented report should preserve the user's expected outcome in their own words, the selected turn, and the stage where expectation diverged from the record. Then distinguish a visibility problem from a behavior problem. An order correctly rejected under a saved limit may need a clearer explanation. An action that passed despite violating the applicable limit needs an execution-path investigation.

Our controls paper companion describes a historical method that traced failures to their producing stage and evaluated harness revisions against replayed scenarios. That method motivates the proposed support study. It establishes neither a current support classifier nor automatic model updates from messages.

Support-derived cases also need a comparison set of affected turns without reports. Otherwise the most articulate users define the entire failure map. Sampling both groups can reveal defects that users struggle to describe, including failures that appear ordinary in the interface.

The useful sensor output is a prioritized collection of reproducible mismatches with estimated reach and severity. A drop in tickets is one observation. Better user understanding and fewer verified failures are separate outcomes, each worth measuring directly.