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. The trap is 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, Anysphere's AI code editor, 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.

Common questions

• How do async subagents speed up AI coding workflows?

  They let the parent session keep working while forked children handle scoped tasks in the background. The gain survives review only when each child returns a receipt block: paths touched, commands run, and tests proving regression guards. The parent then merges checkable evidence rather than a friendly summary, which is where most of the time gets saved.

• What should a parent require before accepting child output?

  The child receipt block, checked against the scope ledger. Did the touched paths stay inside the allowed paths, did the verification command run, and does the merge owner match? When the receipt and the ledger disagree, the work is re-scoped or redone, never waved through. That one check stops most quiet regressions before they reach the queue.

• Why do forked agent sessions go wrong so quietly?

  Because summaries replace receipts and the delegation stack turns into a telephone game. Each hop drops the child-owned paths, so by the merge queue the parent is approving a diff nobody can narrate. Nothing errors, nothing looks broken, and the failure only surfaces at the incident review. Receipts at every handoff stop the dropping.

• Who reviews subagent output before merge?

  The merge owner named in the scope ledger, reading the decision stub for context: constraints considered, rejected alternatives, verification proof. Keeping a named person on the hook matters more than the process, especially when several forked sessions each wrote part of the same diff. Accountability lands on someone who can answer for the change.

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.