Agent Workflows: Orchestrating Multi-Step AI Agents in Production

What Are Agent Workflows

Agent Workflows define how AI agents coordinate reasoning, memory, tools, and actions to accomplish complex tasks. Unlike a simple loop where an agent calls a tool and immediately responds, a workflow structures execution into predictable stages—sequential steps, parallel branches, conditional decisions, and human‑in‑the‑loop pauses—enabling reliable, observable, and scalable agent systems.

From an engineering perspective, a workflow is a state machine. Each step receives a snapshot of the agent’s current state (memory contents, plan status, tool outputs), performs some computation (LLM reasoning, tool call, validation), and transitions to the next step based on the outcome. The workflow engine is responsible for executing these state transitions, managing concurrency, and persisting progress.

LangGraph, which is built on a StateGraph architecture with nodes and edges, represents a shift from linear chain abstractions to the graph semantics needed for branching, looping, retries, and checkpoints. Similarly, CrewAI Flows combine the collaborative power of agent crews with procedural programming for structured, event-driven control.

Why Workflows Matter

Workflows bring structure to the inherently non‑deterministic behaviour of LLM‑driven agents. Without a workflow, an agent might loop indefinitely, lose state across failures, or execute tool calls in an uncoordinated way that wastes tokens and time.

Aspect	Without Workflow (ReAct loop only)	With Workflow Engine
Predictability	Execution path varies with every prompt.	Graph defines explicit transitions.
Reliability	Crash loses entire conversation.	Checkpointing enables resumption.
Observability	Hard to trace what step failed.	Each node emits structured spans.
Scalability	Sequential only; no parallelisation.	DAG allows fan‑out, parallel branches.
Human oversight	Interrupts are ad‑hoc, not built‑in.	Native human‑in‑the‑loop checkpoints.
Cost control	Loops can run unbounded.	Max iterations, step‑level budgets.

Workflows also enable deterministic coordination, parallelism, and conditional routing between agents, making complex multi‑agent systems more straightforward to reason about and debug. Companies such as Klarna, Replit, Elastic, Uber, LinkedIn, and GitLab rely on graph‑based orchestration to run stateful agents in production.

Agent Workflows in Agent Architecture

The workflow engine sits at the orchestration layer, connecting planning, memory, tool calling, and observability.

The workflow engine does not contain business logic—it orchestrates. Each node is a pure function that receives the current state and returns an updated state. The engine guarantees that nodes execute in the order defined by the graph, that state is persisted after each transition, and that failures are handled according to policy.

Workflow Execution Lifecycle

Stage Details

Stage	Purpose	Failure Mode
Request intake	Identify workflow type and session.	Missing session ID → new session created.
State loading	Resume from last checkpoint.	No checkpoint → start from entry node.
Node execution	Run the current node’s logic (LLM, tool, condition).	Node timeout, exception, invalid state.
Edge resolution	Determine next node based on state or condition.	Cyclic edge without termination.
Checkpointing	Persist state after each node.	Write failure → retry with backoff.
Termination	Reach end node or condition.	Max iteration exceeded → forced stop.

Core Workflow Patterns

Sequential Workflows

The simplest pattern: execute nodes one after another in a linear chain.

Use case: Data pipeline where each step depends on the previous output (e.g., extract → transform → load).

Implementation in LangGraph: graph.add_edge("node_a", "node_b")

Parallel Workflows (Fan‑Out / Fan‑In)

Multiple nodes execute simultaneously, then converge.

Use case: Gathering data from multiple independent APIs (weather from three sources, pricing from multiple competitors). Fan‑out reduces total latency from sum of execution times to the maximum.

Conditional Workflows (Branching)

Path depends on evaluation of the current state.

Implementation: LangGraph provides decision nodes with condition types: equals, contains, greater_than, less_than. In AutoGen’s graph extension, edges can be conditionally activated.

Event‑Driven Workflows

Nodes are triggered by external events rather than by completion of a previous node. Common in human‑in‑the‑loop and long‑running approval processes.

Use case: Agent pauses after submitting an approval request. When a human clicks “Approve” or “Deny” (webhook), the workflow resumes from a checkpoint.

Implementation: LangGraph interrupts allow workflows to pause and resume via interrupt(). CrewAI Flows support start/listen/router steps for event‑driven control.

Human‑in‑the‑Loop Workflows

A specialised form of event‑driven workflow where a node waits for human input.

Use case: Drafting an email or document, generating code, processing a financial transaction. Human‑in‑the‑loop checkpoints enable seamless incorporation of human oversight by inspecting and modifying agent state at any point.

Multi‑Agent Workflows

Multiple specialised agents collaborate, each with its own role, tools, and potentially its own workflow.

Use case: A crew for content creation: a Researcher gathers facts (tool calls to search and DB), a Writer synthesises the research into an article, and a Reviewer fact‑checks and edits the output.

CrewAI is built specifically for role‑based multi‑agent orchestration. You define agents with explicit roles (Researcher, Writer, Manager, etc.) instead of a monolithic prompt, assign tasks to them, and group them into a crew.

Workflow Orchestration

Orchestration is the runtime management of workflow execution: state persistence, node scheduling, edge evaluation, retry handling, and concurrency control.

State Management

Every workflow operates on a shared state object that is passed through nodes and persisted after each transition. LangGraph’s State is a typed dictionary (TypedDict) that flows through the graph. The @wundr.io/langgraph-orchestrator package maintains an AgentState with unique ID, messages, arbitrary data store, current step, and history for debugging.

Task Scheduling

The engine must decide, after each node, which node(s) execute next. For parallel branches, the engine identifies all outgoing edges and may execute nodes concurrently if they are independent. For nodes with multiple incoming edges, the engine must implement a join semantics—typically, wait for all predecessors to complete before executing the join node.

Routing

Routing determines the next node based on:

• Static edges – Always go to node B after node A.
• Conditional edges – Evaluate state to choose between nodes.
• Dynamic edges – The node’s output specifies the next node (return {"next": "node_c"}).

Retries

Transient failures (network timeouts, rate limits, temporary API unavailability) should trigger retries. Each node can have its own retry policy:

• Maximum attempts – Typically 3.
• Backoff strategy – Exponential (1s, 2s, 4s) with jitter.
• Retry‑eligible errors – 5xx, timeout, connection errors (not 4xx client errors).

Error Handling

Four categories of error require different handling:

Error Type	Example	Handling
Transient	Timeout, network blip	Retry with backoff.
Permanent	Invalid parameter, auth failure	Fail node, route to fallback node.
Catastrophic	LLM API completely down	Circuit breaker opens, fallback to cheaper model.
Logical	Tool returned unexpected data	Route to replanning node.

Agent Workflows vs Agent Planning

These terms are often conflated, but they operate at different levels of abstraction.

Aspect	Planning	Workflow
Role	Decide what to do (generate action sequence).	Decide how execution is organised (order, concurrency, checkpoints).
Timing	Before execution and during replanning.	Throughout entire execution lifecycle.
Output	Sequence or DAG of actions (tool calls, sub‑tasks).	State machine definition (nodes, edges, conditions).
Adaptivity	Replanning on failure or new information.	Routing based on state; human‑in‑the‑loop pauses.
Ownership	Typically an LLM call.	Workflow engine (LangGraph, CrewAI, Temporal).
Example	Plan: [search_flights, filter_by_price, book_flight].	Workflow: sequential node execution with checkpoint after each.

A planner generates the content of what the agent will do. A workflow engine executes that content in a reliable, observable, and resumable manner. Many production systems combine both: the planning node in a workflow calls an LLM to generate a plan, then the workflow executes each plan step as a sub‑node.

Agent Workflows and Tool Calling

Workflows determine the orchestration of tool calls, while tool calling provides the execution mechanism.

Tool Chaining

In a sequential workflow, the output of one tool is passed as input to the next. The workflow engine must handle data flow between nodes, not just control flow.

Example:

1. get_order(order_id="123") → returns {status: "delayed", eta: "+2 days"}
2. send_email(to=user_email, body="Your order is delayed")

The workflow engine extracts user_email from session state and eta from the first tool’s output.

Parallel Tool Execution

Independent tool calls should execute concurrently to reduce total latency. The workflow engine must support fan‑out (execute multiple tool nodes simultaneously) and fan‑in (wait for all to complete before proceeding).

Result Propagation

Each tool call updates the workflow state. Subsequent nodes access these results via the state object. This requires careful schema design: tool outputs must be structured and namespaced to avoid collisions.

Agent Workflows and Memory

Workflows interact with memory at three distinct levels.

Short‑Term (Session) Memory

The workflow state itself often contains the short‑term memory buffer (recent conversation turns). Each node can read from and write to this buffer. At the end of the workflow, the updated buffer is persisted to the session store.

Checkpointing as Durable Memory

Checkpoints persist the entire workflow state, including pending plan steps, tool results, and conversation history. This is the primary mechanism for durable execution: after a crash, the workflow resumes from the last checkpoint exactly where it left off without losing context.

Long‑Term Memory as a Node

Long‑term memory can be implemented as a dedicated workflow node. Before the main task, a “memory retrieval” node queries the vector store and injects relevant memories into the state. After task completion, a “memory update” node extracts new facts and writes them back.

LangGraph provides “comprehensive memory” with both short‑term working memory for ongoing reasoning and long‑term persistent memory across sessions.

Workflow Patterns in Popular Frameworks

Framework	Workflow Model	Orchestration Capabilities	State Management	Best Use Case
LangGraph	StateGraph with nodes, edges, conditional branching, cycles	Checkpointing, human‑in‑the‑loop, durable execution, parallelism	Typed State dict, multiple checkpointer backends	Complex, long‑running, stateful workflows requiring resumption and debugging
CrewAI	Roles (agents) + tasks + crew; Flows for procedural control	Sequential/parallel tasks, manager agent, event‑driven Flows	Shared memory object, persistence via checkpoints	Role‑based multi‑agent collaboration, content pipelines
AutoGen / Microsoft Agent Framework	Graph‑based workflow API; sequential, parallel, conditional patterns	Multi‑agent conversations, handoffs, group chat, broadcast	Conversation thread management, middleware	Multi‑agent systems with conversational handoffs
OpenAI Agents SDK	Handoff graph between specialised agents	Built‑in tracing, guardrails, handoffs with routing intent	Session context variables	Single‑turn to few‑turn agentic apps with OpenAI stack
Semantic Kernel	Plan + stepwise execution; kernels and plugins	Planners (sequential, stepwise, custom)	Kernel state, memory plugins	Enterprise (.NET/Java) with rich Microsoft ecosystem

LangGraph (Low‑Level, Highly Flexible)

LangGraph is a low‑level orchestration framework for building, managing, and deploying long‑running, stateful agents. It provides:

• Durable execution – Build agents that persist through failures and can run for extended periods, automatically resuming from exactly where they left off.
• Human‑in‑the‑loop – Seamlessly incorporate human oversight by inspecting and modifying agent state at any point during execution.
• Comprehensive memory – Short‑term working memory for ongoing reasoning and long‑term persistent memory across sessions.
• Debugging with LangSmith – Deep visibility with visualisation tools that trace execution paths, capture state transitions, and provide detailed runtime metrics.

LangGraph is used by Klarna, Replit, Elastic, Uber, LinkedIn, and GitLab.

CrewAI (Role‑Based Multi‑Agent)

CrewAI is a role‑based multi‑agent framework built from scratch, independent of LangChain. Its mental model is based on four primitives: Agents, Tasks, Tools, and Crew.

CrewAI offers two complementary approaches:

• Crews – Teams of AI agents with true autonomy, working together through role‑based collaboration.
• Flows – Granular, event‑driven control combining regular code, direct LLM calls, and crew‑based processing.

CrewAI workflows can be declared declaratively in YAML for fast iteration, then upgraded to programmatic Python APIs for advanced orchestration.

AutoGen → Microsoft Agent Framework

AutoGen pioneered multi‑agent orchestration patterns that are now widely adopted. The most significant recent change is a new workflow API that allows you to define complex, multi‑step, multi‑agent workflows using a graph‑based approach. Orchestration patterns such as sequential, parallel, and conditional workflows are built on top of this API.

AutoGen has now merged with Semantic Kernel into the unified Microsoft Agent Framework, which combines AutoGen’s simple multi‑agent orchestration with Semantic Kernel’s enterprise readiness.

OpenAI Agents SDK (Tracer Integration)

The OpenAI Agents SDK includes built‑in tracing capabilities that capture agent activity, including LLM generations, tool calls, guardrails, and handoffs. By default, tracing is enabled and sent to OpenAI’s backend; the built‑in traces dashboard allows developers to visualise, debug, and monitor agent workflows by providing a structured way to see every decision the agents make.

Workflow Reliability

Production workflows must survive transient failures, cascading errors, and partial outages without corrupting state or losing progress.

Retries

Each node should be retryable. Use exponential backoff with jitter to avoid thundering herds. Only retry on transient failures (5xx, timeout). Do not retry on 4xx client errors (except 429 rate limits).

Timeouts

Every node must have a timeout. A node that hangs indefinitely blocks the entire workflow.

Node Type	Typical Timeout
LLM node	30–60s
Tool node (API call)	10–30s
Tool node (DB query)	5–60s
Human‑in‑the‑loop node	Infinite (but workflow can be resumed)

Circuit Breakers

Circuit breakers prevent a bad situation from spiraling further. They monitor failure patterns and automatically cut off traffic to unhealthy components before the rest of the system is affected. After a configurable threshold (e.g., 5 failures in 1 minute), the circuit opens and all calls fail immediately for a cooldown period (e.g., 60 seconds). After the cooldown, limited test calls assess if the service has recovered.

Fallback Chains

When a primary node fails, the workflow should route to a fallback node. For LLM calls, fallback to a cheaper, more stable model. For tool calls, fallback to a cached response or a different API.

Dead‑Letter Queues (DLQ)

Workflows that cannot complete after exhausting retries should be sent to a DLQ for manual inspection and replay. This prevents infinite loops and provides a mechanism for recovering from unexpected failure modes.

Workflow Observability

Without observability, a workflow failure is a black box. SRE teams need visibility into how agents behave, where they fail, and how they perform over time.

Tracing

Tracing captures the path of a request through the system as a tree of spans, each representing a unit of work (an LLM call, a tool execution, a workflow node) with timing, attributes, and parent‑child relationships. Agent‑native tracing understands agent behaviour as a first‑class primitive—reasoning, delegation, coordination, and policy enforcement.

Logging

Each node should log its input, output, duration, and any errors. For workflows, log state transitions (which node → which next node). For sensitive data (API keys, PII), redact before logging.

Metrics

Track at the workflow level:

• Workflow success rate – Percentage of workflows that reach a terminal success node.
• Workflow duration – p50, p95, p99 from start to end.
• Node‑level metrics – Per‑node success rate, error rate, latency.
• Cost metrics – Total LLM token usage, tool API costs per workflow execution.

Execution Monitoring

The workflow engine should expose health endpoints: current active executions, pending checkpoints, DLQ contents, and circuit breaker states.

Workflow Security

Workflows multiply the attack surface because each node may have different permissions and data access.

Access Control

Not every node should have the same permissions. An “email sending” node requires write access to the email API; a “search” node requires only read access to the search index. Enforce node‑level least privilege.

AgentWard sits between agents and their tools (MCP servers, HTTP gateways, function calls) to enforce least‑privilege policies, inspect data flows at runtime, and generate compliance audit trails. Policies are enforced in code, outside the LLM context window—the model never sees them, can’t override them, can’t be tricked into ignoring them.

Tool Permissions

Each tool call must be authorised based on:

• User identity – The end user on whose behalf the agent is acting.
• Tool sensitivity – Read (low risk) vs write (high risk) vs destructive (critical).
• Node context – Some nodes may have higher authority than others.

Data Protection

Sensitive data (PII, secrets) must never be written to checkpoints in plain text. Encrypt checkpoint stores. Redistribute sensitive fields from logs.

Audit Logging

Every workflow transition and tool call must be logged in an immutable audit trail. Full audit trails enable compliance and debugging.

Production Workflow Challenges

Challenge	Description	Mitigation
Long‑running tasks	Workflows that take hours or days cannot hold resources continuously.	Checkpoint frequently; resume on demand; use durable execution.
Tool failures	External APIs fail, change schemas, or become slow.	Retries, circuit breakers, fallback tools, dead‑letter queues.
Workflow loops	Conditional edges can create cycles that never terminate.	Set max iterations (e.g., 100). Detect repeated state patterns.
State corruption	Concurrent updates to the same workflow state.	Use versioned checkpoints; implement optimistic concurrency control.
Cost escalation	Long‑running workflows with repeated LLM calls.	Cache intermediate results; use cheaper models for routine nodes; budget limits.
Latency bottlenecks	Sequential execution of independent nodes.	Parallelise using fan‑out; identify and optimise critical path.
Cold starts	Serverless workflow engines may have high first‑execution latency.	Keep checkpoint store warm; use provisioned concurrency.

Workflow Evaluation

Metric	Definition	How to Measure
Workflow success rate	% of executions reaching terminal success node.	From logs: final_node == "success" / total_executions.
Workflow completion time	Time from start to terminal node (p50, p95, p99).	Trace start and end timestamps.
Node‑level error rate	% of executions where a specific node fails.	Node‑level spans with error=true.
Retry effectiveness	% of failures resolved by retry vs. final failure.	Compare initial failure vs. success after retry.
Dead‑letter rate	% of workflows sent to DLQ.	Count DLQ writes.
Cost per workflow	Total LLM token cost + tool API costs for a complete workflow.	Accumulate across all nodes.

Evaluation dataset: Collect 100–1000 real user requests. Run the workflow on each. Annotate success/failure and the node where failure occurred. Use this to identify problematic nodes and guide optimisation.

Best Practices

1. Define workflows as explicit graphs, not implicit code – A graph (nodes + edges) is easier to visualise, debug, and version than nested conditionals spread across dozens of functions.

2. Checkpoint after every node – Never rely on in‑memory state alone. Persist to a durable store (PostgreSQL, Redis with persistence). This is the single most important reliability practice.

3. Set per‑node timeouts – Do not rely on global timeouts. A 10‑second API call and a 60‑second LLM call need different timeouts.

4. Design nodes as pure functions – Each node should receive state and return an updated state, with no side effects outside the workflow (except explicit tool calls). This makes testing and replay possible.

5. Implement circuit breakers for external dependencies – When an LLM API or tool repeatedly fails, the circuit breaker prevents the workflow from hammering it and incurring cost.

6. Observe before optimising – Add tracing and metrics from the first production deployment. Measure success rates, latencies, and costs. Optimise based on data, not intuition.

7. Version your workflow graphs – A workflow is code. Store the graph definition alongside your application code. Use semantic versioning. When you change the graph (add node, remove edge), increment the version.

8. Separate control flow from content – The workflow engine should not know what a node does internally. It only knows that a node runs, may update state, and then the engine resolves the next edge.

9. Use dead‑letter queues for unrecoverable failures – When all retries are exhausted, write the failing state to a DLQ. A separate process can examine, fix, and replay.

10. Test workflows with simulated failures – Inject delays, timeouts, and error responses into nodes. Verify that retries, fallbacks, and circuit breakers behave as expected.

11. Design for idempotency – If a node can be replayed (e.g., after a crash), it must be idempotent. State‑changing tool calls should accept an idempotency key.

12. Document node contracts – For each node, document its expected input state fields, output state fields, possible errors, and typical duration. This enables independent development and testing of nodes.

Common Workflow Mistakes

Mistake	Consequence	Fix
Overly complex workflows	Hard to debug, high cognitive load, poor performance.	Keep nodes small (one responsibility). Use hierarchical workflows (sub‑graphs).
No observability	Cannot debug failures; no visibility into cost or latency.	Add tracing before writing the first production node.
No failure recovery	Workflow dies on first error. Crash loses all progress.	Retries, checkpoints, circuit breakers, DLQ.
Unlimited execution loops	Workflow runs forever, burning tokens and API credits.	Set max_iterations. Detect repeated state patterns.
Poor state management	Race conditions, lost updates, checkpoint bloat.	Use immutable state deltas; keep checkpoints small (< 1MB).
Mixing workflow logic with business logic	Cannot reuse nodes; testing is impossible.	Nodes return structured state; edge decisions are declarative.
No human‑in‑the‑loop for high‑risk actions	Agent may delete data or send unauthorised emails.	Pause workflow before high‑risk nodes; require explicit approval.
Ignoring cold starts	First execution after deployment is very slow.	Warm checkpoint store; use provisioned concurrency for critical workflows.

Case Study: Enterprise Customer Support Agent Workflow

Scenario: A large e‑commerce company automates customer support for order issues: status checks, refund requests, shipping delays, and product returns.

Workflow Design (LangGraph)

Node Details

Node	Type	Tools / Actions	Timeout	Retry
Classifier	LLM	None (decision only)	15s	1 retry
get_order_status	Tool	GET /orders/{id}	10s	3 retries (exp. backoff)
auth_refund	Tool	POST /refunds/auth	5s	2 retries
execute_refund	Tool (high‑risk)	POST /refunds/execute	30s	1 retry (idempotent)
Human approval node	Human‑in‑the‑loop	Wait for webhook	Infinite (persisted)	N/A

State Transitions

Workflow state after each node:

Initial: {order_id: "123", intent: "refund_request", user_tier: "premium"}

After get_order_status: {order_id: "123", order_status: "delayed", original_eta: "2026-03-15", ...}

After auth_refund: {refund_auth_token: "xyz", refund_amount: 49.99, ...}

After human approval: {refund_approved: true, approved_by: "agent_jane", ...}

After execute_refund: {refund_transaction_id: "ref_456", status: "completed"}

Monitoring Strategy

• Workflow‑level trace – customer_support_workflow with spans for each node.
• Metrics – Success rate (target > 95%), average duration (target < 30s), human escalation rate (alert if > 20%).
• Alerts – get_order_status failure rate > 5% in 5 minutes. Refund workflow takes > 60s.
• Cost tracking – Sum of LLM token costs across all nodes + tool API costs per workflow execution.

Optimisation Opportunities

• Parallel classification – Classifier node could be replaced with a faster routing service (embedding‑based intent classifier) to reduce latency.
• Caching – get_order_status results cached for 5 minutes; repeat queries from same user hit cache.
• Fallback – If execute_refund fails after retries, fallback to human‑managed refund via support ticket.
• Batching – Multiple refund requests from same user batched into a single approval.

Result after deployment: Workflow success rate 96.2%, average duration 9.8 seconds, human escalation rate 8% (down from 34% with previous chatbot). Cost per workflow $0.023 (LLM + tool API).

FAQ

1. What is the difference between a workflow and a plan?
A workflow is the execution structure defined at design time (nodes, edges, checkpoints). A plan is the action sequence generated at runtime by the planner. Workflows execute plans step by step and handle failures, retries, and state persistence.

2. Are workflows necessary for simple single‑turn agents?
No. For agents that make a single tool call and respond, a simple ReAct loop is sufficient. Introduce a workflow engine when you need more than 3 steps, conditional branching, human approval, or long‑running execution.

3. How does LangGraph handle workflows compared to CrewAI?
LangGraph is a low‑level graph orchestration framework with explicit state, checkpoints, and cycles. CrewAI is a higher‑level role‑based framework for multi‑agent collaboration. LangGraph gives you fine control; CrewAI abstracts more. Many production systems use LangGraph for complex, stateful workflows and CrewAI for content pipelines with defined roles.

4. When should workflows be explicit vs. implicit?
Explicit workflows (graph definitions) are preferable for production systems because they are predictable, testable, and observable. Implicit workflows (code that calls code that calls code) are harder to debug and cannot be checkpointed. Make workflows explicit.

5. How do I handle human‑in‑the‑loop in a workflow?
Implement a special node that persists state and then waits for an external signal (webhook, message queue). The workflow engine should support interruptions: when the node runs, it saves a checkpoint and exits. When the human responds, the workflow is resumed from that checkpoint with the human’s input added to state.

6. What is the difference between AutoGen and Microsoft Agent Framework?
AutoGen is the original multi‑agent orchestration framework from Microsoft Research. It has merged with Semantic Kernel into the unified Microsoft Agent Framework, which takes AutoGen’s simple orchestration and adds Semantic Kernel’s enterprise readiness. AutoGen will still be maintained but will not receive significant new features.

7. How do workflows scale?
Workflows scale by making the engine stateless (checkpoints stored externally) and horizontally scaling the executor. Each workflow execution runs independently. Long‑running workflows can be paused and resumed without holding resources. Parallel nodes fan out across multiple workers.

8. Can I mix LangGraph nodes with arbitrary Python code?
Yes. In LangGraph, a node is any function that takes state and returns an updated state. You can call arbitrary Python code, call an LLM, execute a tool, run a sub‑workflow—anything, as long as it obeys the state contract.

9. How do I test a workflow without running all the tool calls?
Mock the node functions. Replace tool‑calling nodes with stub implementations that return predetermined outputs. Replace LLM nodes with deterministic mock models. This allows you to test edge conditions and error handling without incurring API costs.

10. What is durable execution, and why does it matter for workflows?
Durable execution means the workflow persists its state after every step and automatically resumes after a crash or restart. It matters because agent workflows often run for minutes, hours, or days. Without durable execution, a single pod restart loses all progress.

11. How do workflows handle cost control?
Implement per‑workflow budget limits (e.g., max 20,000 tokens, max 10 tool calls). Check the budget after each node; if exceeded, route to a termination node. For expensive tool calls, require explicit approval before execution.

12. What are the trade‑offs between sequential and parallel workflows?
Sequential is simpler to debug and has predictable resource usage. Parallel reduces total latency but introduces complexity in handling partial failures and merging results. Only parallelise when nodes are truly independent and latency matters.

13. Can one workflow call another workflow?
Yes. This is called a sub‑workflow or nested workflow. The parent workflow node invokes a child workflow, waiting for its completion. The child workflow has its own state, checkpoints, and error handling. Nested workflows allow composition and reuse.

14. How do I migrate a linear ReAct agent to a workflow?
Start by converting each ReAct step into a node. Identify the decision points (where the agent chooses the next action) and make them explicit conditional edges. Add a checkpoint node after each step. Keep the existing LLM prompts unchanged. Gradually add parallel branches and fallback nodes.

15. What is the recommended workflow engine for production Java environments?
Semantic Kernel (now part of Microsoft Agent Framework) has strong Java support. For pure Java implementations, consider Temporal for durable execution with a custom orchestration layer, or a lightweight state machine library (Spring State Machine) for simpler workflows. LangGraph4j is emerging but less mature.

Continue Your Journey

Now that you understand how workflows orchestrate multi‑step agent execution, explore the components that work alongside workflows:

• Planning – Agent Planning (generating the action sequences that workflows execute)
• Tool Calling – Tool Calling (executing the individual steps within a workflow)
• Memory – Agent Memory (persisting state across workflow nodes)
• Frameworks – LangGraph Guide (implementing production workflows)
• Evaluation – Agent Evaluation (measuring workflow effectiveness)
• Human‑in‑the‑Loop – Human‑in‑the‑Loop Patterns (designing approval workflows)

Or return to the Agent Learning Path to see where workflows fit in your roadmap.

---

This article is part of the AgentDevPro Production Agent Engineering Handbook. Updated for Q2 2026.