Orchestrator-Workers Workflow

Why it matters

Here the model, not your code, decides the decomposition. Before you choose an adaptive plan, see what it gains and what it leaves unchecked.

What to practise

Build a FlexibleOrchestrator whose first call analyzes a product-description request and returns two or three approaches as <task> elements in XML. parse_tasks() turns them into dictionaries, and each worker call receives the original task plus its own type and description. Run it on the marketing-copy example. Note that the workers run one after another, that the run costs one orchestrator call plus one per worker, and that the only check on a worker’s result is that it isn’t empty.

How it fits

This is the adaptive decomposition of 1.5.2: the subtasks depend on the input. Compare each worker’s acceptance test with 1.5.1’s independently verifiable result. The notebook returns the variations side by side without combining them, so ask what integration gate 1.5.4 would put there.