AI Prompt Engineering · Lesson

Orchestrator and Workers

Hierarchical coordination.

Orchestrator and Workers is a free AI Prompt Engineering lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the AI Prompt Engineering learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

The Orchestrator Pattern

In the orchestrator-workers pattern, a single orchestrator agent owns the plan and the goal; worker agents execute scoped subtasks and report back. The orchestrator decomposes, dispatches, integrates, and decides when the task is done.

Orchestrator: planning, routing, synthesis, control flow.
Workers: focused execution within a tight contract.

This hierarchy concentrates judgment in one place and parallelizable labor in many.

Separation of Planning and Execution

The key discipline is keeping planning separate from doing. The orchestrator reasons about strategy with a small, high-level context; workers operate with detailed but narrow context. Mixing the two recreates the overloaded generalist.

The orchestrator should rarely touch raw tool output directly — it reasons over worker summaries.

plan = orchestrator.decompose(goal)        # high-level
results = [worker.run(sub) for sub in plan] # detailed, scoped
final = orchestrator.integrate(results)     # over summaries

Decomposition Quality Drives Everything

The system is only as good as the orchestrator's decomposition. Subtasks must be independent enough to parallelize, scoped enough to hand off cleanly, and collectively complete. Have the orchestrator emit an explicit plan you can inspect before any worker runs.

Independent subtasks -> parallel execution.
Complete coverage -> no gaps in the final answer.

plan = {
  'subtasks': [
    {'id': 1, 'goal': '...', 'inputs': [...], 'depends_on': []},
    {'id': 2, 'goal': '...', 'inputs': [...], 'depends_on': [1]}
  ]
}

Dispatch With Tight Contracts

Each dispatch hands a worker exactly its goal, its inputs, and its expected output schema — nothing more. A worker that knows only its slice cannot be distracted by the broader goal and returns a predictable shape the orchestrator can integrate.

The dispatch message is a contract: clear deliverable, clear format, clear done-criteria.

dispatch = {
  'goal': 'Summarize doc 7 risks',
  'context': doc7,
  'output_schema': {'risks': [{'text': str, 'severity': str}]},
  'done_when': 'all risk clauses covered'
}

Context Isolation Between Workers

Workers should not see each other's full context by default. Isolation prevents one worker's errors or hallucinations from contaminating another and keeps each worker's prompt small and cacheable. The orchestrator is the only component with the global view.

Share between workers only through the orchestrator's vetted summaries, never raw cross-talk.

Parallel vs Sequential Subtasks

Independent subtasks run in parallel for latency wins; dependent ones must respect order. The orchestrator's plan encodes a dependency graph, and the runtime schedules accordingly — fan out the independent leaves, then join.

Fan-out: dispatch all ready subtasks concurrently.
Join: wait for dependencies before dependent dispatch.

def schedule(plan):
    ready = [t for t in plan if not t['depends_on']]
    run_parallel(ready)
    # then unlock tasks whose deps are now done

Integration and Conflict Resolution

Integration is not concatenation. The orchestrator must reconcile overlapping, contradictory, or low-confidence worker outputs into one coherent result, deciding which to trust and surfacing unresolved conflicts.

Give the orchestrator an explicit reconciliation step with rules: prefer higher-confidence, flag contradictions, request a re-run when coverage is incomplete.

merged = orchestrator.reconcile(
  results,
  rules='prefer higher confidence; flag contradictions; re-dispatch on gaps'
)

The Orchestrator as Controller

The orchestrator also owns control flow: deciding when to stop, when to retry a failed worker, when to re-plan, and when to escalate. This makes it the place to enforce budgets — max iterations, max spend, max depth — preventing runaway loops.

Without a controlling orchestrator, multi-agent systems spiral.

if iterations > MAX_ITERS or spend > BUDGET:
    return orchestrator.best_effort_answer()

Recursive Decomposition

A worker can itself be an orchestrator for a sub-problem, forming a hierarchy. This handles deep tasks but adds latency and error-propagation depth. Cap recursion depth and require each level to return a clean summary, so upper levels never drown in lower-level detail.

Failure Containment

Design so a single worker failure degrades gracefully. The orchestrator should detect malformed or empty worker output, retry with a clarified contract, and fall back rather than crash. Workers fail in isolation; the orchestrator absorbs and routes around it.

Validate every worker return against its schema.
Retry-then-fallback, never propagate raw failure upward.

def collect(worker, dispatch):
    out = worker.run(dispatch)
    if not valid(out, dispatch['output_schema']):
        out = worker.run(clarify(dispatch))
    return out or fallback(dispatch)

An Orchestration Blueprint

The blueprint: orchestrator decomposes into an inspectable dependency-graph plan, dispatches tight contracts to isolated workers, runs independent subtasks in parallel, validates and reconciles results with explicit conflict rules, enforces budgets and stop conditions, and contains worker failures with retry-then-fallback. Judgment stays central; labor stays distributed.

Quick Check

You are designing an orchestrator-workers system for a research task with several independent subtopics.

Recap: Orchestrator and Workers

Concentrate planning, routing, integration, and control in one orchestrator; push focused execution to isolated workers under tight contracts. Decompose into an inspectable dependency graph, parallelize independent subtasks, reconcile results with explicit conflict rules, enforce budgets and stop conditions, and contain worker failures with validate-retry-fallback. The orchestrator reasons over summaries, never raw cross-talk, keeping the hierarchy coherent and controllable.

Frequently asked questions

Is the “Orchestrator and Workers” lesson free?

Yes — the full text of “Orchestrator and Workers” is free to read here on the web, and the AI Prompt Engineering course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the AI Prompt Engineering course, upgrade to CoddyKit PRO.

What will I learn in “Orchestrator and Workers”?

Hierarchical coordination. You practise AI Prompt Engineering with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start AI Prompt Engineering?

No prior experience is required. AI Prompt Engineering on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Orchestrator and Workers” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this AI Prompt Engineering lesson?

Yes. Every AI Prompt Engineering lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to AI Prompt Engineering