This content originally appeared on HackerNoon and was authored by Supriya Vijay
Agents can browse the web, write and execute code, coordinate with other agents and reason through multi-step problems autonomously. The demos are impressive. Last year, as I started using agents more and more, to the point that they are now a part of my day-to-day, I wanted to understand them more fundamentally. Before the planning strategies, the memory systems and the multi-agent orchestration, there's a core architectural pattern that everything else is built on. Lilian Weng's excellent breakdown of LLM-powered agents taxonomizes agents into planning, memory, and tool use. I want to go one level deeper, into the execution loop that sits beneath all three, because understanding that foundation makes everything else click.
Most LLM applications follow a predictable path - a user sends a prompt and the model returns a completion. Maybe you chain a few calls together - summarize, then extract, then format. The point is, you, the user, decide the sequence. An agent inverts this - the model decides what happens next.
The Loop
At its core and most simple form, an agent begins like this:
# "What is the population of the 3 largest cities in Japan?"
messages = [system_prompt, user_query]
while not done:
# Send the full conversation history to the model.
response = llm.chat(messages)
# Did the model request a tool call, or did it produce a final answer?
if response.has_tool_call:
# e.g. model requested: web_search("largest cities in Japan by population")
tool_name, tool_args = response.parse_tool_call()
result = run_tool(tool_name, tool_args) # Your code executes the actual function
# Append what happened so the model can see it next iteration
messages.append(response) # The model's reasoning + tool request
messages.append(tool_result(result)) # The search results
else:
# Model decided it has enough info and produced a final answer
final_answer = response.content
done = True
Every iteration has exactly two outcomes: the model either requests a tool call or it produces a final answer. In this simplified version, termination is embedded in the model's output format. As we'll see later, production systems can't rely on the model alone to decide when to stop.
Next, look at the messages list. It grows with every iteration. The model doesn't retain any memory between calls. That means by iteration five or six, the model is processing its original instructions, its own prior reasoning, every tool request it made and every result it got back. A simple query might resolve in two iterations: search, then answer. But a complex one, for example "compare the GDP per capita of every EU member state and tell me which ones grew fastest over the last five years" might take eight or ten. The agent searches, discovers a source doesn't have recent numbers, tries a different one, tabulates results, realizes it missed a country, goes back. Each iteration appends to the transcript. This creates an engineering problem called state accumulation - after enough loops, the context window fills up, the model's earlier reasoning gets pushed out and the agent forgets what it was doing. I've seen agents re-search for data they already found three iterations ago because the earlier results scrolled out of context. Managing this through conversation summarization, sliding context windows or external memory stores is its own deep topic and one of the harder open problems in agent design today.
Lastly - and this is easy to miss - the model never executes anything. The model generates a request ("call web_search with these arguments"), and your runtime is the one executing it, with access to the network and necessary permissions.
The MRKL Systems paper (Karpas et al., 2022) formalized an early version of this pattern: an LLM acting as a router, dispatching subtasks to specialized modules. Every modern framework like LangChain's AgentExecutor, LangGraph's state machines or AutoGPT's planner-executor split to name a few, implements its own variation. The bones are the same.
Tools Are the Agent's Hands
Tools give an agent the ability to affect and interact with the world outside its context window. An agent requests tool calls by generating structured output - typically a function name and arguments. A separate runtime layer parses that request, executes the function, and feeds the result back. This means the agent's capabilities are entirely defined by the tools you expose - an agent with a read_file tool but no write_file tool physically cannot modify your filesystem, regardless of its intent.
Meta's Toolformer paper (Schick et al., 2023) showed that LLMs can learn when and how to invoke tools through self-supervised training. That research points toward tool use baked into model weights. More often than not however, most agents rely on explicit tool definitions and runtime routing. This makes tool design the most consequential engineering work in agent development. Anthropic's documentation on tool use and OpenAI's function calling guide both dedicate significant space to this, and for good reason.
Termination: The Part Nobody Talks About
The loop needs to end at some point.
In the code above, termination looks clean - the model either requests a tool call or produces a final answer. But in practice, models are bad at knowing when to stop. Left unchecked, agents fall into two failure patterns - they loop endlessly, retrying marginally different approaches, or they bail early, returning a half-finished result because the model got confused.
Production systems layer on external safeguards:
- Setting a maximum iteration count, after which the agent stops.
- Cost and token budgets are a more nuanced version of the same idea. Instead of counting loops, you track cumulative token usage or dollar spend. When the agent crosses a threshold, it wraps up. This handles the case where a single iteration burns through a massive tool response - ten iterations with small results is different from three iterations where one returned a 50-page document.
- Structured stop signals force the model to be explicit about its intentions. ReAct-style agents (Yao et al., 2023) are the clearest example: the prompt format requires the model to choose between "Action" (keep going) and "Final Answer" (stop) at every step. If the model doesn't produce one of these exact tokens, the runtime can flag it as ambiguous and intervene. Simple mechanism. Works surprisingly well.
- Human-in-the-loop - the agent pauses at certain actions and asks for approval before proceeding.
So What?
Understanding agents as loop + tools + termination won't make you an expert overnight but it gives you a mental model to build on. Andrew Ng has talked about four agentic design patterns - reflection, tool use, planning and multi-agent collaboration - and each one maps back to a specific extension of this core loop. Reflection adds a self-critique step before the next iteration. Planning decomposes the goal before the loop starts. Multi-agent collaboration runs several loops in parallel or in sequence. The patterns are distinct, but the underlying machinery is what we've been looking at.
Next time someone describes a "multi-agent orchestration framework with autonomous task decomposition," you can ask three questions: where's the loop, what tools does each agent have and how does it know when to stop?
Those three questions will tell you more about an agent system than any architecture diagram.
This content originally appeared on HackerNoon and was authored by Supriya Vijay
Supriya Vijay | Sciencx (2026-07-22T11:28:05+00:00) The Core Execution Loop Behind Modern AI Agents. Retrieved from https://www.scien.cx/2026/07/22/the-core-execution-loop-behind-modern-ai-agents/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.