Agents Are Just Loops

Added: 2026-05-14

[00:00:00]Two lines of setup, one function, and one call. That's a working AI agent. It took a question, figured out it needed a calculator, called a Python function, got the answer, and responded. The whole thing is right here. Two lines of setup, a function you could have written in your sleep, and a single call.

[00:00:22]There's a lot of mystery around AI agents right now. If you go looking for explanations, you'll find words like agentic pipelines, multi-agent coordination, swarm intelligence, and it starts to feel like you need a PhD to build one, but you don't. What you need is to understand one concept, and that concept is a loop. A chatbot generates text. An agent can actually do things, call functions, hit APIs, take actions in the real world. The difference is the loop. Every agent runs on this same mechanism. The model receives your input, decides it needs to do something in the real world like call a function or hidden API, does that thing, looks at the result, and decides if it needs to do more. When it's satisfied, it responds. That's the agent loop. Reason, select, execute, repeat. In this video, I'm going to build four agents, each one a little bit more capable than the last, and you'll see this loop running in real time. All of the code is in a GitHub repo linked in the description. I'll be using the Strands agents SDK. It's open source. It's from AWS. And the thing I like about it is that it's model driven.

[00:01:29]The model decides what to do and when.

[00:01:32]You just give it tools and a prompt.

[00:01:34]Strands works with a bunch of different model providers. In this, I'll be using Claude in Amazon Bedrock, but you could use OpenAI or OAM if you want to run locally for free or about 20 other options. The code stays the same either way. Let's start from the beginning. So, here's the setup. I've got a Python file and let me walk you through what's in it. At the top, we import agent and tool from strands. That's the SDK. Then I define a function called add. It takes two integers and returns their sum. The tool decorator is what turns this regular Python function into something an agent can use. And notice the dock string, add two numbers together. That matters. The model reads that description to figure out when this tool is relevant. Think of it as an instruction manual. you're handing over to the model.

[00:02:23]Then we create the agent passing in our tool and we call it with a question. And there it is. The agent responded with the answer. But what actually happened?

[00:02:33]Let me add one line to make it more visible. See that tool was called printed before the response came back.

[00:02:40]The model looked at the question, decided it needed the ad tool, called our Python function with 42 and 58, got 100 back, and then used that result to write its response. You might have heard this called function calling or tool use. That's all it is. The model asks to run a function and the framework runs it. That's the loop. One cycle. The model thought, acted, and responded.

[00:03:04]That's the whole agent.

[00:03:06]Now, one tool is interesting, but not that useful. So, what happens when the agent has options? Let's give it a few more tools and see. I'll add a letter counter. It takes a word, returns how many letters are in it. Again, just a Python function with a decorator and a dock string and a weather tool. This one actually hits a real API, the National Weather Service, which is free and doesn't need an API key. It takes coordinates, hits the weather API, and pulls out the forecast. The details don't really matter here. The point is just that it's a Python function with a decorator and a dock string, same as the others. Now, I'll give all three tools to one agent. So, the model now has to choose. Let's see if it picks the right one. It picked count letters. It didn't try to use the calculator. It didn't check the weather. It read the dock strings, figured out which tool matched the question and called the right one.

[00:04:00]Now, it picked the weather tool. It even figured out the latitude and longitude for Miami on its own. And I didn't give it those coordinates. It inferred them from the location alone. What happens when a question needs more than one tool? Well, it chained two tools together. The model decided it needed the calculator for the first part and the letter counter for the second part.

[00:04:20]Called them both in sequence and wo both results into one answer. I didn't write any routing logic for that. I didn't tell it which tool to use first. The model figured out the plan on its own by reading those dock strings. This is the thing about tool design that took me a little while to internalize. Your dock strings are the API contract between you and the model. If you write a vague dock string, you'll get a vague tool selection. If you write a clear one, the model knows exactly when to reach for it. So better descriptions can lead to better behavior. So we've seen the loop work, but so far we've been taking it on faith that the model is making these decisions. Hooks let you actually watch it happen. Strands has a hook system that lets you subscribe to events in the agents life cycle. I'm going to add two hooks, one that fires before his tool is called and one that fires after. The event object gives us the tool name and the inputs the model chose. That's what we're printing out. Now, when the agent runs, we see every decision it makes in the terminal. Let's try that multi-tool question again. There it is. You can see every step. The model chose add first with input seven and six. Got the result. Then it chose count letters with the word 42. Got that result. Then it combined the final answer from both.

[00:05:36]Nothing is hidden. You can see the loop cycling. The model thinks, picks a tool, the tool runs, the result goes back to the model, and it decides what to do next. Once you can see it, you can debug it. You can reason what went wrong when the agent picks the wrong tool or figure out why it's looping. It's just code at that point. Let's give it something ambiguous and see how it handles it.

[00:05:59]Watch how it breaks this down. It needs to know the length of the word, so it calls count letters. But for the number comparison, it doesn't need a tool. It already knows that the words 42 represents the number 42. So, it reasons through that part on its own and gives you the answer. The model decides when to use a tool and when it already has enough information. All right, last one.

[00:06:21]What happens when one agent isn't enough? The answer is you make agents that use other agents. It's the same loop just nested. I'm going to create two specialist agents. a math tutor that's patient and shows the work and a writing helper that gives simple grammar advice. Each one is wrapped as a tool using the same tool decorator we've been using. Then I create an orchestrator, an agent whose job it is to wrap questions to the right specialist. The orchestrator doesn't know maths. It doesn't know grammar. It knows which agent does. When a maths question comes in, it calls math tutor which spins up its own agent with its own loop. When a writing question comes in, it calls writing helper. And it's the same pattern we've been using. So, it's tools all the way down. The orchestrator recognized this as a maths question and routed it to the math tutor. The math tutor ran its own loop, used the ad tool to work through the calculation, and sent the result back up. And this one went to the writing helper. The orchestrator read the dock strings, picked up the right specialist, and let it handle the work. So, it's the same loop just nested. The orchestrator's loop calls a tool. That tool happens to be another agent and that agent runs its own loop. You can stack these as deep as you need to. The pattern is the same. So let's zoom out. We built four things today. An agent with one tool, an agent with multiple tools that the model chooses between, the same agent with hooks so you can watch every decision, and an orchestrator that routes to specialist agents. All four run on the same mechanism. The model receives input, decides if it needs a tool, runs the tool, gets the result, and decides what to do next. And the thing about this loop is that it doesn't change based on where you run it. The same code works on your laptop, in a container, in a serverless function, or on managed infrastructure like Amazon Bedrock agent core runtime. If you want to see what it looks like to take an agent like this to production, Morgan has a great walkthrough on deploying to agent core runtime and another one on production agent architectures. I'll link both in the description for you, but the starting point is always the same. A loop, some tools, and a model that figures out the rest. All of the code from today is in the GitHub repo linked below. Clone it, run the demos, break some things. If you want to try it out without an AWS account, strands works with Olama, which runs models locally for free. You don't need to understand everything about AI to build an agent.

[00:08:45]You need to understand the loop, and now you do. If this was helpful, subscribe and let me know in the comments what you're going to build. I'll see you next time.