diff --git a/atvm/AGENTS.md b/atvm/AGENTS.md
index 3f7e68c..f39009d 100644
--- a/atvm/AGENTS.md
+++ b/atvm/AGENTS.md
@@ -115,7 +115,9 @@ When the operator asks for run status, report in this order:
 
 Status details:
 - Use the same status display format for every ATVM automation status response regardless of template type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
+- Treat a status request as a request for live status by default.
 - Use the live run log on the automation VM when available.
+- If no automation is currently running, fall back to the most recent historical run artifacts and logs.
 - Use the run `build_name` as the heading/title when available.
 - Format every machine entry as `machine-name - STATUS`.
 - Put each machine on its own line; do not combine multiple machine statuses on one line.
@@ -130,6 +132,7 @@ Status details:
 - Include end time and total runtime for completed runs, or elapsed runtime for active runs.
 - Include quickest completed test runtime, longest completed test runtime, and average completed test runtime under timing details when they can be derived from the log.
 - Make the estimated completion time refer to the entire remaining run, not only the current machine/spec.
+- For categorized runs, reconstruct the status of the entire run across all category batches whether the run is still active or only historical artifacts remain.
 
 ### Automation Blacklist
 Always exclude these machines with `--exclude_partial_match` when building ATVM automation commands.
diff --git a/atvm/atvm-automation-guide.md b/atvm/atvm-automation-guide.md
index 9c4912f..e555ae2 100644
--- a/atvm/atvm-automation-guide.md
+++ b/atvm/atvm-automation-guide.md
@@ -161,12 +161,16 @@ When the operator asks for the status of an ATVM automation run, report in this
 
 Status-report expectations:
 - Use the same display layout for every ATVM automation status response regardless of test type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
+- Treat a status request as a request for live status by default.
 - Use the live automation VM state when available.
+- If no automation is currently running, fall back to the most recent historical run artifacts and logs.
 - Derive the heading/title from the run `build_name` when available.
 - Format every machine entry as `machine-name - STATUS`.
 - Put each machine on its own line; never combine multiple machines into one paragraph or comma-separated line.
 - Use a separate `Notes` section for failure reasons, anomalies, or operator-relevant context rather than cramming those details into the completed-machine list.
 - For categorized runs, reconstruct the whole run across all category batches; do not treat the current live category batch as the full run scope.
+- For categorized runs with no active automation, reconstruct the status from the full historical run across all category batches, not only the most recent category batch.
+- Always report the status of the entire requested run, even when the runner split execution into multiple category batches or cloud sub-runs.
 - Derive completed-machine status from completed spec results already written during the same run.
 - Parse all same-run `test-result-*.xml` files, not only machine-named `test-result-atvm*.xml` files.
 - When XML filenames are hash-named, extract the machine name from XML contents such as `testsuite file=`, `testsuite name=`, or `testcase name=`.
diff --git a/atvm/atvm-automation-runs.md b/atvm/atvm-automation-runs.md
index 4fa338b..a9e2a49 100644
--- a/atvm/atvm-automation-runs.md
+++ b/atvm/atvm-automation-runs.md
@@ -135,3 +135,13 @@ This file stores run-specific examples only when a run produced a new learning r
   - If the requested config file is missing, stop immediately and report the missing filename.
   - Do not search the automation VM for alternate config files.
   - Do not switch to another config unless the operator explicitly instructs it.
+
+## Run Learning: 2026-03-16 (Status requests default to live view with whole-run historical fallback)
+- Observed requirement:
+  - When the operator asks for ATVM automation run status, they want live status by default.
+  - If no automation is currently running, the status response must fall back to the most recent historical run.
+  - For categorized runs, the response must still cover the entire run rather than only the latest category batch or cloud sub-run.
+- Action for future runs:
+  - Treat every ATVM status request as a request for live run status unless the operator explicitly asks for something else.
+  - If no automation is active, reconstruct status from the most recent historical run artifacts and logs.
+  - For categorized runs, always aggregate all same-run category batches so the response covers the full run scope.