What is an AI Agent?

This is the mechanics post, and the cover signals depth: we're opening the agent and looking at the loop that drives it. Posts 1 and 2 stayed at 'it uses tools and figures things out.' Now we make that concrete enough to build.

The goal is that by the end the reader understands the reason-act-observe cycle, how tool calling works at the JSON level, what the ReAct pattern adds, where short- and long-term memory live, and how the loop decides to stop. This is the engine room that demos gloss over.

The steps slide lays out the loop as a recipe so the reader has the skeleton before the details. Send the goal, available tools, and history to the model; the model returns a thought plus an action; your code executes the chosen tool; you append the result as an observation; repeat until the model emits a final answer instead of a tool call.

The crucial realization is that the model never executes anything itself — it only decides. The actual execution always happens in your runtime. That separation is what every subsequent slide elaborates, and it's where both capability and control live.

The cycle diagram visualizes the loop as the circle it actually is. Reason: decide what to do next. Act: call a tool. Observe: read the result. Check: are we done? If not, loop back to reason. Drawing it as a cycle, not a line, fixes the most common misconception — that an agent runs once.

The 'Check' node is easy to overlook but essential: it's where the agent evaluates whether the goal is met and where your step limit lives. Without that check the loop either never ends or ends too early. The cycle shape makes the repetition, and the exit condition, visually obvious.

This slide explains the mechanics of tool calling, which is the piece newcomers most often picture wrong. You describe each tool to the model as a name, a one-line purpose, and a JSON schema for its arguments. The model does not run the tool. It emits structured JSON naming the tool and the arguments it wants.

Your code parses that JSON, calls the real function, and returns the result for the next turn. This indirection is the entire safety and control story: because the model only requests actions and your code performs them, you decide what's actually allowed to run and can validate every call before it executes.

The flow diagram traces a single tool call round-trip so the reader can map the abstract description to discrete handoffs. The model emits a JSON call; the runtime parses and executes it; the tool returns a result; the result is fed back into the context for the next turn.

Seeing it as a four-node flow clarifies that there are two distinct systems cooperating: the model, which only ever produces text and structured requests, and your runtime, which does everything that touches the real world. The arrow back into context is what makes the next reasoning step aware of what just happened.

This slide introduces ReAct, the pattern that made tool-using agents reliable. ReAct stands for Reasoning plus Acting: on each turn the model writes a short thought explaining its plan, then chooses an action, then reads the observation. The innovation is making the reasoning explicit before acting.

That explicit thought measurably improves which tool the model picks and how it recovers when something goes wrong, because the model commits to a rationale it can then critique. Most modern agent frameworks are ReAct or a refinement of it, so understanding this pattern means understanding the family.

This code slide makes a ReAct turn literal so the reader sees the actual data flowing through the loop. The model's output on one turn is a small structure: a thought, an action naming a tool, and the arguments. Your runtime reads the action, runs web_search with those arguments, and appends an observation containing the result.

Then the loop sends the whole accumulated history back so the model's next thought can build on the observation. Showing the concrete JSON-like shapes demystifies ReAct: it's not a special model mode, just a disciplined way of structuring what the model emits and what you feed back.

This slide locates memory precisely, because 'memory' in agents spans two very different things. Short-term memory is just the running list of messages and observations — and critically, the context window IS that working memory. Everything the agent 'knows' in the moment is whatever currently fits in context.

Long-term memory is separate: a vector store or database the agent can query as a tool to recall things beyond the current window. And because context is finite, a practical agent summarizes or prunes old steps as it fills up. Knowing that the context window is the working memory explains many real-world agent limitations.

The pipeline diagram presents the full anatomy of an agent so the reader can see all four parts in their operating order. The goal enters, the LLM reasons and decides, tools act on the world, memory holds the state and history that flows between steps, and an answer emerges once the goal is met.

Placing this after the tool-calling and memory slides lets it act as a synthesis: the reader has now seen each component up close, and the pipeline shows how they connect into one working system. It's the same four parts from post 1, now arranged as a live flow rather than a static list.

This code slide turns the schematic loop into something close to real, so the reader sees the control flow that posts 1 and 2 only sketched. Messages start with a system prompt and the user goal. A bounded for-loop calls the model with the tools available; if the model returns a tool call, you look up and run the named tool, append both the model's action and the resulting observation, and continue.

The moment the model returns plain text instead of a tool call, you return it as the final answer. The MAX_STEPS bound is highlighted in the comment because an unbounded version of this exact loop is the first mistake in post 5. Post 4 expands this into fully runnable code against a real API.

This slide answers the question the loop raises: how does it ever stop? The primary signal is the model itself — when it returns a normal text response instead of a tool call, it's saying it has enough to answer. That's the natural, model-driven exit.

But you never rely on that alone. You also enforce a hard step limit so a confused or looping agent can't run forever, burning cost and time. So stopping has two parts: the model's judgment that it's done, and your safety ceiling that guarantees termination regardless. Both matter, and the second is non-negotiable in production.

The CTA points from theory to practice. We've covered the reason-act-observe cycle, the JSON mechanics of tool calling, the ReAct pattern, where short- and long-term memory live, and how the loop terminates.

Day 76's teaser promises a real, runnable build. Post 4 assembles everything here into a working tool-using agent you can paste into a file — defining tools, describing them with schemas, running the loop by hand, and then showing the same thing through a framework.