Agentic Workflows

A scripted workflow defines a fixed sequence: step one, step two, step three. If step two fails — an API times out, a data format is unexpected, a file is missing — the workflow either stops entirely or follows a pre-defined error branch that the developer anticipated at design time. Every possible failure mode must be predicted and handled explicitly in the code.

An agentic workflow defines a goal rather than a sequence. This relates to how task decomposition works in practice. The agent has access to multiple tools and strategies, and it decides which to use based on the current situation. When a data source is unavailable, the agent doesn't just execute a pre-written fallback — it reasons about why the source failed, whether the failure is temporary or permanent, and which alternative source would provide comparable data. The developer defines the goal, the tools, and the constraints; the agent determines the route.

This distinction matters most in environments with high variability — where data sources are unreliable, input formats are inconsistent, or the task requirements change frequently. Agentic workflows absorb variability that would require constant maintenance in scripted systems. They are especially valuable for tasks where the number of possible failure modes is too large to enumerate in advance.

Every agentic workflow requires four components: a goal specification (what success looks like), a tool inventory (what the agent can do), a reasoning loop (how the agent decides what to do next), and guardrails (what the agent must never do regardless of circumstances). The reasoning loop is the core differentiator — it's the mechanism by which the agent observes the result of each action, evaluates progress toward the goal, and selects the next action.

In practice, the reasoning loop often follows the ReAct pattern: Reason about the current state, Act by calling a tool or generating output, Observe the result, and Repeat. Frameworks like LangGraph, CrewAI, and the Anthropic agent SDK implement this loop with different levels of abstraction and control.

The key design decision is how much autonomy the agent has within the loop — can it try indefinitely, or is there a maximum iteration count or cost budget? Can it choose any tool from its inventory, or are certain tools restricted to certain conditions? These constraints shape the boundary between useful autonomy and dangerous runaway behaviour.

Well-designed guardrails are as important as the goal specification. An agent tasked with 'gather competitive intelligence' needs guardrails preventing it from scraping paywalled content, accessing internal systems it shouldn't touch, or spending more than a defined budget on API calls. The guardrails don't just prevent harm — they channel the agent's autonomy into productive directions.

When an action fails, the agent receives the error as an observation and reasons about it. A well-designed agent distinguishes between transient failures (a rate limit that will clear in seconds), permanent failures (an API that has been deprecated), and data failures (the source returned results but they don't contain the expected information). Each type warrants a different recovery strategy.

Recovery strategies include retrying with backoff for transient failures, switching to an alternative tool or data source for permanent failures, and reformulating the query for data failures. The agent may also choose to proceed with partial information, noting the gap in its output rather than blocking the entire workflow. This graceful degradation is one of the primary advantages over scripted pipelines — the system delivers value even when not everything goes perfectly.

The risk is that agents can also fail at reasoning about failures. An agent might retry an action indefinitely, switch to a less reliable data source without noting the quality difference, or confabulate results when it should escalate to a human. Effective guardrails — iteration limits, cost budgets, and mandatory escalation triggers — prevent the reasoning loop from becoming a resource-burning infinite loop.

Logging and observability become critical for agentic systems. When an agent takes a recovery path, that decision needs to be recorded so operators can understand why the agent did what it did. Without detailed logs of the agent's reasoning at each step, debugging production issues in agentic workflows becomes extremely difficult.

Agentic workflows add latency, cost, and complexity. The reasoning loop requires multiple model calls — one to decide what to do, one to do it, one to evaluate the result — and each call introduces latency and token costs. For tasks with a well-defined sequence that rarely fails, a scripted workflow is faster, cheaper, and easier to debug. Adding agentic reasoning to a pipeline where the steps are deterministic and reliable adds overhead without adding value.

A reliable diagnostic: if you can write out the exact steps the workflow should follow and the steps almost never vary, a scripted approach is better. If you find yourself writing extensive branching logic to handle variations, edge cases, and failures, and the branches are growing faster than you can maintain them, that is the signal to consider an agentic approach. The tipping point is usually when the maintenance cost of the scripted branching exceeds the overhead cost of the reasoning loop.

Hybrid approaches often work well in practice. The predictable, reliable portions of a workflow run as scripted steps, while the variable, failure-prone portions are handled by an agent with reasoning capabilities. This confines the complexity and cost of agentic reasoning to the parts of the workflow that actually benefit from it, while keeping the rest of the pipeline simple and fast.

Human-in-the-loop checkpoints at high-stakes decisions — committing financial transactions, sending external communications, modifying production data, deleting records — should require human approval even within an otherwise autonomous workflow. The agent can gather information, prepare the action, and present a recommendation, but a human confirms the execution. This pattern provides the efficiency benefits of agentic reasoning while maintaining a safety net for irreversible actions.

Ambiguity is another natural breakpoint for human involvement. When the agent encounters a situation where multiple interpretations are plausible and the consequences of choosing wrong are significant, escalating to a human for clarification is more efficient than guessing. Good escalation design includes enough context for the human to make a quick decision without reconstructing the full workflow state from scratch.

The placement of human checkpoints should be driven by risk analysis, not by comfort level. Teams new to agentic workflows often insert checkpoints at every step, which eliminates the efficiency gains of autonomy. As confidence grows through monitoring and evaluation, checkpoints can be removed from low-risk steps while remaining at high-risk decision points. The goal is minimum viable oversight — enough human involvement to catch consequential errors, not so much that the agent is effectively doing nothing autonomously.