What the night shift is allowed to merge

Six weeks after the first night shift, Thandeka booked a meeting room for an hour with Pieter and Ayesha and put one question on the whiteboard: "If one of us leaves, how does the next person know what the agents are allowed to do?" The answer, at that point, was a set of rules that lived in three people's heads, a few Slack threads and the agent's instruction file. That worked while the three of them reviewed every pull request. It would not survive a holiday, a new hire or a busy December.

They spent the hour writing a charter. It fits on two pages. This final episode sets it out, with the reasoning behind each part, so that you can adapt it.

As throughout this series, Keurbooms Software is a fictional Plettenberg Bay company whose nine-person team runs Lagoonbook, a booking and payments platform for guesthouses and tour operators. Its people, code and figures are illustrative.

Why a charter and not just a prompt

The agent at Keurbooms already had detailed instructions. The temptation was to keep adding rules to them. The team decided against making the prompt the source of truth, for three reasons.

First, a prompt instructs the agent, but the charter governs people too: who queues tasks, who reviews, who can stop everything. Second, the most important rules must not depend on the agent following them. "Agents cannot merge" is enforced by repository permissions. "No deploys at night" is enforced by the pipeline. The prompt reflects those rules; it does not create them. Third, a charter can be reviewed and changed deliberately, with a date and a reason, which a sprawling prompt rarely is.

This mirrors the distinction in our guides, guards, checks and sensors framework: instructions guide the agent, but guards and checks have to live outside it. It is also what we mean when we say harness engineering has grown up from a few artefacts into a control system.

Part 1: task classes

The charter sorts work into three classes by consequence and reversibility, not by how difficult it looks.

The charter sorts work by consequence and reversibility, not by how hard it looks. Everything in the first column can be undone with one revert and checked by a test or telemetry. The third column is not banned forever; it simply needs people awake, a decision record and a staged release.

Allowed at night. Work that is small, reversible with one revert, owned by one person and checkable by a test or by telemetry. At Keurbooms: stale flag removal, dead code with telemetry proof, lint and type fixes, patch upgrades of direct dependencies with release notes read and no transitive dependency changes, and tests for existing behaviour.

Allowed with a named approver. Work the agent can prepare at night but which needs a specific person to approve in the morning, with extra evidence: minor upgrades and any upgrade that changes a transitive dependency, with a shadow run, refactors inside one module, performance fixes with a benchmark, additive API changes that do not change a schema, and documentation and runbook updates.

Never at night. Payments, money and rounding; dates and time zones; authentication, secrets and permissions; data migrations; new services or deployment units; major upgrades; and new dependencies. These are not banned. They need people awake, a decision record and a staged release. Parts 2 and 3 of this series are the reasons the list looks like this.

A task that does not fit any class is not queued. That rule matters more than the lists. New kinds of work start in the second or third class and move to a less restrictive class only on evidence.

Part 2: the task format and the evidence pack

Every night task is written in the same four-line shape: the one change to make, the boundary it may touch, the test or measure that proves it is done, and what the agent must not change. If a task cannot be written that way, it is not ready.

Every night pull request carries an evidence pack at the top, read before the diff: why the change is safe, the scope, the proof (tests and any shadow run), telemetry where relevant, how to undo it, for upgrades, the full list of transitive dependency changes with the agent flagging any release-note mention of defaults, rounding, locale, time zone or serialisation, and a run record of what the agent did, how long it took and what it cost. Part 1 describes the pack in detail. No evidence, no review.

Part 3: authority and budgets

The charter states who can do what, and the platform enforces it.

Agents can create branches, run tests and open pull requests. They have read-only access to aggregated telemetry, so they can show whether a code path is still used. They cannot merge, deploy, change pipeline configuration, read production secrets or access personal data. Background agents run against a test environment with synthetic or anonymised data.
Reviewers are the owners of the affected code. For the second task class, the approver is named on the task when it is queued.
Merge happens only in working hours, by a person, and deploys follow the normal release process. The night shift has no fast lane.
Budgets cap each night: a maximum number of tasks (Keurbooms uses eight), a maximum run time per task and a monthly spending limit on the agent service. When a budget is reached, the remaining tasks wait.

The point of the authority rules is not distrust of the agent. It is the same principle as our article on agentic development needing an acceptance authority: someone with context and accountability decides what enters the product. This is the acceptance matrix from that article applied to unattended work. That article accepts a written, approved policy as an acceptance authority for low-risk changes; Keurbooms chose not to use policy-based auto-merge at all during the first months. An automated review comment can help that person, but AI code review is a filter, not a sign-off.

Part 4: who wakes up, and the kill switch

The team was clear that the night shift must never create a reason to wake someone up. Because agents cannot merge or deploy, nothing they do at night can change production. If an agent run fails, it fails quietly and the failure is in the morning report.

There is one exception: the kill switch. Any engineer can pause all night work immediately with one command, without a meeting or an explanation. It is used when something looks wrong: an unexpected spike in agent spending, a pull request touching files outside its boundary, or a run that tried to access something it should not. The pause holds until the tech lead reviews the cause. In six weeks Keurbooms used it once, when an agent repeatedly retried a failing test environment and ran up its time budget. The cost was small; the habit of pausing first and investigating second was the point.

Part 5: measures

The team tracks four numbers weekly, per task class:

Accepted pull request rate. Merged, with or without revision, as a share of those opened.
Reverted pull request rate. Merged changes later reverted.
Median review time. How long a person spends deciding.
Escaped defects. Problems found after merge that the evidence pack should have caught.

High acceptance with low review time means a task class is well specified. Low acceptance means the instructions or the class are wrong. Any escaped defect gets a short written review: what the evidence missed and what changes in the task format or evidence pack. These are measures of the delivery system, not of the agent alone, in line with our view that coding agents are tools inside a delivery system.

The team deliberately does not count lines of code or the number of pull requests. A night that produces three good pull requests and closes two bad tasks is better than one that produces twelve that need careful reading.

Part 6: how the charter changes

A task class moves to a less restrictive class only on evidence: a high acceptance rate, few reverts and no escaped defects over a review period. One escaped defect moves a class back to a stricter class. The kill switch sits outside this loop and can stop all night work immediately.

The charter is reviewed monthly by the tech lead and the product owner. A task class moves to a less restrictive class, from approval to allowed, only on evidence: a high acceptance rate, few reverts and no escaped defects over the month. One escaped defect moves it back to a stricter class. Every change is recorded with the date and the reason, so that a new team member can see why a rule exists rather than guessing.

This also keeps the night shift from slowly growing in scope. Without a review, small additions accumulate until the agents are doing work nobody explicitly decided to give them. Cheap code makes that drift easier, which is the risk we describe in keeping systems fit when code is cheap.

The charter checklist

Adapt this to your own team. If you cannot tick an item, decide whether the gap matters before starting a night shift.

Key points

Write the rules as a charter that governs people and agents, not as an ever-growing prompt.
Sort tasks by consequence and reversibility. New kinds of work start in a stricter class and move to a less restrictive one only on evidence.
Enforce authority with permissions and pipelines: agents propose, people merge, nothing deploys at night.
Give any engineer a kill switch and use it without ceremony.
Measure accepted, reverted, review time and escaped defects per task class, and review the charter monthly.

Previous: Part 3, The overnight upgrade that passed every test. Start of the series: Part 1, Let the agents take the night shift. All parts are on the series page.

How CloudNala can help

CloudNala helps engineering teams write and run a night-shift charter for background coding agents. We work with you to define task classes, the task format and evidence pack, the permissions and budgets that enforce them, and the weekly measures and monthly review that let the agents' scope grow on evidence rather than on enthusiasm.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Talk to us about coding agents in your delivery pipeline or write to us at consult@cloudnala.co.za