Async subagents that speed up AI coding workflows

Async subagents speed up AI coding workflows only when every fork hands back receipts you can check against the diff. An async subagent is a forked agent session that works one scoped task in the background and reports to the parent while the parent keeps moving. The speed is real. Watch for that the speed evaporates at review, because nobody can say which fork wrote the change. So the rule is simple: make forks explain themselves, and the parallelism pays off. The agent here is Cursor though the same shape holds for Claude Code and Codex.

Make forks explain themselves

Forked agent work breaks at the seams, not in the middle. Each child does fine on its own task. The damage happens at handoff, when a summary stands in for proof.

That is why the incident review keeps ending on the same dead question: which fork wrote the regression, the parent or one of its children? You can answer that in seconds, but only if each fork left a written trail.

More autonomy is not the unlock most teams expect. The tax shows up later as merge-queue fatigue: green CI, mystery diffs, and reviewers asking "why this approach?" with no written answer. Parallel sessions do not buy speed. Explainable parallel sessions do.

Give every child a receipt block

A receipt block is a short, fixed report every child returns: the paths it touched, the commands it ran, and the tests that prove its regression guards. The parent reads the receipt, checks it against the diff, and merges evidence instead of a vibe.

Without it, children return summaries that quietly drop their own changed paths. Each hop loses a little more, and by the merge queue the parent is green-lighting work nobody can narrate. The receipt stops the dropping.

Pair the receipt with two more small artifacts and the seams hold:

• Decision stub. Three lines in the PR template: constraints considered, rejected alternatives, verification proof. Review stops being a vote and starts being a read.
• Scope ledger. Five lines the parent carries and every fork inherits: goal, allowed paths, forbidden paths, verification command, merge owner. Forks inherit boundaries instead of guessing at them.

The Cursor agent docs describe the machinery for running these sessions, but the boundaries are yours to write. .mdc language reads as precise right up until two reviewers disagree about what it meant.

Write a boundary snapshot forks inherit

Keep one snapshot at the top of your rules so every forked run starts from the same map. Adapt the globs to your repo:

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Cursor: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

One more guard belongs here for shared machines. Run Claude Code on a team laptop and bash approvals turn into muscle memory fast. State the precedence at the top of CLAUDE.md: which hooks win, which folders need human eyes, where temporary overrides live. Sessions then stop inventing policy mid-run.

Check four boring questions at the merge

A forked workflow survives review when these four questions have dull, fast answers. If any answer is "we are not sure," the work goes back.

If your repo cannot state its boundaries plainly, agents will guess, and guessing scales poorly. Treat review as the gate where parallel output has to be inspectable without replaying a single session. The full version of that idea lives in our methodology, and the team-policy side sits under agentic coding governance.

Try one fix this week

Pick a single named fix, a child receipt template or a five-line scope ledger, and run it on your next forked task before standardizing it. If forked work is already outrunning your review habits, our training walks teams through fitting receipts to their own stack.