← All posts

Agentic Workflows Explained: When to Let the Model Drive

Quick answer: An agentic workflow is a process where a language model makes control-flow decisions at runtime, choosing which step to take next instead of following a fixed script. A traditional pipeline runs the same steps in the same order every time. An agentic workflow lets the model decide, based on what it sees, so it can handle inputs a fixed pipeline could not anticipate. The skill is knowing which parts to let the model drive and which to hardcode.

The word "agentic" gets stretched to cover everything from a single prompt to a fleet of autonomous bots. For workflows specifically, the useful definition is narrow: does the model decide the order of operations, or does your code? If your code decides, it is a pipeline. If the model decides, it is agentic. Most real systems are a blend, and getting the blend right is the whole game.

Fixed pipeline vs agentic workflow

Here is the distinction in one table.

Aspect Fixed pipeline Agentic workflow
Step order Hardcoded, same every run Chosen by the model at runtime
Handles novel input Only what you coded for Adapts to unanticipated cases
Predictability High, easy to test Lower, needs observability
Cost per run Fixed Variable, depends on decisions
Debugging Read the code Read the trace
Best for Well-understood, repeatable tasks Open-ended, branching tasks

A pipeline is a recipe. An agentic workflow is a cook who reads the situation. You want a recipe when the task is the same every time and a cook when it is not.

When to hardcode and when to let the model drive

The instinct to make everything agentic is a mistake. Model-driven control is powerful and also slower, costlier, and harder to test. Use this heuristic.

Hardcode the step when:

  • The order never changes. Validate input, then transform, then store. There is nothing to decide.
  • The step is deterministic and cheap. Parsing a date does not need a model.
  • Correctness is critical and the logic is known. Do not ask a model to decide whether to charge a credit card twice.

Let the model drive when:

  • The next step depends on content the model has to interpret. "If this document is an invoice, extract line items; if it is a contract, extract parties."
  • The path branches in ways you cannot fully enumerate ahead of time.
  • The task involves gathering information whose shape you do not know in advance, like researching a topic across the live web.

A clean design uses hardcoded steps for the skeleton and hands the model control only at the genuinely uncertain joints. That keeps the workflow testable while still adaptive where it matters.

Common workflow shapes

A handful of patterns cover most agentic workflows. Knowing them by name helps you pick the right one.

Routing. The model classifies the input and sends it down one of several fixed branches. Each branch is a normal pipeline. The only agentic decision is which branch. This is the safest way to add model-driven behavior: the uncertainty is contained to one choice.

Chaining with a decision point. Run steps in order, but let the model decide whether to continue, retry, or stop after each one. A research workflow might search, then let the model judge whether the results are sufficient before deciding to search again.

The agent loop. The model plans, acts through a tool, observes the result, and repeats until done. This is the most open-ended shape and the one people usually mean by "agent." It is the right choice when the number and order of steps genuinely cannot be known in advance.

Orchestrator and workers. A coordinating model breaks a task into subtasks and delegates each to a focused worker, then combines the results. Useful when subtasks are independent and can run in parallel.

Most of these need to touch the live web at some point, which is the reliability question worth dwelling on.

A worked example

Say you want a workflow that, given a product name, produces a short competitive brief: what the product does, its pricing, and one recent piece of news. That is a routing-plus-loop shape.

The skeleton is hardcoded: accept the name, run the research loop, format the brief, return it. The research loop is where the model drives, deciding what to search for and which pages to read. The web tools come from link.sc, so the workflow never has to manage rendering or proxies.

import os
import requests
import anthropic

HEADERS = {"x-api-key": os.environ["LINKSC_API_KEY"]}
client = anthropic.Anthropic()

def web_search(query: str) -> str:
    r = requests.post("https://api.link.sc/v1/search", headers=HEADERS,
                      json={"q": query, "engine": "google"}, timeout=60)
    r.raise_for_status()
    pages = []
    for item in r.json()["serpData"]["results"][:3]:
        f = requests.post("https://api.link.sc/v1/fetch", headers=HEADERS,
                          json={"url": item["targetUrl"], "format": "markdown"},
                          timeout=60)
        f.raise_for_status()
        pages.append(f"## {item['title']}\n{item['targetUrl']}\n\n"
                     + f.json()["content"][:4000])
    return "\n\n".join(pages)

TOOLS = [{
    "name": "web_search",
    "description": "Search the live web and return full page content. Use to find what a product does, its pricing, and recent news.",
    "input_schema": {"type": "object",
                     "properties": {"query": {"type": "string"}},
                     "required": ["query"]},
}]

def competitive_brief(product: str, max_steps: int = 5) -> str:
    goal = (f"Research the product '{product}'. Find what it does, its current "
            f"pricing, and one recent news item. Return a three-paragraph brief "
            f"with source URLs.")
    messages = [{"role": "user", "content": goal}]
    for _ in range(max_steps):
        resp = client.messages.create(
            model="claude-opus-4-8", max_tokens=4096,
            thinking={"type": "adaptive"}, tools=TOOLS, messages=messages,
        )
        if resp.stop_reason == "end_turn":
            return next(b.text for b in resp.content if b.type == "text")
        messages.append({"role": "assistant", "content": resp.content})
        results = [{
            "type": "tool_result", "tool_use_id": b.id,
            "content": web_search(**b.input),
        } for b in resp.content if b.type == "tool_use"]
        messages.append({"role": "user", "content": results})
    return "Research did not complete within the step budget."

The hardcoded parts (accepting input, capping steps, formatting the request) are testable and predictable. The agentic part (which queries to run, when the brief is complete) is exactly where a fixed pipeline would fail, because you cannot know in advance what searches a given product needs.

Reliability techniques

Model-driven control introduces variance, so agentic workflows need reliability engineering that pipelines do not.

  • Checkpoints. Save state after each step so a failed run resumes instead of restarting. On a five-step research task, losing step four to a timeout should not cost you steps one through three.
  • Retries with backoff. Tool calls hit the network. Wrap them so a transient failure retries rather than aborting the whole workflow. Return the error to the model as an observation so it can adapt.
  • Step and cost budgets. Cap the number of loop iterations and, where possible, the token spend. An agentic workflow with no ceiling is a runaway bill waiting to happen.
  • Human-in-the-loop gates. For any step that is destructive or irreversible, pause and require approval before acting. Reading a web page runs freely; sending a customer email waits for a human.
  • Observability. You cannot debug an agentic workflow by reading code, because the code did not decide the path. Log every decision, tool call, and observation so you can replay a run and see where it went wrong.

The reliability effort scales with how much control you hand the model. A routing workflow with one decision needs little. A wide-open agent loop needs all of the above.

Where to draw the line

The best agentic workflows are mostly not agentic. They are conventional pipelines with model-driven decisions inserted precisely where the input is genuinely uncertain. That gives you the testability of code and the adaptability of an agent without paying the full cost of either.

When you do hand the model control, the thing that most affects reliability is the quality of what it observes. A workflow reasoning over clean web content makes better decisions than one squinting at raw HTML. For the mechanics of building the loop itself, see how to build an AI agent.


Build agentic workflows on a solid data layer. Try link.sc free and give your workflow clean web search and fetch from one API.