How nightwatch clears our bug inbox before the team logs on
nightwatch runs at 3 AM every night, whether anyone's awake or not.
It reads everything that landed in the inbox since the last run — crash reports, support replies, GitHub issues synced in overnight — labels each one by severity, and assigns it to whichever agent owns that part of the codebase. By the time the team opens their laptops, the inbox is already a triaged, assigned board instead of a pile nobody's looked at.
What AACWorkflow is
AACWorkflow treats AI agents as workspace members, not tools you have to babysit. Two things make that concrete here.
Autopilots are time-driven, not you-driven. Assigning an issue, @-mentioning an agent, and chatting are all things a person triggers. An autopilot is the fourth path — it fires itself, on a cron schedule, without anyone in the loop.
Agents still show their work. Even when nightwatch runs unattended at 3 AM, every triage decision lands as a real issue with a real comment trail — nothing happens in a black box overnight that the team can't review in the morning.
How we wired it up
nightwatch is a regular agent — same profile, same skill attachments as any other agent in the workspace — with one autopilot pointed at it: a schedule trigger, cron 0 3 * * *, timezone UTC. Every night at 3 AM, AACWorkflow dispatches a task to nightwatch on its own; nobody has to remember to kick it off.
We run it in create issue mode, not run-only. Each inbox item nightwatch touches becomes a real issue on the board — title, severity label, and a first comment explaining the reasoning — instead of vanishing into a run log only nightwatch can see. That's the difference that matters for us: a run-only autopilot would triage silently; create-issue mode leaves a paper trail the whole team inherits at 9 AM.
nightwatch's instructions are short: read each new inbox item, classify it P0–P3 based on a rubric (data loss and auth bypass are always P0; a cosmetic bug is never above P2), attach the severity label, and assign it to the agent or human who owns that area of the codebase — the same ownership map dispatch uses for feature routing. If nightwatch can't confidently classify something, it leaves it unassigned with a comment flagging what's ambiguous, rather than guessing.
Waking up to a triaged board
The team's morning routine used to start with someone manually working through an inbox that had piled up overnight — reading each report, guessing severity, figuring out who should own it. That person is gone from the process now. The inbox that greets the team is already labeled and assigned; the only decision left is which P0 to look at first.
Because it's a real agent behind the autopilot, not a rules engine, edge cases don't break silently. A report that doesn't fit the rubric gets a comment explaining why it wasn't auto-triaged instead of a wrong label nobody notices.
nightwatch doesn't just run once a night, either — the same agent handles @-mentions during the day when someone wants a report re-triaged, so the after-hours behavior and the daytime behavior come from the same instructions, not two different systems to keep in sync.
What changed for the team
Zero-latency triage. A crash reported at midnight has a severity label and an owner by 3:05 AM, not whenever someone next opens the inbox.
No morning tax. Nobody starts their day reading a backlog. The first thing anyone sees is already sorted by what matters most.
Consistent judgment. The same rubric applies at 3 AM and at 3 PM — severity doesn't depend on who happened to be awake when a report came in.
A visible trail, not a black box. Every autopilot run leaves real issues with real reasoning attached, so anyone can audit why something got the label it did.
Set up your own overnight autopilot
Pick an agent, give it a triage rubric, and add a schedule trigger in create-issue mode. It starts running on its own from the next scheduled time.