What happens when an agentic workflow runs

AI Agents · By Caleb Sakala · May 26, 2026

Every article about agentic workflows says the same thing: an AI agent makes a plan, uses tools, reflects on results, and keeps going until the task is done. That description is correct in the way that saying "a car burns fuel and moves forward" is correct. It tells you nothing about what breaks, where the latency hides, or why the workflow that demo'd perfectly falls apart under real traffic.

This post walks through the execution sequence the same way you'd trace a request through a distributed system. By the end, you'll know where the term "agentic" maps to something real and where it's marketing vocabulary stapled onto a for-loop.

Inside the agentic workflow execution loop

An agentic workflow starts with something boring: a prompt and a tool registry. The LLM receives the user's goal plus a serialized list of every tool it can call, with parameter schemas and descriptions attached. On a typical setup using LangGraph or the Anthropic tool-use API, that tool registry alone can eat 2,000 to 4,000 tokens before the model reads a single word of the task.

Then the loop begins. The model outputs a structured tool call, a JSON object naming the function and its arguments. Here's what that looks like in practice with Anthropic's format:

{
  "type": "tool_use",
  "name": "search_knowledge_base",
  "input": {
    "query": "refund policy for enterprise accounts",
    "max_results": 5
  }
}

The orchestrator validates those arguments against the schema, executes the tool, and feeds the result back into the model's context. The model reads the result, decides whether to call another tool or produce a final answer, and the cycle repeats.

Here's the part that matters for anyone building these in production: every iteration of that loop is a full LLM inference call. With GPT-4o, that's roughly 300-800ms of latency per step depending on output length. A five-step workflow means 2-4 seconds of pure model time, before you add network round-trips to external APIs or database queries. Ten steps crosses 10 seconds easily.

That loop is the entire mechanical reality of an "agentic workflow." Everything else, the planning, the reflection, the tool use, happens inside iterations of that same loop. There is no separate planning module. There is no reflection engine. The LLM is prompted to plan, and it outputs text that looks like a plan. The structure exists in the prompt, not in the architecture.

Most "agentic workflows" in production are sequential pipelines

And that's fine.

Most production systems that companies label as agentic workflows are, mechanically, sequential pipelines with an LLM at one or more steps. Step A extracts data from a document. Step B validates the extraction. Step C drafts a response. Step D submits to a CRM. Each step has a fixed predecessor and successor. The LLM adds flexibility within each step, but the workflow shape is predetermined.

Sequential pipelines are easier to test, easier to monitor, and dramatically more reliable than giving an LLM full control over execution flow. StackAI's 2026 guide to agentic architectures puts it plainly: start with a single agent, and only add multi-agent structure when you have a concrete reason like needing parallelism or permission boundaries. Most teams never move past the single-agent loop.

The honest taxonomy: at one end sits a static pipeline where the LLM handles text generation at a fixed step. At the other sits a fully autonomous agent that writes its own tool calls in whatever order it decides. Almost every production system clusters near the first end. The ones near the second end have approval gates and rollback mechanisms that constrain the autonomy they advertise.

How an agentic workflow breaks (a field guide)

The dramatic failure scenario, an agent going rogue and executing harmful actions, gets all the attention. The real failure modes are duller and more common.

Context window overflow is the quietest killer. Each loop iteration appends tool results to the conversation history. A workflow that calls a search API returning 3,000 tokens per result will fill a 128K context window in roughly 40 iterations. Long before hitting the hard limit, output quality degrades as the model struggles to find relevant information buried in thousands of tokens of tool output. Most frameworks don't apply aggressive summarization between steps by default, and the degradation is gradual enough that it looks like "the model got dumber" rather than a concrete bug.

Tool schema hallucination is the most frustrating. The model invents parameter values that look plausible but don't match the API. A DataForSEO keyword research tool expects a keywords array, and the model passes a keyword string. Here's the kind of mismatch that eats hours of debugging:

# What the tool schema expects
{"keywords": ["agentic workflow", "ai automation"]}

# What the model sends (looks reasonable, breaks silently)
{"keyword": "agentic workflow, ai automation"}

The tool returns an error or, worse, silently returns empty results. This happens more with less-documented tools and more with smaller models.

Then there's cascading hallucination, the production version of compound error. The model generates a plausible but incorrect intermediate result. In the next iteration, it builds on that result. By step five, the final output contains a confidently stated claim that's two derivations removed from anything real. Sedai's engineering team analyzed this pattern in CI/CD pipelines: an agent misclassifying a test failure doesn't produce one wrong output; it cascades into compounding errors downstream, each one harder to trace back to the original misclassification.

Infinite loops round out the list. The model calls the same tool with the same arguments repeatedly because the result doesn't match expectations and it can't figure out a different approach. Orchestration frameworks have max-iteration limits now, but defaults tend to be generous (15-25 iterations) and the wasted compute adds up fast.

What the word "agentic" buys you in practice

Strip away the marketing language, and the genuinely new capability is conditional branching based on LLM judgment. A traditional automation follows a fixed path. An agentic workflow can look at intermediate results and choose a different next step.

That's it.

A customer support workflow that routes tickets to different resolution paths based on LLM-classified urgency is using agentic branching. A content pipeline that generates a draft, evaluates it against quality criteria, and rewrites weak sections is using it too. Each of those is useful. Neither requires the full autonomous-agent architecture that most "agentic workflow" content implies.

A Reddit thread titled "Everyone in my company is discovering that Agentic Workflow is just CI/CD workflows" caught traction because it named something real: the execution model (trigger, run steps, check results, branch or stop) is structurally identical to what CI/CD systems have done for years. The difference is that an LLM replaces the hardcoded conditionals with probabilistic judgment. Whether that trade-off is worth it depends entirely on how much variability your inputs have and how much you can tolerate non-deterministic outputs.

Here's a decision framework for when the trade-off makes sense:

Low input variability, low tolerance for wrong output: don't use agentic branching. Hardcode the logic. Low variability, high tolerance (internal drafts, summaries): optional, saves dev time but adds latency. High variability, low tolerance (financial, compliance): yes, but with human approval gates at every branch. High variability, high tolerance: yes, this is the sweet spot for agentic workflows.

The sweet spot is variable inputs where getting it wrong 5% of the time is acceptable. Outside that quadrant, deterministic pipelines or human-in-the-loop systems are better fits.

Building an agentic workflow that survives production

Forget the architectural taxonomy for a moment. Reliability comes down to tool design, observability, and constrained autonomy, and the order matters.

Tool design comes first because it has a bigger effect on workflow reliability than which agent framework you pick. A well-documented tool with strict input validation will produce better results with a basic ReAct loop than a vague tool description with a sophisticated multi-agent orchestrator.

Consider what happens when a tool's input schema is loose: an automation that needs to look up a customer record might receive customer_id, customerId, id, or customer-id from the LLM, depending on how the model interprets the schema description. One team running automations on Chase Agents cut their workflow failure rate by defining explicit input schemas and success criteria for every MCP server connection, so each tool specified exactly what "valid input" and "done" looked like. The failures that remained were almost entirely LLM reasoning errors, not tool invocation errors, which made debugging tractable.

Observability comes second. Log every tool call, every LLM input and output, every branching decision. When (not if) something produces wrong output, you need the full trace to figure out which iteration went sideways. Sedai's production principle captures this well: if you can't explain a decision, you can't trust it.

Constrained autonomy is the hardest discipline. Give the LLM exactly the tools it needs and nothing else. If the workflow always follows steps A through D with branching only at step C, hardcode steps A, B, and D. Let the LLM handle only the branching decision. Every degree of freedom you hand to the model is a degree of freedom you'll need to test and monitor.

A procurement automation makes this concrete. An unconstrained agent that can both research vendors and initiate purchase orders is one hallucinated "confirm" away from a five-figure mistake. The version built on Chase Agents uses action-type routing: the research step returns purchase recommendation objects that route to an approval step, while only the orchestrator holds tool access to initiate purchase calls. The boundary between "suggest" and "execute" is architecturally enforced, not prompt-enforced. That distinction is the difference between "the agent made a recommendation" and "the agent spent $47,000."

The uncomfortable question

If 90% of production agentic workflows are sequential pipelines with LLM-powered branching at one or two steps, does the word "agentic" describe a real architectural category or a pricing tier?

For builders, the answer doesn't matter much. Focus on the execution loop. Map where you need LLM judgment and where you need deterministic logic. Build the simplest system that handles your input variability.

And log everything. The workflow that runs correctly 94 times out of 100 will ruin your week on run 95, and the only thing that will save you is a trace showing exactly which tool call returned garbage at iteration 3.