What a good morning report looks like

The promise of overnight agents is simple: queue work in the evening, review results at breakfast. The risk is just as simple: you come back to a wall of text, a dozen branches and no idea which of them you can trust.

We designed the Overnight Autopilot backwards from the report. If the morning doesn’t work, the night didn’t either.

#Rule 1: “ready” must be earned

Every task ends in one of two states: ready or needs you. Ready is strict:

• every required check passes,
• nothing regressed compared with the baseline measured before the night,
• the integrity scan found no warning — no deleted or skipped tests, no loosened configs.

Anything that misses one of these is “needs you”, with the reason attached. That means a ready task is one you can adopt after reading the diff, not one you have to investigate.

#Rule 2: numbers come from records

An agent’s final message often sounds confident: “All tests pass, the feature is complete.” The report never quotes that. Every number in it — checks passed, attempts used, tokens, files changed — comes from rows PaneScale recorded while the night ran.

#Rule 3: the report is frozen

When the queue finishes, the report is written as JSON to the folder you chose and doesn’t change afterwards. If you rerun a task, that is a new night with a new report. You can always compare what the autopilot claimed at 7:00 with what you see at 9:30.

#Rule 4: nothing is published

The night ends with branches and a report — never with pushed code or open pull requests. Publishing is a decision you make in the morning, with a signed one-time approval for each draft PR.

#Reviewing in ten minutes

With those rules in place, a review becomes a short routine:

1. Read the summary line. “3 ready, 1 needs you, 0 regressions.” If regressions isn’t zero, start there.
2. Adopt the ready ones. Open each diff, skim it, adopt. Every adoption takes a checkpoint first, so Undo adoption is there if you change your mind.
3. Read the reasons. For each “needs you”, the reason is usually specific: required check typecheck failed on attempt 3 or check config changed in package.json. Decide: requeue with a better task, finish it yourself, or discard.
4. Prepare drafts if you want them. Review what will be pushed, approve, done.

#What makes nights succeed

Looking back over many reports, the pattern is clear. Nights go well when tasks have a finish line, when the required checks are fast and reliable, and when each task is small enough for one or two attempts. They go badly when tasks are vague, checks are flaky, or one task is really five.

The report makes that visible the first morning. By the third, your evening queue looks different.