The defining feature of an **AI agent** is iteration, not the model. A plain LLM call is one shot: you send a prompt, you get a completion, the conversation ends from the system's point of view. An agent wraps the same LLM in a loop.
The loop has four moving parts. The model **reasons** about the next step. It chooses a tool, which is a function or API the runtime knows how to execute. The runtime executes the tool and captures the result. That result becomes a new observation in the model's context, and the loop runs again.
This continues until the model declares the goal reached, or until a step budget or cost budget forces a stop. The model is allowed to change its plan mid-run based on what each tool actually returned.
Notice that none of this requires a special model. Any modern LLM with function-calling support can drive an agent loop. The agent is the runtime plus the loop plus the tools, not the weights. That is why option B is correct: the answer hinges on architecture, not on training data or hardware.
An **agent** is an LLM placed inside a loop that lets it choose actions, observe results, and choose again until a goal is reached. A plain LLM call returns one completion and stops. An agent keeps going.
The canonical loop has four moves: reason, act, observe, decide. The model reads the current state, emits a tool call, the runtime executes it, the result is appended to the state, and the model gets another turn. Termination happens when the model signals completion or a budget is hit.
The critical insight is that this is a software architecture pattern, not a model property. The same `gpt-4o` or `claude-3.5-sonnet` can be a plain chatbot in one call. The same model can be an agent in another, depending on whether the runtime gives it tools and lets it iterate.
Options A, C, and D miss this. There is no special training data that makes a model agentic, GPU class is irrelevant, and persistent memory is a feature some agents add but not the defining one.
Quick reference
TL;DR
An agent wraps an LLM in a loop that reasons, calls tools, observes results, and repeats until done. The loop, not the model, is what makes it agentic.
Imagine asking a friend a hard question. A plain LLM call is like getting one shot to answer from memory: you reply once and that is it. An agent is like that same friend with a phone, a search engine, and a calculator. They can think, look something up, check the answer, look up something else, and keep going until they are confident. They are not smarter than before, they just have permission to take more than one step and use tools along the way. The repeating cycle of think, act, observe, decide is what makes a system an agent. Without that cycle, you just have a single answer from a single shot, no matter how powerful the model is.
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.
Calling out the agent label for any system that uses an LLM at all. Most production LLM uses are non-agentic. Reserving the term for true loops keeps the architecture conversation honest.
Trying to make a workflow agentic by switching to a bigger model. The path to agency is adding a loop and tools, not upgrading inference. A larger model in a plain call is still a plain call.
Building an agent when the execution path is fully known up front. A fixed DAG gives bounded cost and latency. Adding a loop just to feel modern wastes tokens and complicates debugging.
Quick scan · 2–4 min
Everything important, quickly.
Start by stating that agency is a runtime architectural property, not a model property. Name the four-move loop, contrast with one-shot calls and fixed chains, walk through why each distractor is wrong, and finish by noting how function calling has made the agent loop easier to implement without changing what makes it an agent.
Real-world examples
Real products, models, and research that use this idea.
1Claude's tool use API lets a single model power both one-shot Q&A and full agent loops, the difference is whether the caller iterates on tool_use results.
2OpenAI's Assistants API exposes a thread with an explicit run loop, making the agent architecture visible in the SDK shape itself.
3LangGraph's prebuilt ReAct agent is essentially a state machine that wraps any function-calling LLM, with no model-side changes required.
4Cursor's coding agent and Devin both use the same frontier models that power chat products, the difference is the agent runtime around them.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QIf a chain calls a single tool and returns, is that an agent? Why or why not?
Sign in or go Pro to see the approach for this follow-up.
QHow does function calling support in modern LLMs change the agent architecture compared to early ReAct prompting?
Sign in or go Pro to see the approach for this follow-up.
QWhat is the smallest possible change to a plain RAG pipeline that turns it into an agent?
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
Confusing model capability with system architecture. Bigger or fine-tuned models do not become agents, the loop with tools and observations is what turns any LLM into an agent.