AI agents: loops, tools and guardrails

What makes an agent

Definitions vary, but a practical one has four parts. A goal says what done looks like. A loop lets the model act more than once. Tools let it read or change things outside its own text. Memory keeps what happened in earlier steps so the next decision builds on them.

The key difference from the function calling in lesson 12 is who decides the sequence. In a workflow, your code fixes the steps: retrieve, then generate, then format. In an agent, the model chooses the next step each turn, including which tool to call and when to stop.

That choice is the source of both the power and the trouble. An agent can handle a request you never planned for, and it can also wander, repeat itself or call a tool you did not expect.

The agent loop

Under every agent framework sits the same small loop. You can write it in about twenty lines, and doing so once makes every framework easier to understand.

The model never runs anything itself. It only asks, and your code decides whether and how to carry out the request. That is where every guardrail lives.

A single reply can contain several tool calls at once, for example two note searches with different keywords. Run each one, answer every call with a tool message carrying its matching tool_call_id, and only then call the model again; most APIs reject a conversation where a call was left unanswered.

When a tool fails, do not crash the loop. Send the error back as the tool result in plain words, such as a missing file or an empty search, and let the model try another route or explain the problem to the learner.

• Send the goal, the conversation so far and the tool definitions to the model.
• If the reply contains tool calls, validate the arguments, run each tool and append the results as tool messages.
• Send the longer conversation back and let the model decide the next move.
• Stop when the model replies with plain text and no tool calls, or when a limit is reached.

Memory and state

Short-term memory is simply the message list. Every tool call and result is appended, so the model can see what it already tried. On long tasks this list grows fast, so summarise older steps or drop raw tool output once it has been used.

Long-term memory lives outside the model, in files or a database. For Study Buddy that means the learner's notes, found through the retrieval from lesson 16, and a study plan saved as JSON that the agent reads at the start and updates through a tool.

Keep important state in structured data your code controls, not only in the conversation. A plan stored as a list of days with topics can be validated, shown in the interface and edited by the learner; a plan hidden inside a long chat cannot.

At the start of each session, load the saved plan and put a short summary of it into the system prompt. The agent then knows what the learner covered yesterday without replaying a whole conversation.

Guardrails

Agents fail in predictable ways: endless loops, the same tool called with the same arguments, costs that climb quietly and actions nobody approved. Each guardrail below answers one of these.

Tool results deserve the same suspicion as user input. A web page or a shared note can contain instructions aimed at the model, and an agent that obeys them can misuse every tool you gave it, as lesson 14 showed.

Keep a person in the loop wherever a mistake would be costly. The agent can draft the study plan freely, but saving over an existing plan should wait for the learner to accept the change.

• Cap the number of steps, the total tokens and the wall-clock time for each task.
• Expose only the tools the task needs, and make them read-only unless writing is the point.
• Validate every argument against its schema and an allow-list before running anything.
• Ask the user to confirm actions that send, delete, buy or publish.
• Log each step with the tool name, arguments and result so you can replay what happened.
• Return clear error messages from tools, so the model can recover instead of guessing.

When not to use an agent

If you can write the steps down in advance, write them in code. A fixed workflow is faster, cheaper, easier to test and fails in ways you can predict. Study Buddy's quiz feature, for instance, needs one retrieval and one model call, not an agent.

Agents earn their place when the path depends on what the model finds along the way: researching a topic across several notes, or planning a study week around the gaps a quiz revealed. Even then, start with one agent and two or three tools before trying several agents that talk to each other.

Speed matters too. Every loop turn is another model call, so an agent that needs four steps makes the learner wait four times as long as a single answer would. Where waiting is acceptable, show the steps as they happen so the delay feels like progress.

Frameworks such as LangGraph, AutoGen, Microsoft Agent Framework and the OpenAI Agents SDK add state handling, tracing and multi-agent patterns. They are worth a look once your hand-written loop works and you know exactly what you need from them. For connecting tools, the Model Context Protocol from lesson 12 lets one tool server work with many agents and apps.