Split a Big Project Among Several AI Agents and Check Their Work

## Before Work Starts, Make a Plan and Mark Which Actions Need Approval Before execution, convert the request into a plan that every contributor can follow without guessing. - State the objective, required deliverables, acceptance criteria, exclusions, and known constraints. - Separate facts from assumptions. Resolve assumptions that could materially change scope, safety, cost, or the final result before assigning work. - Break the objective into tasks with explicit inputs, outputs, dependencies, and proof of completion. - Identify which tasks are independent and which must wait for prior evidence. Parallelize only work that cannot invalidate another task in progress. - Define the allowed tools, files, systems, and external actions. Treat access as permission to perform the assigned task, not as unlimited authority. - Mark destructive, production, financial, credential, publication, and irreversible actions as approval gates. No agent may infer approval from urgency. - Record a maximum number of repair attempts, a time or resource budget when relevant, and the conditions that require escalation. Proceed within the approved boundary without repeatedly asking for confirmation. Pause only when a missing decision, permission, dependency, or safety condition would change the plan. ## Give Each Task One Owner and Say What to Hand Back Delegate by responsibility rather than by prestige or convenience. Every task must have one accountable owner, a narrow brief, and a defined return format. - Match the role to the work: planning, execution, research, testing, review, or verification. Combine roles only when independence is not needed. - Give each agent the relevant context, source material, constraints, acceptance criteria, and exact files or systems it may touch. - Specify what the agent must return: changed artifacts, findings, evidence, unresolved risks, and a clear status. - Use separate owners for implementation and final verification when the change is high-impact or difficult to reverse. - Avoid duplicate assignment. Two agents must not modify the same target concurrently unless the plan defines non-overlapping boundaries and a merge owner. - Let agents create smaller subtasks only when delegation is permitted, ownership remains traceable, and the concurrency limit is preserved. - Keep the coordinator responsible for integration. Agent reports are evidence candidates, not automatic approval of their own work. Start an assignment only after its prerequisites are available. If the brief is incomplete, return the specific missing item instead of expanding scope. ## Run Independent Tasks Side by Side and Dependent Tasks in Order Run the plan as a dependency-aware workflow. The coordinator should keep useful work moving while preventing collisions, hidden scope growth, and stale decisions. - Start ready independent tasks in parallel up to the defined concurrency limit; run dependent tasks in sequence. - Maintain a compact status for every task: pending, active, blocked, passed, failed, or cancelled. - Send concise progress updates at meaningful boundaries, including completed work, current work, blockers, and any change to the forecast. - When new evidence changes an assumption, update affected tasks before they continue. Do not let agents execute against obsolete requirements. - Preserve small, reviewable, reversible changes. Avoid unrelated cleanup, new dependencies, or architectural expansion unless the approved plan requires them. - Treat user interruption or cancellation as a priority event. Stop at the next safe boundary, preserve valid evidence, and report what remains. - Do not mark waiting as failure while an assigned agent or required process is still legitimately running. The coordinator owns sequencing and conflict resolution. Contributors own only their assigned outputs and must surface uncertainty rather than silently choosing a broader interpretation. ## Check Results Against What Was Asked and Cap Repeat Fixes Completion requires evidence that matches the acceptance criteria. Confidence, effort, and an agent's self-report are not substitutes for verification. - For each deliverable, identify the smallest reliable check that proves the required behavior, content, or state. - Inspect the actual artifact and run relevant tests, validation, review, or readback. Record the result and the evidence source. - Check integration points and directly affected behavior, while avoiding unrelated full-system expansion unless explicitly requested. - If verification fails, classify the cause, assign a focused repair, and rerun the failed check plus any directly affected checks. - Keep repair changes minimal. Do not use a failed verification as permission for unrelated refactoring or scope growth. - Require independent review for high-impact work or when the same reasoning repeatedly misses the defect. - Count repair attempts against the predefined limit. Escalate with the exact failure and evidence when the limit is reached. Repeat the repair and verification cycle only while each iteration produces new evidence or a plausible correction. A pass is valid only when all acceptance criteria have corresponding current evidence. ## Decide to Finish, Ask a Person, or Stop, and Report What Is Left End the workflow deliberately. The coordinator must choose a terminal state from verified completion, bounded failure, blocked, or cancelled, and must not conceal unfinished work. - Declare complete only when required deliverables exist, acceptance checks pass, no required task remains pending, and evidence is current. - Stop and request direction when authority, scope, safety, or a user-controlled decision is missing. - Stop the repair loop when the attempt, time, cost, or concurrency limit is reached, or when repeated attempts no longer create new information. - Cancel immediately when instructed, while preserving recoverable work and avoiding additional side effects. - When blocked, report the blocking condition, checks already performed, safe alternatives tried, and the smallest decision or change needed to resume. - When complete, report the outcome, changed artifacts, verification evidence, remaining risks, and any action intentionally not performed. - Support resumption by recording the last verified state, unfinished tasks, dependencies, and the next safe step. Safety and explicit scope outrank speed. Never continue merely to appear persistent, and never stop merely because one subtask failed when a bounded, evidence-producing repair remains available.