Course Content

What are the different task execution patterns in Agentic AI?

In the claims system only about one claim in five ever reaches the bottom rung, which is what a good design looks like.

What you need to know

The patterns

Pattern	How it works	Use when
Single call	One well-prompted request	Always the baseline
Prompt chaining	Fixed steps; each output feeds the next, with checks between	Task splits into known stages
Routing	Classify, then dispatch to a specialised prompt, model or tool set	Distinct request types
Parallelisation: sectioning	Split into independent parts, run together, merge	Independent subtasks
Parallelisation: voting	Same task several times; majority or judge	Need confidence on high-stakes answers
Orchestrator-workers	Lead model decides the subtasks at runtime, workers do them	Subtasks not known in advance
Evaluator-optimizer	Generate, critique against criteria, revise	Clear criteria; revisions help
Agent loop (ReAct)	Think, call a tool, observe, repeat	Unknown number of steps
Plan-and-execute	Write a plan, execute, re-plan on failure	Long tasks; approval needed
Human checkpoint	Pause before a gated action, resume after approval	Irreversible or regulated actions

The first six are workflows: code controls the path. The loop and plan-and-execute are agents: the model controls it. This split, and most of these names, come from widely used industry guidance on building agents; interviewers expect them.

Routing in code

Python

1ROUTES = {2    "status":  {"model": "small",  "handler": "lookup_chain"},3    "change":  {"model": "medium", "handler": "change_booking_agent"},4    "refund":  {"model": "strong", "handler": "refund_agent"},5}67def route(classify, request):8    label, confidence = classify(request)          # one cheap model call9    if label not in ROUTES or confidence < 0.7:10        return {"model": "strong", "handler": "general_agent"}   # safe fallback11    return ROUTES[label]

A cheap classifier decides where the request goes. Unknown labels and low confidence fall back to the capable general handler, so a routing mistake costs money, not correctness.

Choosing

Ask in order: Can one call do it? Are the steps fixed (chain)? Are there distinct types (route)? Are parts independent (parallelise)? Are subtasks unknown until runtime (orchestrator-workers)? Is the number of steps unknown (agent loop)? Stop at the first yes. Every pattern from the agent loop onwards needs step budgets, timeouts and a stop condition.

A real-life example

An insurance company's claims system uses almost every pattern, each in its place:

Routing: a small model tags incoming mail as new claim, status query, document upload or complaint. Status queries (45% of volume) go to a simple lookup chain.
Prompt chaining: new claims run extract fields, then validate against the policy, then check for duplicates, with a code check between each step.
Parallelisation (sectioning): the fraud check, policy check and repair-cost estimate run at the same time.
Voting: for suspected fraud, three independent assessments; two of three must agree before a claim is flagged.
Agent loop: only messy claims with missing or conflicting documents go to an agent that can request documents and search history.
Evaluator-optimizer: the customer letter is checked against a rubric (correct amount, clause cited, plain language) and revised once if needed.
Human checkpoint: every denial and every payout above Rs 2 lakh.

Only about 20% of claims ever reach the agent loop. That is typical of good designs.

Follow-up questions to expect

"Orchestrator-workers versus parallelisation?" — In parallelisation, code defines the subtasks in advance. In orchestrator-workers, the lead model decides them at runtime, based on the input.
"Where does plan-and-execute fit?" — It is an agent pattern with an explicit plan artefact, useful for long tasks, approval and parallel steps.
"Can patterns be nested?" — Yes. A router can send to a chain, one chain step can be an agent loop, and the loop can call a parallel fan-out.