8.1 Advanced Agent Patterns: Orchestrator-Worker & Evaluator-Optimizer

Advanced Agent Patterns: Orchestrator-Worker & Evaluator-Optimizer

Exam Blueprint Focus: As LLM applications advance from simple linear chains to autonomous multi-step systems, developers must select and implement architectural patterns that balance autonomy with deterministic reliability. The Anthropic Claude Certified Developer - Foundations (CCDV-F) exam rigorously evaluates candidates on agentic design patterns—specifically identifying when to use the Orchestrator-Worker pattern versus static parallelization, orchestrating dynamic delegation, implementing Evaluator-Optimizer critique loops, and enforcing mathematical convergence criteria to prevent runaway inference billing and model drift.

---

The Agentic Spectrum: From Deterministic Workflows to Autonomous Agents

In modern generative AI engineering, system architectures exist along a spectrum of autonomy. While deterministic workflows (such as sequential prompt chaining, intent routing, and fixed parallel fan-out) rely on developer-defined hardcoded Directed Acyclic Graphs (DAGs), autonomous agents dynamically determine their own control flow at runtime.

Two advanced multi-agent patterns bridge the divide between brittle static pipelines and unconstrained autonomous agents:

1. The Orchestrator-Worker Pattern: Dynamic decomposition, dispatch, and synthesis for open-ended, multi-faceted problems.
2. The Evaluator-Optimizer Pattern: Closed-loop iterative refinement, critique, and validation for high-precision, rubric-governed outputs.

---

Deep Dive: The Orchestrator-Worker Pattern

The Orchestrator-Worker pattern utilizes a central reasoning model (the Orchestrator) to analyze a complex, ambiguously bounded user request, break it down into discrete, sub-problem specifications, dynamically instantiate specialized worker agents (the Workers), execute them in parallel or sequential DAG stages, and synthesize the accumulated results into a coherent final deliverable.

Core Architectural Components

1. The Central Orchestrator:
   • Ingests the high-level user objective, environmental constraints, and available tooling.
   • Produces a structured execution plan (frequently as a JSON-defined list of subtasks with unique identifiers, scopes, required inputs, and expected schemas).
   • Evaluates inter-task dependencies (e.g., determining which tasks can run concurrently and which require prerequisites).
   • Synthesizes the heterogeneous outputs returned by workers, resolving contradictions and eliminating hallucinations.
2. The Worker Subagents:
   • Operate within narrow, highly constrained system prompts and isolated context windows.
   • Receive a scoped subset of tools (least-privilege principle) to minimize tool hallucination and distraction.
   • Can run concurrently using independent inference calls, drastically reducing overall end-to-end wall-clock latency.
   • Return structured payloads (e.g., markdown analysis, structured JSON summaries, or code diffs) directly back to the orchestrator.

When to Use Orchestrator-Worker vs. Fixed Parallelization

A critical distinction on the CCDV-F examination is differentiating between static parallelization (fan-out/fan-in) and dynamic Orchestrator-Worker delegation:

• Fixed Parallelization (Static Fan-Out): Used when the subtasks, schemas, and execution paths are known at compile time. For example, translating a single article into Spanish, French, and Japanese simultaneously, or evaluating a resume against five fixed evaluation criteria (experience, education, skills, certifications, leadership). The pipeline topology is rigid and deterministic.
• Orchestrator-Worker (Dynamic Delegation): Used when the required subtasks cannot be predicted in advance because the subtasks depend entirely on the specific nuances, size, or structure of the runtime input. The orchestrator must first inspect the data to decide what subtasks need to exist, how many workers must be spawned, and which specialized prompts they should use.

Typical Use Cases for Orchestrator-Worker

• Multi-File Codebase Refactoring: Migrating an unfamiliar codebase to a new framework version. The orchestrator scans the repository tree, detects 14 deprecated API usages across 6 separate modules, and dynamically delegates each module's refactoring to a dedicated worker agent.
• Complex Legal Discovery & Contract Analysis: Analyzing an enterprise acquisition with 80 unknown documents. The orchestrator inspects the document manifests, groups them by jurisdiction and risk profile, assigns workers to analyze indemnification clauses per category, and synthesizes an executive risk summary.
• Multi-Source Autonomous Research: Given an open-ended question ("Assess the commercial viability of solid-state lithium-metal batteries"), the orchestrator breaks the query into patent landscape, supply chain constraints, thermal degradation physics, and competitive market pricing, dispatching workers with specialized web-search tools.

Comparative Architectural Matrix

Production JSON Schema for Dynamic Task Planning

In robust production architectures, the orchestrator outputs a validated JSON plan rather than unstructured prose:

{
  "initiative_id": "refactor-auth-v2",
  "plan_summary": "Migrate legacy session authentication to JWT tokens across API routers",
  "tasks": [
    {
      "task_id": "task-01",
      "module": "auth/jwt_handler.py",
      "description": "Implement token generation, validation, and RSA key rotation routines",
      "worker_model": "claude-sonnet-5",
      "tools": ["read_file", "write_file", "run_linter"],
      "dependencies": []
    },
    {
      "task_id": "task-02",
      "module": "middleware/session.py",
      "description": "Replace redis session lookup with JWT header verification",
      "worker_model": "claude-haiku-4-5-20251001",
      "tools": ["read_file", "write_file"],
      "dependencies": ["task-01"]
    }
  ]
}

---

Deep Dive: The Evaluator-Optimizer Pattern

While the Orchestrator-Worker pattern excels at breadth and task coordination, the Evaluator-Optimizer pattern (also known as the Iterative Refinement Loop) excels at depth and output quality. In this pattern, an Optimizer agent generates a candidate solution, and an independent Evaluator assesses the artifact against strict rubrics, automated tests, or domain constraints, returning diagnostic feedback to the optimizer in a closed loop.

The Mechanics of Closed-Loop Iteration

1. Generation (Optimizer): The generator model produces an initial solution (draft document, SQL query, code implementation, translation) conditioned on the task instructions and constraints.
2. Evaluation (Evaluator): The candidate artifact is inspected by an evaluation harness. This evaluator can take multiple forms:
   • Deterministic Automated Harness: Running a test suite (pytest), static analysis linter (flake8, mypy), JSON schema validator, or compiler.
   • LLM-as-a-Judge: A distinct Claude model equipped with an explicit scoring rubric, few-shot calibration anchors, and Chain-of-Thought critique instructions.
   • Hybrid Harness: Deterministic validation run first; if syntax and tests pass, qualitative LLM-as-a-judge evaluates style, tone, and strategic nuance.
3. Feedback Injection: If the evaluation fails, the evaluator does not merely emit a binary boolean. Instead, it generates actionable, localized critique identifying exact lines, violated constraints, edge cases missed, and concrete suggestions for remediation.
4. Refinement (Optimizer): The optimizer receives its previous attempt, the evaluator's critique, and produces an updated candidate artifact.

Setting Convergence and Termination Criteria

Without rigorous mathematical boundaries, an Evaluator-Optimizer loop will degrade into an infinite critique loop, burning hundreds of thousands of tokens and suffering from semantic drift (where successive rewrites erode core truths or introduce new bugs while fixing old ones).

Production Convergence Guardrails

1. Hard Turn Cap (max_iterations = 3): Production benchmarks demonstrate that iterative quality gains exhibit diminishing returns. Most improvements occur between iteration 1 and iteration 2. By iteration 4, models frequently regress. Enforce a strict ceiling of 3 to 5 iterations maximum.
2. Deterministic Acceptance Thresholds: If automated tests pass with exit code 0 or all rubric checklist items are marked boolean true, terminate the loop immediately. Never re-evaluate an artifact that has already passed all acceptance tests.
3. Delta Stagnation Check (Delta < epsilon): Track quantitative evaluation scores across rounds. If the score improves by less than a predefined threshold (e.g., score improves from 8.8 to 8.9 out of 10), terminate the loop. Further iterations consume tokens without generating meaningful quality improvements.
4. Session Token Ceiling: Maintain a cumulative token counter across optimizer and evaluator turns. If total accumulated tokens exceed a hard budget (e.g., 50,000 tokens), abort the loop and return the highest-scoring candidate artifact generated so far.

Failure Modes and Anti-Patterns in Iterative Loops

• The Sycophancy Loop: The evaluator begins nitpicking microscopic stylistic preferences, causing the optimizer to over-correct and lose substantive content.
• Error Ping-Ponging: Fixing bug A breaks feature B; in the next turn, fixing feature B re-introduces bug A. Production mitigations require the evaluator to verify the entire regression suite on each iteration, not just the previously failed component.
• Context Saturation: Feeding every past draft and critique into the optimizer's prompt can exceed context limits and confuse the model. Solution: retain only the original prompt, the latest candidate draft, and the latest critique.

---

Composing Patterns: The Hierarchical Agent Architecture

In state-of-the-art enterprise engineering, Orchestrator-Worker and Evaluator-Optimizer are not mutually exclusive; they are hierarchically composed:

• The Orchestrator breaks down a multi-module migration project into 4 discrete tasks.
• For Task 1 (Database Migration Script), the orchestrator dispatches a Worker.
• The Worker executes an internal Evaluator-Optimizer loop: it drafts the SQL script, executes it against an ephemeral test container, catches a foreign key constraint error, critiques the migration, refines the script, re-runs the test to exit code 0, and returns the verified artifact back to the orchestrator.
• The Orchestrator collects all verified artifacts and performs the final integration merge.