What is an agent
The word is used for everything from a prompt template to an autonomous system. Being precise about it is the first thing an interviewer checks.
A workable definition
An agent is an LLM that decides its own control flow. It chooses which actions to take and when to stop, rather than following a path you wrote.
That’s the line. If your code decides the sequence of steps, it’s a workflow with LLM calls in it. If the model decides, it’s an agent.
# Workflow - YOU control the flow
summary = llm(f"Summarise: {doc}")
sentiment = llm(f"Sentiment of: {summary}")
return {"summary": summary, "sentiment": sentiment}
# Agent - the MODEL controls the flow
while True:
action = llm(prompt, tools=tools)
if action.is_final:
return action.answer
result = execute(action.tool, action.args)
prompt += f"\n{action.tool} returned: {result}"The second loop might run once or twenty times. You don’t know in advance, and that uncertainty is the entire trade.
The spectrum
Most production systems sit in the middle, not at the autonomous end.
| Level | Who decides | Example |
|---|---|---|
| Single call | you | classify this ticket |
| Chain | you | extract, then summarise, then format |
| Router | model picks a branch, you defined the branches | route to billing / technical / sales |
| Tool-calling loop | model picks tools, you bounded them | answer using search and a calculator |
| Planning agent | model decomposes the task itself | research a topic and write a report |
| Multi-agent | agents delegate to each other | a team of specialised agents |
Move down this list only when the level above genuinely fails. Each step adds non-determinism, cost, latency and debugging difficulty. A router solves more real problems than a planning agent, and it’s far easier to operate.
That progression is the answer interviewers are listening for when they ask “how would you build X” — starting at multi-agent signals inexperience.
When agents earn their cost
| Use an agent | Use a workflow |
|---|---|
| the number of steps is unknown up front | steps are known |
| the path depends on intermediate results | the path is fixed |
| the tool space is large and situational | two or three known calls |
| errors need adaptive recovery | failures are handled by retry logic |
| open-ended research or investigation | extraction, classification, formatting |
Determinism is a feature. If a workflow can do the job, it will be cheaper, faster, testable, and debuggable. Agents are for genuine uncertainty about what to do next.
What it costs
- Latency. Every loop iteration is a full round trip. Ten steps at 2s each is 20 seconds.
- Money. The context grows with each observation, so later iterations are the most expensive. Cost is superlinear in steps.
- Non-determinism. Same input, different path. Regression testing gets hard, and “it worked yesterday” stops being evidence.
- Failure modes you don’t get elsewhere — loops, wrong tool selection, plausible-but-wrong intermediate conclusions compounding. See 07_agent_failure_modes.md.
The components
Every agent framework provides the same four things, whatever it calls them:
- A model that can call tools.
- Tools with schemas — the action space. See 08_function_calling_and_structured_output.md.
- State — what carries between iterations. Usually the message history plus scratch data.
- A loop with a termination condition.
Once you see that, framework differences become questions of ergonomics and what they add around the loop: persistence, streaming, observability, human-in-the-loop.
Do you need a framework
Honest answer: not for a simple loop. The code at the top of this file is a working agent in ten lines.
Frameworks earn their place when you need durable state across restarts, human-in-the-loop approval, streaming intermediate steps to a UI, observability into every model call, or complex multi-agent topology. That’s what LangGraph 1.0 provides — see 03_langchain_langgraph.md.
Starting with a raw loop and adopting a framework when you hit a specific need is a defensible answer, and often the right one.
Interview angle
- “What makes something an agent rather than a workflow?” — who decides the control flow. If your code fixes the sequence it’s a workflow; if the model chooses actions and when to stop, it’s an agent. Everything else follows from that.
- “When would you not use an agent?” — whenever a deterministic workflow suffices. Determinism buys testability, predictable cost and latency, and debuggability. Agents are for genuinely unknown step counts and situational tool choice.
- “Product wants an autonomous multi-agent system. Response?” — ask what the simplest thing that could work is, then walk the ladder: single call, chain, router, bounded tool loop. Most requirements are satisfied by a router or a bounded loop, and each step up costs non-determinism and operational pain.
- “Why is agent cost superlinear in steps?” — each iteration appends observations to the context, so later calls process a larger prompt. Ten steps costs far more than ten times one step.
- “What are the components of an agent?” — a tool-calling model, tool schemas defining the action space, state carried between iterations, and a loop with a termination condition. Frameworks differ in what they wrap around that, not in the core.