When NOT to Build an Agent Loop: Workflows vs Agents

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 10)

▶ Watch on YouTube & subscribe to The Stack Underflow

Somewhere in every team that just discovered agents, someone wires up a loop for a task that never needed one — a single lookup, a single transform, a single formatted reply — and now that one straight line costs three model calls, carries loop-termination risk, and takes twice as long to debug. The agent didn’t make the task better. It made the task an agent’s problem instead of a prompt’s problem. Knowing when not to reach for a loop is as much a part of agentic architecture as knowing how to build one, and it’s exactly the kind of judgment call the Claude Certified Architect exam tests.

The one-sentence version: If the task is one deterministic step with no tools, no iteration, and no external state to track, a single-shot prompt is the right architecture — an agent loop is overhead you’re paying for nothing.

The question

When is a single-shot prompt the RIGHT choice over an agent loop?

• A) Always
• B) When the task is deterministic, one step, needs no tools or state
• C) Never
• D) When the model is large

Pause here and pick an answer before you scroll — the reasoning matters more than the letter.

The answer

The correct answer is B — a single-shot prompt is the right choice when the task is deterministic, resolves in one step, and needs no tools or external state.

The mechanism is a decision, not a preference. Before you scaffold think→act→observe, ask one question: does this task actually need tools, iteration, or state that persists across steps? If the answer is no, a loop only adds latency, cost, and new failure modes (a bad tool call, a runaway iteration, a lost observation) to a job that was already solvable in a single forward pass.

                 ┌───────────────────────────────┐
                 │  Does the task need:           │
                 │  - tool calls?                 │
                 │  - multiple iterative steps?    │
                 │  - external / persisted state?  │
                 └───────────────┬────────────────┘
                                  │
                 ┌────────────────┴────────────────┐
                 │                                  │
                NO                                 YES
                 │                                  │
                 ▼                                  ▼
      ┌─────────────────────┐          ┌─────────────────────────┐
      │   SINGLE-SHOT PROMPT │          │       AGENT LOOP          │
      │   input → model →    │          │  THINK → ACT → OBSERVE →  │
      │   output              │          │  THINK → ... → DONE       │
      │   cheap, fast,        │          │  tools, state, retries,   │
      │   deterministic       │          │  termination checks       │
      └─────────────────────┘          └─────────────────────────┘

      "Classify this ticket"          "Investigate this ticket,
      "Summarize this paragraph"       pull logs, check the DB,
      "Translate this string"          escalate if unresolved"

Classifying a support ticket into one of five categories, reformatting a JSON blob, translating a sentence, extracting a field from a fixed-format document — none of these need a second model call to check their own work, a tool to fetch outside data, or memory of what happened three turns ago. They’re a straight line: input in, output out. Wrapping that in an agent loop means you now have to design a stop condition for something that was already finished after step one — see Why Your Agent Loops Forever for what happens when that stop condition is missing or wrong.

Why the other options fail

• A) Always — this collapses the decision into a slogan. If “always” were true, agent loops would never exist, and the exam explicitly tests the domains where they’re necessary: multi-step tool use, orchestration, iterative retrieval. Single-shot prompts are right conditionally, not universally.
• C) Never — the opposite overcorrection. Some architects, burned by watching agents mis-fire, conclude every task deserves the safety net of iteration and self-checking. That’s how a one-line classification task ends up costing 4x the tokens and 4x the latency for identical output quality. “Never” ignores that the loop’s machinery (tool calls, observation, termination checks) exists to solve problems a single pass genuinely can’t — and imposing it on problems that don’t have those problems is waste, not caution.
• D) When the model is large — model size is orthogonal to this decision. A large model still can’t call an external tool, check a database, or track state across turns without the agentic scaffolding around it — size doesn’t substitute for architecture. Conversely, a small model handling a deterministic one-step task is often the better choice on cost grounds (see the model-routing pattern in The Cheapest Way to Cut Agent Cost). Model size answers “how capable,” not “does this need a loop.”

The concept behind it

This question is really asking you to distinguish two architectures that get conflated constantly: workflows and agents.

The distinction Anthropic’s own agent-building guidance draws is between workflows — predefined code paths that may call an LLM once or a few times in a fixed sequence — and agents, where the model dynamically directs its own steps and tool use to reach a goal. A single-shot prompt is the degenerate, one-step case of a workflow. The architectural skill isn’t “can I build an agent for this” — you almost always can — it’s “does this task’s uncertainty justify the loop’s overhead.” Deterministic tasks (fixed inputs, fixed transform, fixed output shape) don’t have that uncertainty. Open-ended tasks (find the root cause, resolve the ticket, plan the trip) do, because the number of steps and the tools needed aren’t knowable in advance.

This is the same judgment call that shows up throughout D1. The agent loop only earns its keep when the loop’s parts are actually doing work: observation feedback closing the think-act-observe cycle, a termination condition bounding the iteration, state that needs to persist. Strip all three away and what’s left is a single-shot prompt wearing an agent costume. On the exam, and in production, the tell is always the same: read the task, not the tooling available to you, and ask whether iteration and tools are solving a real problem or just adding ceremony.

A practical checklist for the “do I need a loop” call:

1. Fixed number of steps, known in advance? → workflow (possibly single-shot).
2. Model must decide what to do next based on what just happened? → agent loop.
3. No tools required, output derivable from input alone? → single-shot.
4. State must persist across multiple exchanges or sessions? → agent (and probably long-term memory, not just loop iteration).
5. Task could in principle infinite-loop if under-specified? → agent loop, and now you need an explicit stop condition.

If you answer this checklist honestly for a task and land on “one step, no tools, no state,” building a loop anyway isn’t rigor — it’s over-engineering with extra latency and extra failure surface attached.

FAQ

Isn’t an agent always more “capable” than a single-shot prompt, so why not always use one? Capability isn’t free. Every extra loop iteration is another model call that can hallucinate a tool call, misread an observation, or simply cost tokens for no quality gain. On a deterministic task, the loop’s extra capability has nothing to act on — there’s no ambiguity to resolve, no external fact to fetch, no multi-step plan to execute. You’re paying for machinery the task doesn’t use.

How do I tell if a task is “deterministic” versus just simple-looking? Ask whether the same input always produces the same correct output through a fixed transform, and whether that transform needs no information outside the input itself. Classification, formatting, translation, and extraction from a fixed schema usually qualify. If the correct output depends on something not in the prompt — a database lookup, a live API result, a decision that branches based on intermediate findings — it’s not deterministic, and you’re back in agent territory.

Can a “workflow” use tools at all, or does any tool call mean I need a full agent? A workflow can absolutely call a tool — the distinguishing feature is who decides the call sequence. If your code calls the LLM once, then deterministically calls a fixed tool, then calls the LLM again in a hardcoded pipeline, that’s still a workflow: the control flow is fixed at write-time. An agent is what you have when the model decides, at runtime, which tools to call, in what order, and how many times, based on what it observes along the way.

What’s the cost difference in practice? A single-shot classification or extraction call is one prompt, one completion. The equivalent wrapped in an agent loop with tool-checking and self-verification steps commonly runs 2-5x the token cost and multiples the latency, for identical output on a task that had no ambiguity to begin with. That gap is exactly what model routing exploits at the workflow level — the same principle, applied earlier in the pipeline.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This is D1 · Q7 of the Agentic Architecture practice set — the domain worth 27% of the exam, the largest single slice. It pairs directly with The Agent Loop Explained, which covers what happens inside the loop once you’ve decided you need one, and Why Your Agent Loops Forever, which covers the termination guard every loop needs once you’ve built it. For the cost angle on this same decision, see The Cheapest Way to Cut Agent Cost. If you want the full five-domain picture before drilling into more D1 questions, start with the Claude Certified Architect (CCA) Exam Guide. Exam logistics — Pearson VUE, $125, retakes, 60 questions in 120 minutes, a 720/1000 pass bar — are current as of mid-2026; verify them on Anthropic’s official pages before you register. Browse all tutorials for the rest of the series.