AI Agents From Scratch: The Loop in 38 Lines of Python (No Framework)

0:0046 of the 54 AI engineer job posts I read mention agents or tool calling. 85%. That's partly circular, since agent was one of my search words. But read what they ask for. ZoomInfo wants two years shipping agent loops to production. Not a framework name. The loop. Hiring managers want people who can build it,

0:21and control it. Here's the difference. A chatbot is one call: a question goes in, one answer comes out. An agent is a loop. It looks at the situation, picks a tool, sees the result, and goes again, until the job is done. In the Tool Calling video, our support bot learned to use one tool.

0:44Today, it works a whole refund ticket on its own. By the end, you'll have the loop map, a 38-line Python agent with no framework, tested, the guards that stop runaway loops and bills, and when you shouldn't build an agent at all.

1:04Think of an agent as a new intern with a checklist. You hand them a ticket: a customer wants a refund. The checklist says: look up the ticket, check the order, then write the reply. And the intern can't touch the money. Refunds need the manager's signature. Watch how the intern works. Read the ticket. Decide the next step.

1:27Do it. Look at what came back. Then decide again. Nobody tells them the order for every case. They choose, based on what they find. That's the whole difference. A chatbot answers from what it already knows, in one shot. An agent uses tools, in a loop, and stops when the work is done. Anthropic's guide to building agents says it in one line: agents are typically just LLMs using tools based on

1:55environmental feedback in a loop. Just a loop. That's what we're building today, in plain Python, with no framework.

2:08Here's the whole loop. It starts by observing: the task, and everything that's happened so far, sits in the message list. Then the model thinks: it reads all of it, and picks the next move. Then your code acts: it runs the tool the model asked for. The result goes back into the messages. That's a new observation.

2:27And around it goes. Zoom into think. That's one call to the model, gpt-4o-mini, with the tools attached. The model never runs anything. It only replies with a request: call this tool, with these arguments. In intern terms, the intern writes the next step on a sticky note. Zoom into act and observe. Your code checks the arguments, runs the function, and appends the result as a tool

2:56message, with the same call ID. That message list is the intern's notepad. It's the agent's memory for this task. Now the most important part: the exits. A loop with no way out is a bug. Our agent has four. One: done, when the model answers without asking for a tool. Two: a risky action, like a refund,

3:19pauses for a human. Three: a step limit. Four: a token budget.

3:29Here's agent.py. The OpenAI client, and a system prompt. That's the checklist: look up the ticket, check the order, then write the reply. Refunds need a human. Then three settings: the tools that need a person, a maximum of 8 steps, and a budget of 20,000 tokens. The tools live in tools.py, written the same way as in the Tool Calling video.

3:55Two tools read data: lookup_ticket and check_order. Each has a strict JSON schema, and Pydantic checks the IDs. The third, issue_refund, is listed for the model, but it has no handler. Our loop will never run it. Now the loop. Start the messages with the checklist and the task. Then, for up to 8 steps, think: call gpt-4o-mini with the messages and the tools,

4:21and add up the tokens it used. If the reply has no tool calls, the model is done: return its answer, and the step count. Otherwise, keep its request in the messages, and go through each tool call. If it's an action that needs a human, stop right here, and return what it wants to do.

4:43Anything else, act: our code runs the tool. Then observe: append the result as a tool message. After each step, check the budget. And if we run out of steps, return max steps. That's it. 38 lines. No framework.

5:03Does it work? I ran this exact file with the real OpenAI SDK, against a local test server that plays the model. Ticket T-1042. Step one: the model asks for lookup_ticket. The result: export is broken, the customer wants a refund, and the order is O-5531. Step two: it asks for check_order, on that order. 49 dollars, paid 12 days ago,

5:30refundable. Step three: it asks for issue_refund. The loop stops: needs approval. The refund never ran. A teammate sees exactly what the agent wants to do, and clicks approve. Now ticket T-1050. Same code, same tools. Lookup, then check order: 490 dollars, paid 75 days ago, not refundable. So this time, the model doesn't ask for a refund at all. It writes the reply, and the loop ends:

6:01done, in 3 steps. That's what makes it an agent. Same code, two different paths, chosen by the model from what it observed. And when it makes a mistake, like a ticket ID without the T, the error goes back as an observation, and it retries with T-1042.

6:25Now the part demos skip. Gotcha one: the loop that never ends. A model can keep asking for the same tool, again and again. Every step resends the whole message list, so each turn costs more than the last. Anthropic warns: agents mean higher costs, and the potential for compounding errors. So we have two guards. Max steps: in my test, a model that never stops gets cut

6:52off after exactly 8 requests. And a token budget: at 9,000 tokens a step, the agent stops after step 3, at 27,000. In intern terms: come back to me after 8 tries, and don't spend more than the petty cash. This is real job post language. Elastic's agentic AI engineer role asks for systems that help manage token spending, and identify agent loops.

7:22Gotcha two: human approval for actions that write. Our refund is not a tool the loop can run. It's an exit. The loop pauses, and a human sees the exact action and amount. Okta's posting asks for exactly this: approval screens for agent actions, with clear diffs of what the agent is about to do.

7:47Gotcha three, and interviewers love it: when don't you need an agent? Anthropic splits these systems in two. Workflows: the model and tools follow code paths you wrote. Agents: the model directs its own steps. Here's our triage as a workflow. Look up the ticket. Check the order. The refund rule is an if statement, in your code.

8:10The model is called once, only to write the reply. For a refund ticket, it makes zero model calls. My test checks both. So if every ticket follows the same steps, write the workflow. It's cheaper, faster, and easier to test. Reach for an agent when you can't predict the steps: messy requests, many tools, paths you can't hard-code.

8:33Anthropic's advice: find the simplest solution possible. That might mean not building an agent at all. And frameworks? Only 30% of my job posts name LangChain or LangGraph. Frameworks are fine, but they're built on this same loop. Anthropic's advice: start with the LLM API directly, and if you use a framework, understand the code underneath.

9:04Here's the whole loop again. Observe the messages. Think: one model call. Act: your code runs the tool. Observe the result. And four exits: done, human approval, max steps, and a budget. If an interviewer asks you to explain agents, here's your checklist. One: a chatbot is one call; an agent is a loop with tools. Two: the model only asks for tools;

9:29your code runs them. Three: the message list is the agent's memory. Four: every loop needs exits: done, human approval, max steps, and a budget. Five: if the steps are fixed, use a workflow. Or, in one line: frameworks are optional. The loop is the skill. All week, the Shorts zoom into each piece of this loop.

9:52The code is linked below. Next deep dive: the harness around the agent. Subscribe, so you don't miss it.