In short

Dispatching agents without verifying the coherence of the decomposition exposes the system to errors that are difficult to diagnose after the fact: write conflicts on a shared file, nested call loops, missing outputs because the source files did not exist. Step 0bis (control point no. 0bis, pre-dispatch self-critique) is a validation step that the orchestrator (main agent that decomposes a task and pilots the sub-agents) applies to its own architecture before launching a single agent. This type of verification detects structural conflicts that are invisible when reading the initial plan.

The problem: cascading errors that are hard to isolate

A multi-agent orchestration (coordinated deployment of several LLM agents in parallel, often called an “Octopus” — one orchestrator + N sub-agents + 1 consolidator) runs in parallel. When a problem occurs, it rarely manifests alone: one agent fails, which deprives the consolidator (final agent in charge of aggregating the sub-agents’ outputs) of an input, which produces an incomplete synthesis, which invalidates a downstream decision. The original source — an incorrect assumption in the initial plan — is buried under several layers of side effects.

In plain terms: when an orchestration plan has a design flaw, you don’t see it at launch time. You see it 5 to 10 minutes later, after having spent [order of magnitude estimate: $0.50 to $5 depending on the models] on a series of LLM calls that produce an unusable result, without knowing which of the agents failed.

This cascading behavior is not unique to LLM agents. In aviation, pre-takeoff checklists exist precisely because a verification omitted on the ground can trigger a chain of in-flight incidents whose cause becomes difficult to trace back. In software development, the code review before a merge plays the same role: detecting inconsistencies before they enter production and contaminate other parts of the system.

Step 0bis transposes this logic to agent orchestration: verify the coherence of the architecture before deploying it, while it is still possible to correct it at zero cost.

Four control points

The verification covers four independent dimensions. Each corresponds to a distinct class of error. The complete checklist fits in 4 closed questions — you either pass or you don’t.

In plain terms: 4 questions, 4 yes/no answers. If a single “no” → rework the plan before dispatching. Total execution time: less than a minute [order of magnitude estimate] for a seasoned orchestrator.

1. Nesting

Is a subtask itself likely to spawn (dynamically create) additional agents? If so, the architecture becomes recursive and nesting (agents embedded within other agents) levels multiply. The practical rule: a maximum of one level of nesting. Beyond that, the coordination complexity outweighs the benefits of parallelism.

Cases are regularly observed where an agent, receiving an ambiguous prompt about its own scope, interprets its task as itself requiring decomposition into sub-agents. Restructuring the initial decomposition — by clarifying the scope of each agent — resolves the problem before dispatch (coordinated launching of agents).

2. Hidden dependencies

Are two agents writing to the same file? Is the output of agent A used as input by agent B? Hidden dependencies turn supposedly independent tasks into masked sequential tasks — incompatible with parallelism.

This control point forces explicit tracing of data flows between agents. If a dependency exists, two options: restructure the decomposition to eliminate it, or serialize the agents concerned rather than launching them in parallel.

3. Feasible parallelism

Is the number of planned agents compatible with the rate limits (request quotas per minute imposed by the API) constraints of the API tier being used? Launching 20 agents simultaneously on a tier that tolerates 5 concurrent requests produces timeouts, not parallelism.

This check is often omitted because planning happens in logical terms (N independent tasks), not in terms of resources. The verification forces reconciling both perspectives.

4. Required files

Do all files referenced in the agents’ prompts actually exist at the time of dispatch? An agent that starts on a non-existent reference fails immediately, with no possibility of recovery.

A simple ls or existence check before dispatch is sufficient. The error is trivial to detect at planning time, and costly to diagnose after the fact.

Self-critique, not external audit

The important conceptual distinction: Step 0bis is applied by the executor itself, on its own planning, before execution. It is not an external review. It is a self-critique (the agent questioning its own plan, without human intervention or a third-party agent) mechanism integrated into the process.

In plain terms: the same orchestrator that designed the plan verifies the plan. No second model, no human validator at this stage — just a structured re-read pass on 4 precise criteria.

This implies that the executor can, and must, question the decomposition it has itself built. In practice, this posture produces flagging that the initial planning would not have generated: “this plan looks coherent, but this specific point is problematic for this concrete reason.”

In practice, the problems detected are predominantly naming conflicts (multiple agents targeting the same file path with slightly different names) and nesting loops (an agent whose prompt implicitly implies a sub-orchestration). Based on our empirical observations in R&D, these two categories represent the majority [order of magnitude estimate: ~70%] of tensions detected at Step 0bis. They systematically go unnoticed when reading the initial plan.

Limits

Step 0bis only detects structural problems visible before execution. It does not protect against content errors — an agent that produces a poorly formatted, factually incorrect, or incomplete output due to lack of context. These errors are only detectable upon examination of the results.

In plain terms: Step 0bis catches plumbing bugs (who writes where, who depends on whom, do the files exist). It does not catch content bugs (wrong answers, hallucinations). For those, you need to re-read the outputs — and ideally cross-check several independent agents.

The verification is also bounded by what the executor can anticipate. Undocumented system constraints (silent quotas, file size limits, API edge case — unforeseen boundary cases — behaviors) escape the check. Step 0bis reduces foreseeable risks, not unknown risks.

Finally, the quality of the verification depends on the precision of the initial decomposition. A vague decomposition produces a vague verification. If agent scopes are fuzzy, hidden dependencies remain hidden.

Key takeaways

  • Step 0bis is a self-critical verification step applied before any dispatch, covering four points: nesting, hidden dependencies, feasible parallelism, required files.
  • Its objective is to detect structural inconsistencies before they cascade through a running orchestration.
  • The most frequently detected errors are naming conflicts and implicit nesting loops — two categories invisible when reading the plan.
  • The mechanism does not protect against content errors or undocumented system constraints.
  • The relevant analogy: the pre-takeoff checklist in aviation, or the code review before a merge — fixed-cost verification points that prevent high-cost corrections.