Describe the conditions under which choosing an agent architecture is an engineering over-complication, even for an LLM-powered task. What alternative is appropriate and why?
Free · 2 AI evals / day
An **agent** is an LLM placed in a loop that decides its own next step at runtime. That flexibility is powerful, but it is not free. Each step pays for an extra reasoning call, the path can branch in ways you did not plan, and the total cost and time are hard to predict.
Using an agent becomes an engineering mistake when the execution path is fixed. If the same tools always run in the same order, no matter what comes back from each step, there is nothing for the agent to decide. The dynamic routing is dead weight.
The right alternative here is a chain, also called a pipeline or a fixed graph. A chain runs a known sequence of steps every time. It is simpler to write, cheaper to run, faster, and far easier to debug because every run looks the same.
A classic example is a document ingestion flow: extract text, split into chunks, embed, then store. Those four steps never reorder based on results. A chain expresses that perfectly, and an agent would only add cost and unpredictability for no benefit.
The deciding question is simple. Does the next step depend on the current result in a way that needs a decision? If no, use a chain.
An **agent** is the wrong architecture whenever the execution path is fully determined at design time. If the same tools run in the same order on every run, regardless of intermediate results, there is nothing to route dynamically. The agent's defining feature becomes pure overhead.
The appropriate alternative is a chain: a fixed directed graph or pipeline that runs a known sequence of steps. A chain wins on four engineering properties.
First, predictability. A five-node chain always makes five LLM calls. An agent might make five or fifty, which wrecks both your latency SLA and your billing cap. Second, cost. The agent pays an extra reasoning call at each step just to decide what is already known. Third, debuggability. Every chain run has the same shape, so a failure is easy to localise. Fourth, simplicity, because there is no loop, no termination policy, and no stuck-agent detection to maintain.
Clear chain cases include document ingestion, which extracts then chunks then embeds then stores, and basic retrieval augmented generation, which retrieves then generates. The order never branches on results.
The decisive test is one question. Does the next step depend on the current result in a way that requires a runtime decision? If no, reach for a chain.
Quick reference
TL;DR
An agent is the wrong tool when the execution path is fixed at design time. A chain is cheaper, faster, and predictable when nothing needs dynamic routing.
Imagine you need to make tea the same way every morning: boil water, add a bag, pour, steep, remove. You do not hire a chef who decides each step fresh, asks what to do next, and might wander off to grind beans. You just follow the recipe. An agent is the chef: smart, flexible, and great when the next move genuinely depends on what you find. But for a fixed recipe, that flexibility is wasted. Worse, the chef pauses to think before every action, so the tea takes longer and costs more, and some mornings the chef gets confused and makes ten cups. A chain is the recipe card. When you already know the steps and their order, the recipe wins on speed, cost, and the simple comfort that tomorrow's tea looks exactly like today's.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
The execution path branches on intermediate results in ways you cannot enumerate at design time. A static chain cannot express open-ended routing, so a real agent loop is warranted here.
The number of steps to reach the goal is genuinely unknown before the run starts. A fixed graph has a fixed node count, so an unbounded loop with a budget is the right fit.
The task needs the model to plan, observe, and replan against live tool results. That is the defining workload for agency, where a chain would fail to adapt.
You only have a small fixed set of routes to choose between. A conditional chain handles this without the cost and risk of a full agent loop.
Quick scan · 2–4 min
Everything important, quickly.
State the condition (a fixed execution path) in one line, name the chain as the alternative, list the predictability, cost, and debuggability wins, give a concrete ingestion or retrieval example, mention the conditional-branch middle ground, and close with the deciding question about result-dependent next steps.
Real-world examples
Real products, models, and research that use this idea.
1Document ingestion pipelines in LangChain LCEL run extract, chunk, embed, and store as a fixed graph with no loop, because the order never changes.
2Basic retrieval augmented generation over a knowledge base is a two-step chain of retrieve then generate, which production stacks like LlamaIndex express without any agent.
3Teams using LangGraph reserve cyclic loop-back edges for genuinely dynamic tasks and keep linear flows as straight-line graphs to preserve a predictable cost and latency profile.
4A support-ticket triage that classifies then fills a fixed template is a conditional chain, not an agent, even though it calls a model like Claude Opus 4.7 at each node.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhere exactly is the line between a conditional chain and a true agent?
Sign in or go Pro to see the approach for this follow-up.
QHow would you justify migrating an existing agent back to a chain?
Sign in or go Pro to see the approach for this follow-up.
QWhat hybrid keeps a static backbone but allows occasional dynamic steps?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Reaching for an agent because the task uses an LLM. Agency is justified by a dynamic execution path, not by the mere presence of a model in the system.