Agentic Workflows: Why Looping Beats Asking Once

Most people's mental model of using a language model is a text box. You type a question, you get an answer, you move on. One call in, one blob of text out.

For a lot of work that's fine. Fix my grammar. Explain what a semaphore does. Rewrite this so it doesn't sound passive-aggressive. Small task, self-contained answer, and a decent model nails it first try.

Where it falls apart is anything with real depth. Migrate a service off an old database driver. Figure out why churn spiked last quarter. Research five vendors and pick one. Ask for any of those in a single call and you're asking the model to produce a complete answer in one pass, from a frozen snapshot of information, with no way to check whether a word of it is true. That's a rough deal for anyone.

So what makes a workflow "agentic"

The loop. Instead of one prompt and one response, the system makes many model calls, and what happens on call seven depends on what came back from calls one through six.

Four things have to be present:

Iteration, meaning the model gets more than one shot. Tools, so it can actually do something (search, read a file, run code, hit an API) and see what happened. State that survives between steps, whether that's a scratchpad, a task list, or files on disk. And control flow that gets decided as it goes rather than up front.

That last one is the real dividing line, and it's where a lot of things marketed as agents don't qualify. A pipeline that always runs A then B then C is a program that happens to call a model. An agent looks at bad search results and tries a different query. It sees the test suite go red and walks back to fix what it broke.

Patterns you'll see over and over

Reflection is the cheapest one and it works better than it has any right to. Draft, then critique the draft against explicit criteria, then revise. It works because reviewing is an easier job than writing, for models the same as for people.

Planning breaks a big goal into pieces and does them one at a time, so each piece gets a clean context instead of fighting nineteen other concerns inside one prompt.

Tool use is the model going and checking instead of recalling. There's a large gap between a model producing what an API signature probably looks like and a model that just read the docs.

Iterative retrieval means searching, reading, noticing a hole in what you found, and searching again with a better query. Research is naturally iterative, and shoving everything into the prompt up front works against that.

Verification loops are the most reliable pattern here by a wide margin. The output gets checked by something dumb and deterministic, a test suite or a compiler or a schema validator, and the agent iterates until the check passes. The reason this beats everything else is that the feedback is real. Every other pattern in this list relies on a model's opinion of its own work, which is a much softer signal than a stack trace.

Multi-agent setups split work across separate agents with their own prompts, tools, and context. Genuinely useful when the work is parallel. Overkill most of the rest of the time, and I'd treat reaching for it early as a warning sign.

What you get out of it

The biggest thing, by a distance, is that mistakes stop being final. In a single call the error is the output. In a loop it's just an intermediate state that gets fixed on the next pass. The agent writes code, runs it, reads the traceback, patches it. You never see the bug. That one property is most of why agentic coding tools feel so different from pasting code into a chat window, and it's not really a prompting improvement at all, it's an architectural one.

Second: the model gets to touch reality. A direct call answers from training data plus whatever you pasted, both of which are frozen. An agent reads the file that's actually on disk, queries the live table, fetches the page as it exists today. It stops guessing about things it could just go look at. For anything involving your systems or your data or recent events, that's not a nice-to-have.

Then there's the context problem. A single prompt is a fixed budget, and quality sags as the model juggles more things at once. Splitting the work means each piece gets its own budget. A research agent can work through fifty documents across fifty calls without ever holding all fifty in its head.

Two smaller wins worth naming. Multi-step workflows have seams, and seams are where you put logging, review, and approval gates. You can look at the plan before execution starts and require a human to sign off before anything irreversible happens. A single monolithic generation gives you nowhere to stand. And different steps can use different models, so you can route the classification step to something cheap and fast and save the expensive model for the part that's actually hard.

What it costs you

Now the other side, because this is where people get surprised.

Money and time multiply. Twenty calls cost about twenty times one call and take about twenty times as long. It's worse than linear on tokens, actually, because later calls carry accumulated context, so the per-call cost creeps up as the run goes on. Something that felt instant becomes a two minute wait with a bill.

Errors compound, and the math is brutal. Say each step is independently 95% reliable. Chain twenty of them and you're at roughly 36% end to end. Per-step reliability has to be genuinely high before long chains work at all. And it's not just failure, it's propagation: a wrong assumption on step three doesn't announce itself, it gets built on top of for the next five steps. Verification loops mostly exist to fight this.

You can't test it the normal way. Same input, different trajectory, different run. There's no assertion to write. Checking whether a change made things better means sampling many runs and comparing distributions, which is slow, expensive, and less conclusive than you'd like. Teams consistently underestimate how much eval infrastructure an agent needs. I'd say this is the most common reason agent projects stall out somewhere between demo and production.

Agents get stuck. They retry the same broken approach, oscillate between two fixes, or wander down an irrelevant branch for thirty steps. Without hard caps on iterations, wall clock time, and token spend, one confused run can burn real money. Budgets and circuit breakers are not optional.

Security gets much harder, and this is the part that deserves the most attention. Tools mean the model can act. Now combine tool access with exposure to untrusted content: web pages, emails, uploaded documents, third-party API responses. Text the agent reads can contain instructions the agent follows. That's prompt injection, and if the agent also has access to something sensitive and any way to send data outward, injected instructions can walk data out the door.

There are mitigations. Least-privilege tool scopes, allowlists, human approval on irreversible actions, keeping untrusted content away from privileged tools, sandboxed execution. None of them is complete, all of them are work you didn't have to do before, and the blast radius is fundamentally different from a direct call, where the worst case is bad text on a screen rather than a dropped table.

Debugging is a different activity. A bad single response is one artifact you can read. A bad agent run is a forty-step trajectory with tool calls and retrieved documents and intermediate reasoning, where the root cause might be a slightly wrong search query near the start. Tracing tooling helps enormously and you'll want it earlier than you think.

And you now own a distributed system. State, retries, idempotency (what happens when a step runs twice?), partial failure recovery, prompt versioning, concurrency. That's ongoing engineering cost, and it's why so many teams find the prototype was the easy 20%.

Last one, and it's common: plenty of agentic systems are wrapping a task a single good prompt handles fine, and they're slower and more expensive and less reliable for the trouble. The loop should be justified by the task.

Picking between them

Direct call when the task is bounded, the information you need already fits in the prompt, the output is text rather than action, a human can eyeball the result for correctness, and latency matters.

Agentic when the model has to go get information it doesn't have, when the work has real sub-structure, when there's an actual verification signal available, or when you can't know the right path through the problem before you start.

Either way, build up rather than down. Get the single call working, find where it breaks, add the smallest loop that fixes that specific break, measure again. Teams that architect ten agents on day one usually spend their second month deleting eight of them.

The framing that's held up best for me isn't "should this be an agent." It's "what's the smallest loop that makes this reliable," which tends to produce a much less impressive architecture diagram and a much better system.