Build Your Own Agent Loop — The Minimal Shape of Tool Calling

At the center of every AI agent is a single while loop. We build it from scratch without a framework — the shape of JSON function calls, what ReAct actually left behind, and the stopping conditions where nearly every incident originates.

ReAct: Synergizing Reasoning and Acting in Language Models

The assistant on the phone

Picture asking a very knowledgeable assistant for help — over the phone. They have no hands and no eyes in your room; all they get is your voice. So they say "could you read out what's in that folder?", you read it out, and based on what they hear they tell you what to do next. A few rounds of that, and the job is done.

That is what we currently call an AI agent. A language model is a function from strings to strings. It cannot open a file or send an email. Something outside the model always does the actual work. The core value an agent framework provides is a dozen lines that automate this back-and-forth.

This article builds that loop without a framework. The goal isn't working code you can copy — it's being able to say which line, if you delete it, breaks what.

It's a while loop

Here's the conclusion up front. This is the whole thing:

messages = [{"role": "user", "content": task}]
while True:
    reply = model(messages, tools=TOOLS)     # 1. let it think
    messages.append(assistant_turn(reply))   # 2. append its turn
    calls = tool_calls_in(reply)
    if not calls:                            # 3. no tool = done
        return text_of(reply)
    results = [run(c) for c in calls]        # 4. we do the work
    messages.append(user_turn(results))      # 5. append the results

The word "agent" deserves to lose some of its magic right here. The model is not persistently pursuing anything. On every turn it reads the whole conversation from a cold start, emits exactly one next move, and stops. The thing with continuity is the messages array; nothing carries over on the model's side.

That asymmetry decides most of the design questions that follow. Because the history is the only memory, anything you didn't write into it doesn't exist for the model, every extra step inflates the input, and a failure will repeat unless you write down why it failed.

There are only four parts: the tool list, the model call, the dispatcher (the table mapping tool names to real functions), and the stopping conditions.

How to describe a tool

Handing a model a tool is, in practice, writing a function signature in JSON.

{
  "name": "read_file",
  "description": "Read one text file in the repository. Paths are relative to the repo root. Not for binary files. If you only need to check existence, use list_dir instead.",
  "input_schema": {
    "type": "object",
    "properties": {
      "path": { "type": "string", "description": "e.g. src/main.py" }
    },
    "required": ["path"]
  }
}

Nearly everyone makes the same mistake once: writing description for a human. The reader here is the model, not a colleague. A clever summary matters far less than "when not to use this", a concrete example of the argument format, and what comes back on failure. It is not unusual for one added sentence to change behavior outright.

Whether the returned JSON is syntactically intact is largely solvable with constrained decoding — zeroing out tokens the grammar forbids before they're sampled. But valid syntax and valid arguments are different things: a nonexistent path arrives as a perfectly well-typed string all the time. That boundary is covered in Structured Output and Constrained Decoding.

Temperature — the parameter governing sampling spread — is usually set lower for an agent loop than for prose. A wobble in the spelling of a tool name means calling a function that doesn't exist, and if the model decides differently every time from the same state, debugging stops working.

That does not make temperature 0 automatically safe. Identical history yields identical output, so once the loop enters a failing state it cannot climb out on its own. Keep it low (roughly 0 to 0.3) and handle stuck states with stopping conditions instead — that's the division of labor in practice.