Operations and Supervision of Autonomous AI Agents in GitHub-Driven SDLC Workflows
The supervision surface
In a GitHub-driven SDLC, an agent's blast radius is defined by what it can touch: a branch, a pull request, an issue, a workflow run. Supervision means deciding before the run which of those the agent may write to and which require a human. The dominant pattern is: the agent works on a short-lived branch, opens a draft pull request, and a human promotes it to ready-for-review. The PR then becomes the single audit surface - diff, checks, conversation, and approval all live in one place, which is exactly what a supervisor needs to reconstruct what happened.
Name your autonomy levels
Write them into runbooks: propose-only (agent comments a plan), assisted (agent writes code to a branch, human merges), supervised-auto (agent merges after required checks), autonomous (agent merges and deploys behind progressive rollout). Promotions between levels should be justified by evaluation evidence, not by enthusiasm.
Watching a run
A supervisor needs four things per run: a durable log, a timeout, a cancel path, and an escalation path. If a session dies mid-task, the work must be recoverable from branch and PR state - never from the model's memory of the conversation.
Traps
- Treating "the agent opened a PR" as "the change is reviewed".
- Assuming the agent stops when the chat ends; scheduled workflows and event triggers keep it running.
- Conflating green CI with correctness - passing checks prove the tests you have, not the tests you need.
- Letting an agent approve or merge its own pull request.
Rule of thumb
Agent output is a proposal, not a change. Nothing reaches a protected branch except through a PR satisfying exactly the same required checks, CODEOWNERS review, and approval gates as a human-authored one - and any exception must be a named, time-boxed policy decision, never a default.