Skip to course content
Free LangChain course

LangChain for LLM Applications and RAG

Unit 07.04: When an agent is more than you needed

An agent is a loop that decides what to do next. If you already know the sequence, the loop is overhead.

Three of four are chains

The test is whether the sequence depends on results computed during the run.

The code sorts four tasks.

TASKS = [
    ("look up one account and report the balance", "chain",
     "one tool, known in advance"),
    ("answer from documents with citations",       "chain",
     "retrieval then generation, fixed order"),
    ("decide which of 3 tools, then maybe another", "agent",
     "the sequence depends on results"),
    ("classify then route to a fixed handler",     "chain",
     "the routing rule can be written down"),
]

print(f"{'task':46} {'use':7} why")
for task, choice, why in TASKS:
    print(f"{task:46} {choice:7} {why}")

chains = sum(1 for _, c, _ in TASKS if c == "chain")
print(f"\n{chains} of {len(TASKS)} are chains, not agents")

# An agent is a loop that decides what to do next. If you know the sequence in
# advance, a chain does it for one model call instead of several, with no
# stopping condition to get wrong.

"Answer from documents with citations" involves retrieval, a model and a parser, and the order never varies - so it is a chain, and running it as an agent means several model calls to rediscover an order you knew.

Only the third genuinely needs an agent: which tool runs second depends on what the first returned. That is the property, and it is narrower than it usually looks.

The mistake this prevents

The mistake is choosing an agent because the task involves tools. Tools and agents are independent. A chain can call tools in a fixed order; what makes something an agent is that the order is decided at run time.

Takeaway

Use a chain when you know the sequence and an agent only when the sequence depends on run-time results. Tools do not imply an agent.