LLM Agents: How a Loop of Model and Tools Replaced the Chatbot

Three dates define the modern LLM agent: 2022, when the paper on the ReAct approach came out; June 2023, when OpenAI added function calling to its API; and November 2024, when Anthropic introduced MCP, a protocol for connecting tools. Habr has published a piece on how an agent built on top of an LLM works. The author says upfront that the piece will not discuss transformer architecture and looks at the system from a practical angle. The RSS announcement includes only the introduction, so below we lay out the general scheme most agents rely on, without retelling the details of the article itself.

A Loop Instead of a Single Answer

An ordinary chat is simple: the user asks a question and the model answers. An agent works differently. The model receives a task and a list of available tools, then decides what to do: answer right away or call a function. The result of the call goes back into the context, and the model takes the next step. This continues until the model considers the task done or until external code breaks the loop.

The model itself executes nothing. It emits a structured request, for example a function name and arguments in JSON. An ordinary program, called the orchestrator or runtime, carries it out. That is where the logic for retries, timeouts and limits lives.

What an Agent Is Made Of

Most implementations use a similar set of components, whether it is hand-written code or an off-the-shelf framework:

• Model: takes the context and returns either text or a tool call.
• Tools: functions with a text description and an argument schema. Search, SQL, shell, a browser, internal APIs.
• Memory: the history of steps inside the context window, plus external storage such as a vector database or files.
• Orchestrator: ordinary code that runs the loop, validates calls and keeps logs.
• Stop condition: the model's final answer, a step limit or a token budget.

MCP deserves a separate mention. The protocol defines a single way to describe tools and resources, and the same server can be connected to different clients. For developers, this lowers the cost of integrations: a tool description is written once.

Where Agents Break

Problems usually arise not in the model itself but around it. The first common failure is that the agent gets stuck in a loop: it calls the same tool with the same arguments and expects a different result. The second is that the context grows with every step. Tool outputs, especially long dumps, push out important instructions, and each subsequent step costs more. The third is that errors accumulate. If the probability of a correct step is 95%, then only about 60% of runs will get through ten steps in a row without an error. That is why long chains without checks perform noticeably worse than short ones.

Another risk involves permissions. An agent with access to a shell or a database executes whatever the model proposes, and the model can be nudged by bad input or by text from a web page that ends up in the context.

How to Build Your Own

Start with a minimal loop on a single model and two or three tools. A hard step limit and a token budget are needed from day one, as is a log of every call with its arguments and response: without it, debugging turns into guesswork. Dangerous actions such as writing, deleting and payments are better routed through human confirmation. Tool results should be trimmed and summarized before they enter the context. Frameworks come in handy later, once it is clear which parts of the loop really need to be made more complex. The author publishes the full breakdown with examples on Habr, and that is where to look for implementation specifics.