A final answer is not enough.
When an autonomous route runs for minutes or hours, the final output hides the operational questions that matter during execution. What is running? What authority does it have? Which dependency failed? Did an external side effect occur? What evidence supports completion? Without those answers, autonomy becomes difficult to trust and expensive to supervise.
Observability should compress, not overwhelm.
Exposing every token, log line, and tool call can create another form of opacity: too much information. Useful observability summarizes system state around decisions and intervention points. The operator should be able to see active objectives, route health, approvals, exceptions, evidence, and recovery status without becoming a full-time debugger.
Evidence belongs next to status.
A green indicator is meaningful only when the system can explain why it is green. Verification artifacts, source references, test results, diffs, and other evidence should travel with claims of completion. That makes machine work easier to audit and reduces the need to reconstruct what happened after the fact.
Observability changes autonomy itself.
Once state and evidence are visible, the system can support more nuanced authority. Low-risk work can proceed autonomously while exceptions escalate. Consequential actions can pause at approval gates. Failed routes can surface recovery options. Observability is therefore not decoration around autonomous execution; it is one of the mechanisms that makes autonomy governable.