A signal is a proposal
The trading-agent prototype reads financial news, produces a signal, applies technical checks, and prepares a paper trade for review. The most important product boundary is between proposing the trade and approving it. Model output does not remove the need for that boundary.
This is a paper-trading experiment, not evidence of investment returns. Its value as an engineering project is the opportunity to make each step visible and to design the transition from recommendation to action deliberately.
Make the review possible
An approval button is only useful if the person beside it can understand the proposal. The saved dashboard screenshots expose model reasoning, technical checks, confidence information, and the pending review state. The reviewer should not have to reconstruct the recommendation from several unrelated screens.
I would evaluate that interface by asking someone to explain why a signal was proposed, which checks it passed, and what would happen if approved. If they cannot answer those questions from the interface, the system has moved the burden to the human without supporting the decision.
Controls need their own evidence
Risk limits and a kill switch express operating constraints. Their presence is not a performance result. The next evaluation should record when controls reject a proposal, why it was rejected, and whether repeated approval attempts can produce duplicate actions.
A repeatable paper-trading report and backtests are still needed before assessing signal quality. I would include rejected and expired proposals in that report rather than only successful executions. Otherwise the record leaves out the decisions where the controls mattered most.
The lesson
Treat approval as an interface and a state transition that deserves design attention. A useful agent gives a person the context to disagree with it and leaves a record that makes the action understandable later.