🌙 Night Orders Sleep through the fixes you authorized. Wake up for everything else.
💡 Inspiration
An on-call engineer should not have to choose between approving every incident at 3 a.m. and giving an AI agent permanent access to production.
Night Orders asks a smaller question: what may the agent do tonight, while its owner sleeps? The person holding the pager grants a few precise permissions before bed. The agent can decline when an incident does not fit. Those permissions expire the next morning.
🛠️ What it does
Night Orders gives on-call automation a nightly permission boundary.
Before bed, a GitLab Duo flow drafts up to three orders as a merge request. Each pairs a measurable condition with one reversible action. The on-call engineer reviews and signs them.
During the night, code checks the signature, expiry, traffic volume and numerical condition. The watch flow must identify a signed order that fits the incident or decline. The model cannot invent or expand an action. Anything outside the boundary requires a person.
After an action, recovery checks examine the whole shop, not just the checkout path that was switched off. At 07:00, authority to make new changes expires. A morning countersign determines what stays and what is restored.
Incident memory connects alerts to evidence, decisions, approvals, actions and recovery checks. The next shift inherits that history, not permission to act.
⚙️ How we built it
Python and FastAPI power the relay and deterministic decision code. Three custom GitLab Duo Agent Platform flows handle dusk, watch and dawn. GitLab merge requests, incidents and feature flags provide the operational record.
GitLab CI/CD validates policies and flow definitions, runs tests and browser checks, scans code and dependencies, and publishes the demonstration through GitLab Pages.
The browser story runs the actual decision code against a simulated shop. A separate execution explorer shows recorded real Duo sessions, tool calls and GitLab artifacts.
🧩 Challenges we ran into
A threshold crossing does not prove a fix is appropriate. Both checkout paths might fail while an order only covers the new checkout. The model checks whether the evidence fits; code independently enforces permission.
Recovery can also be misleading. Turning off a failing path can make its error rate look like zero without fixing the shop. We check the whole service and require enough traffic to support the result.
🏆 Accomplishments
Two Duo flows have executed on GitLab. Watch declined an incident because no orders were signed. Dusk inspected the repository and created an orders merge request containing zero orders because no verified production change justified an action.
All three flows are installed. The project has passing GitLab CI, and its documented application test run includes 639 tests with 94% coverage. A permission-boundary explorer exposes 23 refusal cases and a valid control, evaluated by the decision code.
The browser demo is explicitly simulated and uses recorded model replies. The relay is not deployed, no real overnight feature flag change has run, and dawn has not executed live. We do not claim measured production impact.
📚 What we learned
Investigating, authorizing, acting and verifying recovery are separate responsibilities. Human approval is not proof that a fix worked. Yesterday’s successful action is not permission to repeat it tonight.
🚀 What’s next
Deploy the relay, run a controlled live test night and morning countersign, and measure whether the workflow reduces unnecessary interruptions without hiding incidents. Expand the action menu only when each action has explicit permission, recovery and restoration checks.
Log in or sign up for Devpost to join the conversation.