CS146S Week 8: Once Agents Run in the Cloud, the Bottleneck Moves from Waiting to Reviewing

🌏 中文版

This is the ninth post in the CS146S series, covering Week 8 of Fall 2026.

Three topics: async, cloud-delegated agents; managing fleets of parallel agents; issue-to-PR pipelines and triggers (Slack, Linear, GitHub). The session is "Background agents: launching tasks asynchronously," guest still unannounced.

This week didn't exist in Fall 2025. A year ago, an agent was something you opened a terminal and watched.

Disclosure: this post was written by a background agent — running in an ephemeral cloud container on its own branch, pushing the result when done. The costs and limits below are not speculation.

The shared parts

Product names differ; the architecture has converged:

Claude Code's GitHub Actions integration describes exactly this shape — "Run Claude Code in GitHub Actions workflows to respond to @claude mentions, automate tasks, and turn issues into pull requests" — split into interactive (waits for a trigger) and automation (runs a configured prompt) modes. Codex cloud sums itself up as "Delegate work to Codex in isolated cloud environments."

"Output is a PR" matters more than it looks. It forces agent output into a review mechanism that has existed for decades: diff, CI, review, merge. You don't have to invent an acceptance process for agents. It also means Week 5's codebase readiness becomes a direct throughput ceiling — a repo where CI doesn't run produces PRs nobody can validate.

What belongs in the background

Not every task should be async. Three conditions, all required:

1. You can write the acceptance criteria down — "tests go green," "this lint rule stops firing," "this API returns a new field." If you can't state acceptance up front, you won't know whether the result is right
2. The context fits in one handoff — a task needing three mid-flight questions just makes every round trip longer
3. Failure is cheap — the output is a PR, not a deploy

Filtering by those three, what actually runs well: dependency upgrades, mechanical refactors (renames, API migrations), promoting a lint rule from warn to error and fixing the fallout, adding tests, turning a spec into scaffolding, cross-file consistency fixes.

What runs badly: vague requirements, anything needing back-and-forth alignment, anything depending on business context only you hold. Send those to the background and you get back a PR that looks complete and points the wrong way — and it's harder to throw away than a wrong conversation, because it looks finished.

The real new problem: you are the bottleneck

Starting five background agents is easy. Reading five diffs at once is not.

Concrete problems you will hit:

They don't know about each other. Five agents branch from the same base, two touch the same file, and you find out at merge time. That's not a bug — it's the price of isolation.

Review cost is linear; output speed isn't. Agent output scales horizontally, human review bandwidth doesn't. That's why Week 6's AI code review is sequenced before this week: without an automated review layer, background agents just move the traffic jam from writing to reading.

Silent failure. When you're watching, you see it go off track within thirty seconds. Asynchronously, it can spend twenty minutes walking into a dead end and hand you a diff that took the scenic route. Some harnesses notify mid-run, but "when should this be interrupted" has no good answer yet.

Opaque cost. Five parallel agents each burn tokens; the bill is one number. Attributing it per task needs extra instrumentation — the problem Week 9's gateways exist to solve.

Practical rules

• One agent, one PR, and keep PRs small. Large PRs were already an antipattern for humans; an agent's large PR is worse, because there's no author to ask
• Environment setup lives in the repo. That's what AGENTS.md and setup scripts are for (see Week 4). A background agent has neither your shell history nor the three steps you never wrote down
• Minimize permissions. Nobody is watching a background agent, and Week 7's lethal trifecta is at its most dangerous here: it reads issues (untrusted content), holds repo access (private data), and can open PRs and call APIs (outbound channel) — all three on by default
• Put acceptance criteria in the triggering issue, not in your head

Where this week sits

Read across the ten weeks, Week 8 is the pivot: the first seven teach you to work with one agent, and from here the subject is managing many. The course then moves into Week 9's team scale and Week 10's software factory.

The order makes sense: one person managing three background agents is a tooling problem; an organization managing three hundred is an infrastructure problem.

What will go stale

• Background agent features and pricing move very fast; this post covers shared architecture, not product comparison
• Fall 2026's guest and materials for this week aren't published
• Conventions like "one agent, one PR" are young and may look different in a year

References

• CS146S Fall 2026 syllabus — Week 8 topics
• Claude Code GitHub Actions — official docs on issue-to-PR and the two trigger modes
• Claude Code on the web — cloud sessions, environments, and network policy configuration
• Codex cloud — OpenAI's isolated cloud task environments
• Effective context engineering for AI agents — Anthropic Engineering, on the cost of sub-agent context isolation
• Introducing Agent Readiness — Factory, on how feedback loop quality bounds autonomous run length