Multi Agent Conductor

Multi-Agent Conductor

Turn multiple agents into one controlled workflow. Optimize for validated throughput, not agent count: every delegation must reduce latency, isolate context, or add independent expertise more than it increases coordination cost.

Decide whether to delegate

Delegate a subtask when it has a clear output and at least one of these is true:

• it can run independently in parallel with other useful work
• it benefits from a separate context window or specialized capability
• an independent evidence-gathering or review pass materially improves confidence
• isolating it protects the primary task from large logs or exploratory branches

Keep work with the primary agent when it is tiny, tightly interleaved with the next decision, depends on rapidly changing shared state, or requires the primary agent's authority over an external mutation. Do not create agents merely to restate, summarize, or validate trivial work.

Delegation does not expand authorization. Use agents only when delegation is explicitly allowed by the user or governing instructions.

Draw the dependency graph

For each candidate work unit, identify:

• required inputs and their current revision
• expected artifact or decision
• read set and write set
• upstream dependencies and downstream consumers
• tools and mutations it may use
• acceptance checks and stop conditions

Run units concurrently only when they have no unmet dependency and cannot race on the same mutable state. If agents share a filesystem or repository, assume their edits are immediately visible to each other unless the environment guarantees isolation.

Assign exactly one owner to every mutable artifact, branch, record, or external resource. Multiple agents may inspect the same target, but only the owner may change it. Keep reviewers read-only and centralize consequential external actions when ownership cannot be isolated safely.

Choose the orchestration shape

• Manager with specialists: the primary agent retains control and calls agents for bounded artifacts. Use when one agent must integrate the final answer or enforce common constraints.
• Handoff: a specialist takes over the active interaction. Use when the specialist should own the remaining conversation, not merely return evidence.
• Pipeline: one result becomes the next agent's input. Use for genuinely sequential stages with explicit acceptance between stages.
• Fan-out / fan-in: independent agents work in parallel and the primary agent reconciles their outputs. Use for disjoint research, implementation areas, or competing assessments.
• Maker / checker: one agent produces an artifact and an independent read-only agent evaluates it against a fixed contract. Bound revisions; do not loop until a model happens to approve.

Prefer the simplest shape that exposes dependencies and preserves one clear owner for the final result.

Issue an agent contract

Give each agent the minimum complete context needed to act:

Objective:
Why this unit is separate:
Inputs and evidence pointers:
Allowed tools and actions:
Read scope:
Exclusive write scope:
Output artifact or schema:
Acceptance checks:
Stop and escalate when:
Downstream consumer:

Include exact paths, identifiers, versions, and known constraints when they prevent rediscovery. Exclude unrelated conversation history, secrets, and speculative conclusions. State whether the agent may spawn children; absence of permission means it may not expand the delegation tree.

Conduct the run

• Dispatch only dependency-ready units. Continue useful primary work while independent agents run.
• Prevent duplicated effort by routing new evidence or corrections to the current owner instead of silently redoing the task.
• Keep fan-out and recursion proportional to the integration burden. More partial answers can make the final result slower and less reliable.
• Treat agent summaries as claims. Require the artifact, source pointer, command result, revision, or test evidence needed by the acceptance contract.
• If an agent stalls or fails, recover its partial artifacts before reassigning. Transfer ownership explicitly so two agents cannot resume the same mutation concurrently.
• If shared state changes unexpectedly, pause affected units and rebase their assumptions from current evidence. Do not overwrite another agent's work.

Integrate through one owner

The primary agent owns final reconciliation unless the orchestration contract explicitly transfers that role.

1. Check every returned artifact against its contract.
2. Re-verify drift-prone facts and mutable shared state.
3. Resolve conflicting conclusions through source quality and discriminating evidence, not majority vote.
4. Combine changes through one integration path; do not ask several agents to merge the same result.
5. Run cross-boundary tests for interactions no individual subtask could observe.
6. Confirm all open dependencies and promised follow-ups are closed or reported.

The workflow is complete only when the integrated artifact satisfies the original user request and its verification, not when every agent has produced a response. Report the result as one coherent outcome, with unresolved risks and evidence where they materially affect confidence.