Building an AI agent when you do not need one is like hiring a team of 10 people for a job one person can do.
Most engineers I see make this mistake in one of two ways.
Either they reach for an agent immediately, before they have even thought about whether the task needs one. Or they stick to chains for
everything because agents feel complex and unpredictable.
Both are wrong. And the cost of getting this wrong is real.
What is actually happening under the hood
An agent runs a minimum of 3 to 10 LLM calls per task. Often more. Each one costs tokens, adds latency, and introduces a point of failure. A chain runs one LLM call and moves on.
If your task has a fixed, predictable path, you just paid 10x for nothing. And you made your system harder to debug in production because now you have 10 things that could have gone wrong instead of one.
But if your task requires the system to look at what it just found and decide what to do next, a chain physically cannot do that. You have to hardcode every possible path upfront. Which means you are not building a chain. You are building a maze with no exits.
So the question is not "should I use an agent?" The question is one thing: does the next step depend on what the previous step returned?
If yes, you need an agent. The path cannot be defined upfront.
If no, use a chain. Same steps, same order, every time. Faster, cheaper, and fully deterministic.
A concrete example so this is not just theory
Say you are building a system that answers questions about Apple's Q3 earnings.
Step one: search for "Q3 2024 earnings Apple". Step two: fetch the top result. Step three: extract revenue numbers. Step four: format as a table.
Same path every run. Every single time. You can write this in 20 lines of Python without any agent infrastructure at all. This is a chain.
Now take a different task. You want the system to research Apple's recent financial performance, but you do not know upfront whether it will find a press release, a news article, or a data source. If it finds a news article, it needs to search for the primary source. If it finds data, it checks whether confidence is high enough or needs cross-referencing. If the numbers conflict across sources, it needs to reconcile them.
You cannot write that decision logic before you see what the search returns. The path through step 2, 3, and 4 depends entirely on what step 1 gave back. This is an agent.
The structure of the task determines which one you need. Not your preference, not what feels more impressive, not what you learned about last week.
The one question to ask before you build anything
Before you decide, run through this mentally:
Can I define the complete execution path right now, before the task runs?
If yes, write a chain. You know every step, every input, every output. There is no dynamic decision to make. An agent adds nothing here except cost and complexity.
Does the task need to look at intermediate results and decide what happens next?
If yes, you need an agent. The path is dynamic. It cannot be fully specified until the task is actually running and producing observations.
Does the task need to pick from multiple tools based on context?
If no, a chain with a fixed set of steps is the right call. Agents are designed for situations where the choice of tool itself is a decision that needs to be made at runtime.
What is the latency requirement?
Agents typically take 5 to 30 seconds for multi-step tasks. A single LLM call takes 0.5 to 2 seconds. If someone is waiting for a response in real time, this matters a lot.
What is the volume?
At 100,000 calls a day, an agent running 3x the LLM calls of a chain at potentially higher token counts can cost 9 times more. That difference is not theoretical. It shows up in your AWS bill at the end of the month.
How this played out in LocusLab
For LocusLab, this decision was clear from day one.
A customer sends an Instagram DM asking what hoodies are in stock. The system searches the Shopify catalog, finds the products, and returns a response. Same sequence every time. That is a chain.
A customer sends a DM asking about their order. The system checks the order status, gets back a result, and then has to decide: is this a delivery issue, a product issue, or does this need a human? Each of those paths triggers different tools and different responses. You cannot write that decision before you see what the order lookup returns. That is an agent.
Two tasks. Same product. Completely different infrastructure. Because the structure of the problem is different, not because one feels more advanced than the other.
Where most people go wrong
The mistake is not choosing agents over chains. The mistake is choosing based on anything other than the structure of the task.
Engineers reach for agents because they want to build something sophisticated. Or they avoid them because they had one go wrong in production and it spooked them. Both of these are the wrong reason.
The engineers who get this right are not the ones who know how to build agents. They are the ones who know when not to.
The short version
Use a chain when the path is fixed, the steps are predictable, and you can define everything upfront. It will be faster, cheaper, and easier to debug.
Use an agent when the next step genuinely depends on what the previous step returned, when the task needs to pick from multiple tools dynamically, or when self-correction is required because a bad intermediate result should change what happens next.
If you can hardcode it, hardcode it. Agents are not a better version of chains. They are a different tool for a different problem.
Top comments (0)