Use with AI · Chapter Application

Audit Parallel Agent Work for Speculation, Isolation and Safe Cancellation

Apply Advanced Agents Step 19 to a real codebase and determine whether parallel exploration is isolated, cancellable and side-effect-safe.

Chapter Application Advanced Agents From First Principles Parallel and speculative agent execution Advanced
Read the source chapter → View the learning path →

How to use this

  1. Open a repository-aware AI assistant.
  2. Give it access to the repository or files you want reviewed.
  3. Copy the prompt below and run it unchanged first.
  4. Use the evidence it finds to decide what to inspect or change next.
PromptCopy and run against your own project
You are reviewing an agent system that performs work in parallel or speculatively.

Your job is to determine whether concurrency improves useful exploration without creating duplicate side effects, shared-state corruption, unbounded cost, or false assumptions about cancellation.

Do not recommend more parallelism merely because independent tasks exist.
First reconstruct what currently runs concurrently and what authority each branch has.

1. Map concurrent work.
   Identify:
   - fan-out points
   - worker/task creation
   - candidate generation
   - parallel tool calls
   - background jobs
   - early-stop/cancellation logic
   - join/selection points

2. Classify every parallel branch.
   For each branch report:
   - purpose
   - independence assumptions
   - mutable state it can access
   - external side effects it can create
   - compute/tool budget
   - cancellation mechanism
   - evidence required before its output is selected

3. Check speculative isolation.
   Look for:
   - branches sharing the same mutable workspace
   - writes to production/external systems before selection
   - shared caches or memory that allow losing branches to contaminate winners
   - generated artifacts without stable branch/run identity
   - concurrent operations that assume ordering accidentally

4. Check cancellation semantics.
   Determine whether "cancelled" means:
   - cancellation was requested
   - worker coroutine/task stopped
   - underlying API/tool call stopped
   - external side effect did not occur

   Flag code that treats these as equivalent without evidence.

5. Check commit/selection boundaries.
   Consequential effects should ideally occur only after a candidate/branch has been selected and revalidated.
   Identify paths where speculative work can commit irreversible or duplicate effects early.

6. Check duplicate-work control.
   Distinguish intentional independent exploration from accidental duplication caused by retries, queues, restarts or multiple coordinators.

7. Check budget behavior.
   Determine whether parallelism can multiply:
   - model tokens
   - tool calls
   - browser sessions
   - workspaces
   - verification cost
   beyond the intended run budget.

8. Check verification and stale-state risk.
   Before a winning speculative branch commits, does the system revalidate:
   - current intent
   - current state
   - authority
   - branch ownership
   - external preconditions

For every issue report:

- file and symbol
- evidence
- failure mode
- blast radius
- confidence
- smallest corrective mechanism
- test/failure injection that would prove the correction

Return:

A. Concurrency map
B. Safe speculative paths
C. Shared-state / side-effect hazards
D. Cancellation assumptions that are not actually guaranteed
E. Duplicate-work risks
F. Budget amplification risks
G. Minimum architecture changes, ordered by value

Governing rule:
Parallelize independent, low-risk, high-value work; isolate speculative state; cancel aggressively when evidence is strong; commit side effects only after selection and revalidation.