What Are Agentic Workflows? Design Patterns & When to Use Them

Traditional software workflows are deterministic. They follow a predefined sequence of action, following the branching logic you encoded up front. That approach works well when the path is predictable. But what happens when you can’t know the path in advance? 

Consider a fraud detection system. Traditional software applies predefined rules: flag transactions above a threshold, block transactions from certain geographies, and require step-up authentication if risk exceeds a score. Clear rules. Clean branches. Yet fraud doesn’t follow clean branches. It often presents itself as a subtle change in purchase history, a new device fingerprint, a burst of activity after months of silence, a web of linked accounts. For a fraud detection system, the next move isn’t always obvious. Should the system request more verification? Freeze the account? Scan related transactions? Escalate to a human analyst? Deterministic workflows cannot handle that uncertainty. 

An agentic workflow decides the next step of action at runtime based on context and intermediate results, using tools and a feedback loop to reach a goal within defined guardrails. Instead of following a fixed path, it adapts as it goes.

“Instead of prompting a single time, we can have a more iterative process of taking multiple steps of prompting, tool calling, and other things to stitch together complex workflows.“

Andrew Ng, Founder, DeepLearning.AI

In this article, you’ll learn what agentic workflows are, how they differ from non-agentic workflows, and how to design them for production.

What Makes a Workflow Agentic?

In agentic workflows, the goal is still defined, but the path to reach it isn’t fully specified upfront. Instead, an AI agent decides what to do next based on the current context and the results of previous actions. Rather than simply generating text, the system can reason, use tools, and iterate toward an outcome. 

This shift was made possible by the rise of agentic AI, moving teams away from static, predefined execution paths and toward processes that adapt as conditions change.

In simple terms:

• A traditional workflow follows a script.
• An agentic workflow decides the script as it runs, within defined guardrails.

To do that reliably, agentic workflows typically follow four steps:

1. Planning: Interprets the goal and decides what to do next.
2. Tool use: Execute an action by using tools to interact with the external environment.
3. Reflection: Reflects on the results. If the results don’t meet the goal, it loops back to create another plan and execute again until the goal is completed.
4. Orchestration: Coordinates multiple agents, tools, and states for an efficient workflow.

Deterministic vs. Non-Agentic vs. Agentic Workflows

A common source of confusion is how agentic workflows differ from traditional automation and familiar LLM-powered pipelines. It’s important to know the difference because it changes how you design, evaluate, and operate the system.

Workflow Type	How It Runs	Best For
Deterministic	Fixed steps and rules	Stable, repeatable processes
Non-agentic AI	Fixed pipeline with an LLM step	Bounded tasks like summarizing/classifying/extracting
Agentic AI	Plans, uses tools, and iterates with feedback	Investigation, diagnosis, and open-ended work

Traditional deterministic workflows are fully predefined systems. Every step, branch, and outcome is specified in advance using rules or process definitions. They excel when the path from input to outcome is known and stable.

Non-agentic AI workflows introduce LLMs into the process, but the overall structure remains mostly linear. The sequence of steps is still predefined, even if one step is language-driven (for example: retrieve context → generate an output → stop). The model performs a task within the pipeline, but it doesn’t meaningfully decide what to do next based on results.

Agentic workflows keep the goal fixed but make the path adaptive: they plan, use tools, evaluate results, and continue until a success condition or safe stop is reached.

Design Patterns for Agentic Workflows

Agentic workflows aren’t built by letting a model “run free.” In practice, they rely on a small set of reusable design patterns that balance autonomy with control. These patterns address common failure modes in production systems, including hallucinations, brittle outputs, and silent errors.

Planning Pattern

Planning is the pattern in which an LLM decomposes a high-level goal into executable steps and determines their order at runtime.

Rather than hard-coding the path in advance, the system decides what needs to happen next based on the goal, the current context, and the results of prior actions. This is often described as task decomposition and sequencing.

When It Helps

Planning is most valuable when:

• Questions or tasks require multiple hops of reasoning
• Steps have dependencies on earlier results
• Inputs are incomplete or ambiguous
• The correct path cannot be specified upfront

Common examples include incident investigations, deep research, contract analysis, and complex support triage — situations where each discovery influences the next action.

Implementation Notes

Planning is powerful, but it must be constrained to be reliable:

• Plans should be testable
  Each step should include a clear success or failure condition so the workflow can decide whether to continue, retry, or stop.
• Plans must map to actions
  A plan without execution is speculation. Each step should correspond to concrete tool calls, queries, or operations.

In practice, production systems often use lightweight, bounded planning combined with guardrails rather than unconstrained autonomy. This preserves adaptability without sacrificing predictability.

Tool Use Pattern

The model gets answers from source systems and takes actions rather than guessing in text by using tools.

Instead of inferring answers from training data, the model can invoke specific capabilities — such as querying a database, calling an API, or executing an operation — and incorporate the results into its workflow.

This is what transforms an LLM into an agent.

When It Helps

Tool use is essential in any workflow where correctness depends on the current system state, not static knowledge. Common examples include:

• Querying databases or knowledge graphs
• Checking CRM or ticketing systems
• Inspecting deployments, logs, or infrastructure state
• Executing calculations or validations
• Triggering downstream actions in business systems

Without tool use, agentic workflows degrade into approximations. With it, they can ground decisions in authoritative systems and adapt to real-world conditions.

Implementation Notes 

In production systems, tool use must be explicitly constrained.

Key practices include:

• Tool schemas and strict validation
  Define tools with typed inputs and well-structured outputs. This reduces ambiguity and prevents malformed or unsafe calls.
• Tools as structured context
  Tools are provided to the model as part of its context, including clear descriptions of what each tool does and when it should be used. This allows the model to reliably choose the correct tool rather than hallucinating actions.

Standardizing Tool Access With Model Context Protocol

As agentic workflows scale, managing tools across multiple systems becomes increasingly complex. The Model Context Protocol (MCP) addresses this by providing a standard interface for exposing tools, resources, and prompts to AI systems.

With MCP, agents interact with databases, APIs, and services through a consistent, discoverable protocol rather than custom, one-off integrations. Instead of wiring each tool separately for every model or framework, teams can expose capabilities once through an MCP server and make them available across clients and workflows.

This standardization improves reliability, observability, and reuse — qualities that matter far more in production systems than rapid prototyping.

Reflection Pattern

Reflection is a pattern where an AI system critiques its own output and revises it before finalizing a result. Instead of assuming the first response is correct, the workflow evaluates whether the output meets defined constraints and quality criteria.

When It Helps

Reflection is especially valuable for tasks with high output variance, where correctness or precision matters more than speed:

• Code generation and refactoring
• Query generation (SQL, Cypher, GraphQL)
• Policy or compliance language
• Structured summaries with strict constraints
• Multi-step reasoning where early mistakes compound

In these cases, a single-pass generation often appears plausible but fails subtle requirements. Reflection catches those issues before they reach users or downstream systems.

Implementation Notes

In production systems, reflection is implemented as an explicit evaluation step.

A common pattern:

• Use one prompt (or model) as the generator
• Use a second prompt (or model) as the critic or judge
• Feed structured critique into a revision step

To keep reflection predictable and cost-effective:

• Cap the number of iterations to prevent runaway loops
• Define explicit evaluation criteria
• Optionally persist common failure patterns to improve future runs

Reflection alone does not make a workflow fully agentic. However, it significantly improves output quality and reliability, and is often the first pattern teams adopt in production systems.

Orchestration

Orchestration is the pattern that helps multiple specialized agents coordinate around a shared goal and shared state, rather than relying on a single monolithic agent.

Each agent plays a focused role, for example:

• Planner – Decomposes the goal into steps
• Retriever – Gathers relevant data
• Executor – Performs tool calls or actions
• Validator/Judge – Verifies correctness or compliance
• Reporter – Synthesizes and communicates results

This separation of responsibilities improves clarity, control, and reliability.

When It Helps

Orchestration is most valuable when workflows involve:

• Multiple agents with different specialization
• Multiple domains of expertise (e.g., legal, finance, security)
• Independent verification or review requirements
• High-stakes decisions where separating execution from validation reduces risk

For example, one agent may propose a contract modification while another validates it against policy and regulatory constraints before approval.

Implementation Notes

Without structure, multi-agent systems quickly become chaotic.

• Shared state and decision traces
  Agents should read from and write to a common memory layer so actions are explainable and auditable.
• Explicit handoffs
  Each agent should have clearly defined responsibilities and handoff points. Avoid designs where roles overlap excessively, leading to duplication or conflicting actions.

When designed carefully, multi-agent collaboration increases reliability by turning complex workflows into coordinated, inspectable systems rather than opaque prompt chains.

What Production-Grade Agentic Workflows Require

Agentic workflows introduce flexibility and new failure modes. Success depends less on prompting techniques and more on control, evaluation, and system discipline. In production, agentic workflows require:

• Guardrails: Define explicit allowed and disallowed actions, enforce least-privilege access to tools and data, and validate inputs and outputs around every tool call to prevent unsafe behavior, overreach, and unvalidated decisions.
• Error Handling and Safe Failure Modes: Design for inevitable failures with timeouts, bounded retries, and idempotent tool calls; implement fallbacks, human escalation paths, and loop breakers to prevent runaway execution and ensure safe degradation.
• Evaluation: Focus on outcome-based assessment of correctness, usefulness, and risk, supported by layered testing (unit, integration, regression) and continuous error analysis to iteratively improve prompts, tools, and data quality.
• Latency and Cost Control: Maintain production viability through token budgets, controlled tool-call parallelization, and structured retrieval (including graph-based approaches) to minimize unnecessary context expansion, reduce costs, and improve decision quality.

Where Agentic Workflows Make Sense (and Where They Don’t)

Agentic workflows aren’t a default upgrade over deterministic systems. They’re appropriate for specific classes of problems.

When Agentic Workflows Are a Good Fit

Agentic workflows are well-suited when:

• Inputs are ambiguous or incomplete.
• The goal is clear, but the execution path is flexible.
• The task requires investigation, diagnosis, or troubleshooting.
• Workflows change frequently due to evolving systems or policies.

These are environments where predefined scripts break down, and runtime decision-making adds value.

When to Avoid or Constrain Agentic Workflows

Agentic workflows are usually inappropriate, or must be tightly constrained, when:

• The workflow is simple, repeatable, and rule-driven
• Latency requirements are extremely tight (e.g., real-time control systems)
• Actions are high-risk or compliance-heavy without approval gates
• Tool reliability is low, and failure has significant consequences

In these cases, deterministic or hybrid architectures are typically safer and more predictable.

A Quick Decision Guide

• If the path is known → use a deterministic workflow.
• If the path is unknown but the goal is clear → consider an agentic workflow.
• If both are unclear → narrow the scope or keep humans in the loop.

Knowledge Graphs for Agentic Workflows

Most teams store agent memory in a vector database and retrieve it through vector search. That works well when the right answer is the text that’s most semantically similar to the query.

The limitation is that similarity alone doesn’t capture structure: which entities are connected, how they’re connected, and which paths matter for the task. When the job depends on those connections, retrieving the closest chunk can miss the facts you actually need.

A knowledge graph adds that structural context by modeling entities and relationships explicitly — closer to how real systems and domains are organized. At runtime, an agent can traverse multiple hops (for example, service → dependency → owner → ticket history) to pull in related information that may not use similar wording, but is connected and relevant.

For agentic systems, knowledge graphs provide a structured memory that stores facts and enables multi-hop reasoning across related entities, which agents retrieve through GraphRAG. They also provide decision traces that track and explain agents’ decisions.

When agentic workflows rely on structured, connected context, they become easier to debug, audit, and control — all of which are essential in production environments.

Build Agentic Workflows You Can Trust

Agentic workflows allow AI to operate in dynamic environments rather than fixed prompt-response timelines by combining planning, tool use, reflection, and collaboration.

But design patterns alone aren’t enough. Production success depends on guardrails, evaluation discipline, controlled execution, and high-quality context. Without those foundations, flexibility becomes fragility. When agentic systems must operate accurately, safely, and at scale, context quality matters as much as model capability. 

Knowledge graphs provide the structural layer and quality context that agentic systems require. By modeling entities and relationships explicitly, they reduce ambiguity, improve retrieval precision, and make decisions traceable. Through GraphRAG, agents to retrieve connected facts instead of just semantically similar text to produce more reliable outputs.

To learn how to use knowledge graphs to strengthen retrieval, reduce hallucinations, and support production-grade agentic workflows, read Essential GraphRAG from Manning. It covers domain modeling, graph-powered retrieval design, and context engineering for real-world agentic systems.

This article first appeared on Read More