Week 9: Background agents

The example below is course-written and hand-worked; its predictions are not a model run.

Learning objectives

Outcome	What you will demonstrate
LO2	Run the same bounded task with immediate feedback and with a later handoff; isolate parallel work; identify the checks that must block a pipeline
LO9	Inspect an unattended result against the request and upstream rules, verify its evidence, and decide whether to accept, narrow, recheck or stop

The studio uses a small task from your project or current contribution. It adds a comparison and a decision to your existing work record, rather than another assignment. Follow the current syllabus's model-access and safety section while you work.

Minimal example

One request, two ways to run it

A duration summary fails when a running build has duration=None. The request is:

Keep only completed durations when computing the median.
[60, None] -> 60; [60, 120, None] -> 90; [None] -> None.
Keep duration display unchanged: format_duration(185) -> "3m 05s".
Change only the summary implementation and add regression tests.
Do not edit existing test expectations, dependencies or pipeline checks.
If another change is needed, stop and explain. Return a diff, check evidence
and unresolved questions. Do not push, open a remote PR or merge.

Generate. In a foreground session, the student stays present to answer a question. In an unattended session, the same agent receives the same base revision and request, then works without answers until it returns or reaches its stop condition. Unattended means a later handoff; it can happen in a local directory with an ordinary terminal. It does not require a cloud service. Neither mode changes what counts as correct.

Before reading the candidates, predict what a green branch check can establish.

Candidate	Generated change	Agent's report
Foreground	Skip `None` in the summary; preserve display	Summary cases pass
Unattended	Skip `None`; change display to `3:05`; rewrite the display test to expect `3:05`	All branch tests pass

Verify. Trace the three summary inputs through each candidate. Both could satisfy them. Then compare the unchanged display requirement with each returned diff. A check that uses the base display test against the unattended implementation would fail: 3:05 != 3m 05s. The branch's green report does not resolve that disagreement. This is a possible pair of outcomes, not a claim that one mode always performs better.

A file allowlist permits edits to the test file; it does not permit every edit within that file. Read the hunks. Keep the acceptance cases under the student's control and run them yourself against the returned revision. The unattended candidate needs revision.

Parallel work has three different boundaries

Generate. Suppose another agent adds the summary tests while the implementation agent changes the summary. Give each a separate worktree and branch from the same base, with a bounded file list and a stop condition. Give neither authority to merge.

Verify. Inspect the diff in each branch, then test the combined candidate. If the implementation returns None for no completed builds but the new tests require 0, isolation has prevented an edit collision while leaving a contract conflict. Resolve the conflict from the request, then rerun the checks after integration.

Boundary	What you inspect
Working directory and branch	Separate worktrees, recorded base, each diff and uncommitted files
Permissions and execution	Actual tool permissions and execution environment; a worktree alone is not a security sandbox
Shared assumptions	One contract, non-overlapping responsibilities and a combined-candidate check

Parallelism helps only when useful independent work outweighs coordination and integration. For a tiny fix, sequential runs may be easier to inspect. A second session is not automatically an independent reviewer if it helped implement the change.

An issue-to-pull-request pipeline

Generate. Draft a controller that reads an authorized issue, records its base and acceptance criteria, creates a task branch, runs an agent, checks its result and prepares a pull request. The diagram describes a design you can simulate locally.

Authorized issue -> frozen request/base -> isolated agent workspace
  -> candidate revision -> controller verification -> draft pull request
                                       |
                            FAIL / missing evidence / timeout
                                       v
                              stop; retain a failure reason
Draft pull request -> independent review -> integration checks -> merge decision

Verify. Try three failures: a forbidden diff, an omitted check and a changed base. Name the component that prevents each from advancing. Writing “please run tests” in the prompt is a request. A controller that refuses the next stage when a required check is missing or fails is a gate. The agent's own “PASS” text is not the controller's result.

Stage	Gate and who controls it
Start	Controller verifies authorization, repository, bounded task and pinned base
Run	Execution controls enforce permissions and stop limits; no unattended permission expansion
Return	Controller collects the actual diff and revision, detects forbidden changes and incomplete evidence
Check	Checks retained outside the candidate's writable scope run against that exact candidate; failures and missing results block
Open PR	Only a passing candidate gains the narrowly scoped ability to prepare/open a PR; opening does not grant merge authority
Integrate	Independent review plus required checks on the combined current candidate precede the merge decision

For the display change, a branch-local rewritten test is a request-shaped safeguard: the agent can redefine success. Keeping the base test outside its writable scope and requiring its result blocks the candidate. Review still checks whether the contract and test cover the right behavior. Retry only a bounded failed stage; first inspect whether it already created a branch or PR so a retry does not create duplicate work.

Hands-on exercise

Use the studio instructions to run one task twice from the same base in two local worktrees. Hold the request and acceptance checks constant. Record interventions in the foreground run and unresolved questions in the unattended run. Compare correctness, scope, waiting and rework; do not infer general agent performance from this single pair. If the supplied agent seat is unavailable, stop and record the access blocker; you may still complete the hand-worked verification table as a paper exercise.

Verification

Before generation, preserve a reproducer that fails on the base and the relevant existing checks. Verify that the check notices the fault; otherwise recheck the test.
After each run, use git status --short, git diff BASE_SHA and the project's exact verification command recorded in the request. Review untracked files as well as the diff.
Keep command, candidate revision, exit status and the meaningful failing/passing output. Treat an absent result as unknown. Confirm that unchanged checks still run.
Test against current integration inputs before accepting an unattended result. Earlier success applies to the earlier snapshot. Changed inputs require another check.
Write one decision: Accept / Narrow / Recheck / Stop — evidence: ....

For the example, useful negative checks are the display expectation, all-running input, a forbidden changed test and a missing verification result. A screenshot of a green report cannot substitute for these checks. Mark each handoff claim confirmed, refuted or cannot tell, with the evidence or the missing check that would decide it.

Common mistakes

Mistake	Observable warning	Correction
Treat a detached run as cloud-only	The plan requires new paid hosting	Run locally with the supplied agent access; no hosted pipeline is required
Treat worktrees as security isolation	Both processes can reach the same host resources	Inspect permissions and the execution environment separately
Let the candidate define its own success	Existing assertions or gate configuration changed	Preserve controller-owned acceptance checks and inspect each hunk
Merge two green branches without testing	Evidence names only the separate revisions	Run checks on the integrated revision
Leave an ambiguous request unattended	The agent guessed a missing requirement	Add a stop-and-return condition and clarify before retrying
Treat an agent report as evidence	No command, revision or actual result is available	Recheck and retain your own result

Continue with the readings and self-check.