Understanding AI Agents Through the Brain-Finger Analogy

Overview

You've probably come across buzzwords like tool calling or the idea that agents are just LLMs wired up with tools. Instead of diving straight into definitions, this piece uses a familiar everyday scenario as a way to explain what actually happens inside an AI agent. Along the way, you'll see how the LLM, the tools, and something called a tool executor fit together. This is written for developers who want to genuinely understand the mechanics behind an agent rather than just repeating the terminology, and further along you'll walk through building a minimal agent to see the implementation in practice.

Analogy

Picture yourself ordering food through a delivery app. Walking through this ordinary action will reveal how your brain and your finger cooperate with the app to get a meal ordered, and afterward we'll map every step onto agent terminology.

It starts with your brain telling your finger to launch the food ordering app so you can browse nearby restaurants. Your finger taps the icon, and a list of restaurants appears on the screen.

Then your brain reads through the restaurant names shown on screen and directs your finger to tap on one particular restaurant to pull up its menu. After that, your brain scans the menu items and tells your finger to tap the Add button next to whichever dishes you want, placing them into the cart.

Once that's done, your brain reviews everything sitting in the cart to make sure nothing is missing, then instructs your finger to tap place order.

Finally, your brain recognizes the goal has been reached once it sees the order confirmation screen, and at that point the back-and-forth between brain and finger comes to a close.

Analogy in agentic language

Notice something important throughout this whole sequence: the brain itself never performed a single action directly — it only interpreted incoming information and told the finger what to do next. This maps almost exactly onto how an AI agent operates. The LLM plays the role of the brain; actions like browsing restaurants, opening a menu, adding items to a cart, and placing the order are the tools that the brain knows how to use; and the finger corresponds to the tool executor, the component that actually carries out the action.

When you build an agent for a specific purpose, you define a set of tools and hand that list to the LLM, which acts as the decision-making brain. (From here on, -> is used to mean one step passing control to the next.) When a user gives the agent a task to complete, the flow looks like this: the LLM examines the current step or the work still remaining and picks the most relevant tool -> it hands that tool off to the tool executor, asking it to run and report back the outcome -> the LLM reads that outcome and checks whether it satisfies the user's request. If it does, the process stops there; if not, the LLM chooses the next appropriate tool based on the latest result and the loop repeats, continuing until the LLM determines that the task is fully done and no further tool calls are needed.

Implementation

With the concept established, the next step is to construct a small working agent capable of placing a food order based on what a user asks for. The code snippets that follow trace the actual execution path the agent takes, and a link to the full repository is included toward the end.

Tools

get_restaurants() {
    // In production, replace with an API call such as GET /api/v1/restaurants
  return list of restaurants;
}

get_menu(restaurantName) {
    // In production, replace with an API call such as GET /api/v1/restaurants/${restaurantName or restaurantId}/menu
  return menuItems;
}

add_to_cart(sessionId, menuItemId) {
  // In production, replace with an API call such as POST /api/v1/cart
  return updatedCart;
}

place_order(sessionId) {
  // In production, replace with an API call such as POST /api/v1/order
  return orderDetails;
}

Notice that these tools are nothing more than ordinary functions of the kind you'd write in everyday application code — there's no special agent framework or LLM-specific logic baked into them. In a real production setup, every tool would additionally carry a name, a description, and a defined input schema describing what data it expects. It's this name and description that the LLM relies on to figure out which tool best matches whatever the user is asking for.

Tool executor

toolExecutor(toolCall) {
  const tool = toolNameMap[toolCall.name];

  return tool.execute(toolCall.arguments);
}

The tool executor itself is just another plain function. Its toolCall argument carries information about the tool being invoked — the name and its arguments — and these vary depending on which tool is called, whether that's a restaurant name, a menu item ID, or something else entirely. The key point is that when the LLM tells the executor which tool to run, it hands back precise, structured details, such as tool name get_menu with argument {restaurantName: "Spicy Pizza"}. There's no need to manually extract or parse this information from the LLM's raw text output.

Agent

// Give all the tools to the LLM
llm = OpenAILLM.bindTools([get_restaurants, get_menu, add_to_cart, place_order])

// Take the user query to run the agent loop
reactAgent(userInput) {
  while (true) {
    response = llm(userInput);

    if (response.isFinalAnswer) {
      return response.answer;
    }

    result = toolExecutor(response.toolCall);

    userInput = response + result;
  }
}

Things to observe from the pseudocode

1. The name reactAgent refers to the ReAct (Reason and Act) prompting pattern, in which the LLM decides on a tool to call, observes the outcome of that call, and then determines whether another tool needs to run or whether the task is complete and the loop can stop.
2. Pay attention to the while(true) loop. This is precisely where agents diverge from the conditional logic you'd normally write in languages like Java or Python. Rather than hardcoding function calls inside if-else branches or for-loops, you expose a set of tools to the LLM — each with a name and description — and let the LLM itself decide, at runtime, which tool to invoke next, what arguments to pass, and when the work is done and the loop should exit.
3. That said, production systems don't actually rely on a raw while(true) loop; it's used here purely to illustrate the underlying agentic behavior in simple code. In practice, you'd reach for an orchestration framework such as LangGraph. Even with a framework like that, it's standard practice to cap the recursion depth so the LLM can't be called indefinitely — an unbounded loop risks bugs, wasted tokens, and unnecessary cost.
4. The response.isFinalAnswer check in the pseudocode signals that the agent has reasoned its way to a complete answer and no further tool calls are needed. Once that happens, the agent returns a summarized response to the user instead of triggering another tool.
5. You may also have noticed the line userInput = response + result, where the combined output is fed back into the LLM as response = llm(userInput) on the following iteration. This happens because each LLM call is stateless — it retains no memory of earlier turns, even within the same session or user interaction. Consequently, every time a tool finishes executing, you need to resend the full conversation history: the system prompt describing how the agent should behave, the original user query, the AI's prior response suggesting a tool call, and the result that tool produced. The LLM then processes this entire sequence to judge whether the goal has been met or whether more tool calls are required.

LLM and tool execution sequence diagram

The diagram below walks through how the LLM chooses the next tool, how the tool executor runs it, and how this cycle repeats until the LLM concludes that the task is finished and no further tool execution is necessary.

The described flow shows the back-and-forth clearly: the LLM proposes a call, the executor performs it, the result flows back to the LLM, and the LLM either proposes another call or ends the loop with a final answer.

GitHub code

A repository with starter code is available if you want to run this example yourself and watch the agent loop in action.