Unattended agent runs — bounded recurring work
An unattended agent run is appropriate for a narrow, recurring, reversible task whose inputs, permissions, checks, and stop conditions are already understood. Scheduling adds no maturity by itself. The strong pattern curates low-risk work, limits dispatch and repair attempts, retains evidence, exposes incomplete runs, and requires review before merge or any consequential external action.
Q15 · Parallelism at team scale Max-score evidence: a curated low-risk backlog, bounded attempts, retained evidence, and mandatory review before merge or external action.
Define eligible work
Section titled “Define eligible work”Good candidates are deterministic maintenance tasks with established tests, such as a narrow dependency update, documentation synchronization, generated-client refresh, or a well-specified lint repair. Exclude auth, payments, migrations, production configuration, sensitive data, broad refactors, and tasks whose specification lives only in a person’s head.
- Curate the trigger. A named owner accepts the task class and input; untrusted issue or comment text is data, not authority.
- Bound execution. Use an isolated checkout, narrow credentials, allowed paths, time and cost budget, diff-size limit, and maximum repair attempts.
- Produce a draft artifact. Link accepted intent and include diff, commands, test results, residual risk, and rollback notes.
- Stop visibly. Ambiguity, permission boundary, repeated failure, elevated risk, missing test, or unavailable dependency creates a handoff—not improvised scope.
- Review before action. CI verifies mechanically; a named human decides merge and any downstream release or communication.
Prompts for an unattended run
Section titled “Prompts for an unattended run”Validate whether this item matches the approved unattended task class. Check scope, affected paths, data, reversibility, acceptance criteria, and required tests. Reject it if any field is missing or risk exceeds the policy.Execute only the accepted task in an isolated checkout. Stop after two failed repair attempts, any protected-path touch, or unexpected external dependency. Produce a draft PR with evidence; do not merge or deploy.Triage the completed run as accept for review, refine with one bounded request, reject, or escalate. Cite the evidence and preserve the human gate.Acceptance evidence
Section titled “Acceptance evidence”- Dispatch stops when reviewer or CI queue limits are reached.
- Duplicate triggers are idempotent and cannot create repeated side effects.
- Failed and rejected runs remain in metrics and cost totals.
- The runner has no production credentials and cannot change its own gate policy.
- A kill switch and recovery procedure are tested.
Failure pattern: fire-and-forget backlog
Section titled “Failure pattern: fire-and-forget backlog”An agent that selects arbitrary work while reviewers sleep amplifies ambiguity and queue load. Make eligibility a reviewed contract, bound the queue to acceptance capacity, and prefer no output over a plausible but unauditable change.
Continue with the server loop
Section titled “Continue with the server loop”Implement the runner through AI in CI/CD and set capacity from Team parallelism.