An agent can propose work without having the authority to approve it. That distinction belongs in the system.
Name the states
Evidence, inference, proposal, approval, and execution should not collapse into one status. The person reviewing a proposal needs to see the source, the uncertainty, and the consequence of accepting it.
Sources
Comparable sales
Known gaps
Scope
Cost ranges
Uncertainty
Review the scope
Confirm the inputs
Own the decision
Bind approval to the proposal
Approval should refer to a concrete version with specific inputs and scope. If an input changes materially, the approved version should remain inspectable and the changed proposal should require a fresh decision.
Do useful work first
Gather evidence, calculate the result, prepare the artifact, and explain what will happen. Ask for approval when the person can evaluate a real consequence, rather than a vague intention.
Preserve the boundary
A model’s interpretation of a document is not authorization. A suggested renovation item is not confirmed scope. A forecast is not an actual payment. These distinctions are part of the data model and the workflow, not a disclaimer at the bottom of a screen.
When an approval boundary is explicit, the system can automate preparation aggressively while leaving the consequential decision in the right hands.