klod68/agentic-workflow-patterns

---

name: agentic-workflow-patterns description: "Use when designing or choosing a multi-step AI workflow, deciding between an autonomous agent and a structured workflow, or when a task requires more than one LLM call and you need a pattern to orchestrate them reliably. Covers the five agentic workflow patterns — prompt chaining, routing, parallelization (sectioning and voting), orchestrator-workers, and evaluator-optimizer — when to use each, and how they map to the Truenorth agent and skill hierarchy. Domain: AI Architecture, Orchestration. Level: Advanced. Tags: agentic, workflows, orchestration, prompt-chaining, routing, parallelization, evaluator-optimizer."

Agentic Workflow Patterns

Problem

When a task requires more than one LLM call, developers reach for complexity by default — chaining calls without structure, building frameworks, or treating every problem as an autonomous agent. This leads to systems that are hard to debug, unreliable, and costlier than necessary.

The right question is not "should I use an agent?" but "which workflow topology fits this task, and is a workflow even needed?"

Core Distinction

Single LLM call       → Optimise the prompt. Start here. Most tasks end here.
        │
        ▼
Workflow              → LLMs and tools orchestrated through predefined code paths.
        │               Predictable. Cheaper. Easier to debug.
        ▼
Agent                 → LLM dynamically directs its own process and tool use.
                        Flexible. Higher cost. Non-deterministic path.

Default to the simplest option that produces acceptable output. Only add a workflow or agent when a simpler approach demonstrably falls short.

---

The Five Workflow Patterns

1 — Prompt Chaining

A task is decomposed into a fixed sequence of LLM calls. Each call processes the output of the previous one. Optional gates (programmatic checks) sit between steps to catch drift early.

Input ──► [LLM Step 1] ──► Gate? ──► [LLM Step 2] ──► Gate? ──► [LLM Step 3] ──► Output
                              │                            │
                              ▼ fail                       ▼ fail
                           Abort / retry               Abort / retry

When to use:

• The task decomposes cleanly into a fixed, ordered sequence of subtasks.
• Each step has a narrower, easier sub-problem than the full task.
• You want to trade latency for higher accuracy (each LLM call is more focused).
• Intermediate outputs can be validated programmatically before proceeding.

Examples:

• Generate marketing copy → check tone → translate to French.
• Write a document outline → validate it meets criteria → write the full document.
• Extract structured data → validate schema → enrich via a second model pass.

Truenorth mapping: The SDLC Orchestrator's stage pipeline (Requirements → Design → Scaffold → Implement → Review → Docs) is a prompt chain with gates between each stage.

---

2 — Routing

An initial classifier (LLM or rule-based) inspects the input and dispatches it to a specialised handler. Each handler is optimised for one class of input.

                    ┌─► [Handler A: General Questions] ──► Output A
Input ──► [Router] ─┼─► [Handler B: Refund Requests]  ──► Output B
                    └─► [Handler C: Technical Support] ──► Output C

When to use:

• Inputs fall into distinct categories that benefit from different prompts or models.
• Optimising one handler for one input type hurts performance on others.
• Classification itself is reliable (either by LLM or deterministic logic).

Examples:

• Customer service triage: general questions → small model; complex disputes → large model.
• Code review routing: security concerns → security filter; performance → performance filter.
• Routing easy/common questions to a cheaper model; rare/hard questions to a more capable one.

Truenorth mapping: Orchestrators (SDLC, DevOps, Frontend, Library, Quality, Troubleshooting) are routers. They classify the incoming task and dispatch to the appropriate filter agent. The task-complexity-routing rule implements routing at the task-tier level (Trivial / Standard / Complex / Structural).

---

3 — Parallelization

Multiple LLM calls run concurrently and their outputs are aggregated. Two variants:

Sectioning — independent subtasks in parallel

                    ┌─► [LLM Worker 1: Subtask A] ──┐
Input ──► [Split] ──┼─► [LLM Worker 2: Subtask B] ──┼──► [Aggregator] ──► Output
                    └─► [LLM Worker 3: Subtask C] ──┘

When to use sectioning:

• The task can be decomposed into fully independent, non-overlapping subtasks.
• Speed matters and subtasks can run in parallel without coordination.
• Different aspects of a problem benefit from separate focused prompts.

Examples:

• Scaffolding, implementing, and writing tests for a feature simultaneously.
• Evaluating code quality across security, performance, and correctness in parallel.
• Scraping multiple sources simultaneously then merging results.

Voting — the same task run N times, results aggregated

                    ┌─► [LLM Instance 1] ──┐
Input ──► [Fanout] ─┼─► [LLM Instance 2] ──┼──► [Vote / Consensus] ──► Output
                    └─► [LLM Instance 3] ──┘

When to use voting:

• Higher confidence is needed than a single call can provide.
• The answer space is discrete and majority vote is meaningful.
• False positives/negatives have asymmetric costs (tunable via threshold).

Examples:

• Vulnerability scanning: flag code only if 2/3 reviewers detect the same issue.
• Content moderation: require multiple classifiers to agree before flagging.
• Code correctness: run the same test-generation prompt three times; keep tests that appear in ≥2 outputs.

Truenorth mapping: The SDLC pipeline's Code Review stage dispatches Security Reviewer, Performance Reviewer, and Contract Reviewer concurrently (sectioning). The Quality Orchestrator runs multiple review filters in parallel over the same codebase.

---

4 — Orchestrator-Workers

A central LLM (the orchestrator) inspects the task, dynamically determines what subtasks are needed, delegates each to a worker LLM, and synthesises the results. The subtask list is not predefined — it is determined at runtime.

                              ┌──► [Worker: edit file A] ──┐
Input ──► [Orchestrator LLM] ─┼──► [Worker: edit file B] ──┼──► [Synthesizer] ──► Output
          (plans dynamically) └──► [Worker: add tests]    ──┘

When to use:

• The set of subtasks needed cannot be known ahead of time.
• Subtask count and nature vary significantly with different inputs.
• The orchestrator can evaluate subtask results and adapt its plan.

Examples:

• Coding tasks where the number and nature of file changes depend entirely on the specific bug.
• Research tasks where follow-up searches depend on what earlier searches revealed.
• Debugging sessions where each diagnostic step reveals the next.

Key difference from parallelization: Parallelization runs predefined subtasks. Orchestrator-Workers determines subtasks dynamically from the input.

Truenorth mapping: The sdlc-orchestrator agent itself operates in this pattern when deciding which agents to invoke based on the specific task. A task requiring only a backend fix routes differently than one requiring new UI + new API + new tests.

---

5 — Evaluator-Optimizer

One LLM generates a response. A separate LLM evaluates it against defined criteria and provides feedback. The generator refines based on the feedback. The loop repeats until evaluation passes or a maximum iteration count is reached.

Input ──► [Generator LLM] ──► [Evaluator LLM] ──► Pass? ──► Output
               ▲                     │
               │    feedback         │ fail
               └─────────────────────┘
                   (refine loop)

When to use:

• Clear, articulable evaluation criteria exist (not just "make it better").
• Human feedback on the raw output would demonstrably improve it.
• An LLM can provide that same feedback programmatically.
• Iterative refinement yields measurable improvement per round.

Examples:

• Literary translation: translator generates; critic evaluates nuance and idiom; translator refines.
• Code generation: model writes code; test runner evaluates; model fixes failures; repeat.
• Document writing: draft is generated; a style-check model evaluates against guidelines; writer refines.

Stopping conditions: Always define a maximum iteration count. Unbounded loops compound cost and can oscillate.

Truenorth mapping: The Troubleshooting Orchestrator implements an evaluator-optimizer loop: diagnose → fix → verify → if failing, diagnose again. Code review with requested changes and re-review is the same pattern applied manually.

---

Decision Matrix

Apply this decision tree before designing any multi-LLM system:

Can a single, well-crafted prompt solve this?
  Yes ──► Use a single LLM call. Done.
  No  ──► Continue.

Is the sequence of steps fixed and predictable?
  Yes ──► Prompt Chaining
  No  ──► Continue.

Does the input type determine the approach?
  Yes ──► Routing
  No  ──► Continue.

Are subtasks independent and known up front?
  Yes ──► Parallelization (Sectioning)
  No  ──► Continue.

Do you need confidence through consensus?
  Yes ──► Parallelization (Voting)
  No  ──► Continue.

Are subtasks determined dynamically at runtime?
  Yes ──► Orchestrator-Workers
  No  ──► Continue.

Is the output iteratively improvable by an evaluator?
  Yes ──► Evaluator-Optimizer
  No  ──► Continue.

Is the task open-ended with unpredictable tool use?
  Yes ──► Autonomous Agent
  No  ──► Revisit. You may be over-engineering.

---

Combining Patterns

These patterns compose. Complex systems combine multiple:

| Combination | Example | |---|---| | Routing + Prompt Chaining | Route task type → run a tailored chain for each type | | Orchestrator-Workers + Parallelization | Orchestrator determines N subtasks → runs them in parallel | | Prompt Chaining + Evaluator-Optimizer | Each chain step has an inline evaluator loop before proceeding | | Routing + Voting | Classify input → run the matched handler N times → vote on result |

Prefer flat compositions over deeply nested ones. Each additional layer multiplies latency and cost.

---

When NOT to Use Any Workflow

• The task is a single transformation or lookup.
• The output quality difference between one call and a chain is negligible.
• Latency or cost constraints make multi-call architectures impractical.
• The complexity of the orchestration exceeds the complexity of the task itself.

The best workflow is often no workflow.

---

Gotchas

1. Latency compounds. Each sequential step adds round-trip time. Parallelise wherever steps are independent. Profile before optimising.
2. Error propagation in chains. A bad output from Step 1 contaminates every downstream step. Add gates (programmatic validators) between steps where drift is risky.
3. Unbounded agent loops. Autonomous agents and evaluator-optimizer loops must have explicit stopping conditions (max iterations, timeout, convergence threshold).
4. Orchestrator hallucination. In orchestrator-workers, the orchestrator LLM can fabricate subtask results or misroute. Always validate subtask outputs programmatically before synthesis.
5. Voting requires a meaningful answer space. Voting works on classification, detection, or discrete selection. It does not work where every response is unique prose.
6. Cost scales with fan-out. Parallelization and voting multiply token consumption by the number of workers. Model selection matters: use smaller, cheaper models for classification and routing steps.
7. Pattern mismatch is costly. Applying Orchestrator-Workers to a task with fixed subtasks wastes the orchestrator's context window. Applying prompt chaining to a dynamic task produces brittle pipelines that break on unanticipated inputs.

---

Related Skills

• Task Complexity Routing (classify task tier before selecting a workflow pattern)
• SDLC Orchestrator Agent (full prompt-chaining + orchestrator-workers implementation)
• Quality Orchestrator Agent (parallelization of review filters)
• Retry with Exponential Backoff (resilience within a single workflow step)
• Circuit Breaker State Machine (protecting individual steps from cascading failure)
• Evaluator-Optimizer via Test Feedback (code generation loop using test results as the evaluator)