Background agents
Week 9 · Same task, different handoff
What must still be true when nobody is watching?
Learning objectives
LO2: Design a bounded background workflow and its gates.
LO9: Verify the handoff and decide what to accept.
One small request
Skip running builds in the duration median.
Keep the duration display unchanged.
Return a change and evidence; stop on ambiguity.
Hold the comparison constant
Same base, request, initial tests and agent access.
Foreground: you may answer; record interventions. Unattended: return a result or stop without answers.
Generate two possible candidates
Foreground: fix the median only.
Unattended: fix it, change the display and its test.
Course-written predictions, not captured model output.
Predict before verification
Both branch reports say tests pass.
Which unchanged input separates the candidates?
What does the report leave unproven?
Verify the unchanged contract
format_duration(185) must return 3m 05s.
Unattended candidate returns 3:05.
The preserved display test rejects it.
Read the hunks
A permitted test file can contain a forbidden assertion edit.
Map each hunk to the request.
Recheck with tests the candidate cannot redefine.
Background is a handoff
The run returns later with a candidate, diff and evidence.
It can run in a local terminal.
Cloud hosting is not required.
Bound the unanswered question
If the task needs another change or more permission:
stop, retain the partial result and explain.
An unattended run must not guess its own authority.
Generate parallel work
Implementation and test agents start from one recorded base.
Use separate worktrees, branches and bounded responsibilities.
Neither session gets merge authority.
Verify the shared assumption
Implementation: no completed builds means None.
Test branch: expects 0.
Resolve from the request; test the combined candidate.
Worktree isolation has a boundary
Separate directories prevent an edit collision.
They do not enforce host-file or process permissions.
Inspect the execution environment separately.
Generate an issue-to-PR path
Issue -> pinned request/base -> agent -> candidate
-> controller checks -> proposed PR -> review
-> integration checks -> merge decision
A failed or missing gate stops advancement.
Verify the pipeline design
Inject a forbidden hunk, an omitted check and a changed base.
For each, name the controller and the observable block.
A prompt instruction alone is a request.
Keep the gate outside candidate control
Preserve acceptance checks.
Run them on the actual returned revision.
A PASS string from the agent is not a gate result.
Opening is not merging
Prepare a PR only after verification.
Independent review and integration checks still precede acceptance.
Inspect existing work before retrying a lost response.
Studio: generate, then verify twice
Pick a small project or contribution subtask.
Two worktrees, one base and request.
Run foreground and unattended; check each result yourself.
Local execution and paper verification
Use the supplied agent seat in ordinary local terminals.
If the seat is unavailable, stop and record the access blocker. You may trace the two proposed changes on paper, labelled as paper evidence; never call it a real model run.
Compare observable evidence
Interventions and unanswered questions.
Scope, unchanged checks, waiting and rework.
One pair describes these runs; it is not a benchmark.
Decide with evidence
Accept / Narrow / Recheck / Stop — evidence: ...
Name the revision, actual check result and remaining uncertainty.
Changed inputs require another check.
Exit question
Your agent returns green checks from a stale branch.
What must happen before acceptance?
Use the notes, studio, readings and self-check to explain.