Parallel Task Orchestrator: Running AI Agents You Can Actually Trust

Running several AI agents at once is easy. Trusting what comes back is not. Parallel Task Orchestrator is a skill that treats that second problem as the real one.

It follows a single pattern: decompose, parallelize, consolidate, verify, report. One main thread owns the plan, the integration and the final answer. Sub-agents do bounded work and hand back evidence. Nothing gets claimed that the repository does not support.

The rule that refuses to run

Most orchestration tooling assumes you want parallelism. This one checks first, and declines when the answer is no.

Three conditions have to hold before a single agent launches:

• At least three tasks have no unmet dependency on one another
• At least two have disjoint write sets, including read-only scopes
• Dispatch and consolidation overhead is actually worth paying

If any of those fail, the work happens in one thread. No orchestration files, no lock, no claimed speed-up, and one line explaining why it was not parallelised. Small or tightly coupled work is slower and riskier when it is split up, and pretending otherwise helps nobody.

Inspect before decomposing

The main thread reads the repository instructions, the current implementation, the working tree and the relevant tests before assigning anything. You cannot hand a sub-agent an architectural decision in a codebase nobody has looked at.

Once that first pass is done, read-only discovery can run in parallel, but each discovery agent gets one explicit path or question and has to return evidence rather than a summary of the whole repository.

Three kinds of task, and only one gets delegated freely

Interfaces and acceptance criteria get frozen before parallel implementation starts. Every path is absolute. If two tasks want the same file, one of them owns it or they run in sequence. Ownership is enforced by assignment and by auditing the diff afterwards, not by a lock file that everyone agrees to respect.

What a sub-agent is actually given

Each assignment states one concrete outcome and why it is independent, the paths it may touch and what it owns, the constraints and frozen interfaces that apply, the evidence and tests it must return, and the things it must not do.

Two boundaries matter more than the rest.

Delegation never expands authorization. If the request was review-only, sub-agents review. They do not start implementing because implementing would be helpful. A sub-agent that reaches an approval or architectural boundary returns a blocker and stops. It cannot give itself consent, and it cannot deploy, publish, delete data or change permissions without the user having said so.

The same responsibility does not go to two agents. Duplication only happens when an independent review was explicitly asked for.

Truth comes from the diff

This is the part I would defend hardest. An agent reporting “I updated four files” is making a claim, not providing evidence. The orchestrator derives what actually changed from the repository diff and compares it against the pre-wave baseline.

Unsupported claims get rejected. So do broken binding rules, missing evidence, and edits outside the assigned scope. When something fails, the failed scope is inspected and its partial patch is either finished or reverted. There is no blind retry, and no repository-wide stash, checkout, reset or clean to tidy up the mess, because those commands destroy work that was never part of the problem.

Verification is not delegated

Ten agents each passing their own tests tells you very little about whether the combined result works. The main thread runs the smallest complete verification set that proves the requested behaviour and catches the regressions that matter, and marks every material check PASS, FAIL or Not verified.

A failed required check blocks the completion claim. “Not verified” is a real answer and gets written down as one, rather than being quietly upgraded to success.

It survives being interrupted

Long runs cross session boundaries, approval gates and interruptions. The skill picks a persistence tier before the first agent launches:

• Tier 0, memory only. One wave, up to three sub-agents, nothing written to disk.
• Tier 1, one run file. A single file with plan, ledger, evidence and context, updated at wave boundaries.
• Tier 2, resumable set. Plan, state, evidence and context files, for runs that cross a session or hand write scopes to several agents.

Every persisted task record carries its status, declared write scope, files actually changed, evidence reference, tests performed, blocker reason, last checkpoint and the exact next action. Close the session, come back tomorrow, and the run resumes from that next action instead of starting again. The main thread is the only writer of state, so there is one version of the truth.

One report at the end

Whatever happened inside, the user gets a single answer in one voice. No pasted agent transcripts, no contradictory recommendations left for the reader to reconcile, and no speed-up claimed when the run was declined and done in a single thread.

When not to use it

Small work. Tightly coupled work. Anything living in one file. Delegation has a cost in coordination and in context, and below a certain size that cost is larger than the work itself. The engage gate exists precisely so that this decision is made on the facts rather than on enthusiasm.

Example invocation

Use $parallel-task-orchestrator to add CSV export to this application, update tests and documentation, preserve existing JSON export behaviour, and return one verified result.