After this topic
You will be able to explain an agent without waving at “autonomy”: it is the same next-token model, allowed to request your functions, looking at the results, and repeating until it can write a final answer — or until you stop it.
If someone asks “is the agent thinking?”, you will have a precise answer: it is choosing tokens. Some of those tokens happen to be “call this tool with these arguments.”
Why a single completion is not enough
A chat model only sees the messages you send. It cannot fetch weather, read your database, or charge a card — unless you run that code and put the result on the thread.
A chat model only sees the messages you send. It cannot fetch the weather, read your database, or charge a card. If the user asks “what’s the weather in Berlin and Paris, then tell me which is warmer?”, a model with no tools will guess two temperatures. That is the Day 1 failure mode again: likely text, not live data.
Giving it one tool call is still not enough. It may need Berlin, then Paris, then a sentence that compares them. That is two calls plus a final answer — three model steps. One generateText with no loop cannot do that. You would have to orchestrate it by hand.
An agent is that orchestration, handed back to the model: “here are tools you may call; call them until you can answer.” You still write the tools. You still cap the loop. The model chooses when to call and what to say at the end.
The loop, step by step
Start with the same messages array you already know. On each step the model either (a) emits tool calls — a name plus JSON arguments — or (b) emits a normal assistant message and we are done.
If it is (a), your server runs execute for each call. The results are appended to the thread (as tool messages). Then you call the model again, with that richer list. It can call more tools, or it can answer.
In AI SDK v6 you do not write that while-loop yourself for the common case. streamText (or generateText) plus a tools map plus stopWhen: stepCountIs(n) is the loop. n is a budget: how many model steps you will pay for before you cut it off. Without a cap, a confused model can call tools until the bill hurts.
- The model sees the thread (and tool definitions)
- It either writes a final answer or requests tool calls
- Your execute functions run on the server — the model never sees that code
- Results go back on the thread
- Repeat until an answer, or until stopWhen fires
What this is not
It is not a separate kind of neural net. Same next-token model as Day 1. Tools are how you put truth into the thread.
It is not the model running JavaScript. execute is your function. If that function deletes a row, you deleted a row. Guard destructive tools (human-in-the-loop) when that matters.
It is not infinite memory. Every tool result is more tokens in the next step. Long agent runs are a context problem — that is the next chapter.
It is not “autonomous” in the sci-fi sense. It stops when you say so. A missing stopWhen is a production incident, not a feature.
What you will write next
The following topic is the Route Handler: streamText, a weather tool with a Zod schema, stopWhen: stepCountIs(5), toUIMessageStreamResponse(). Same delivery as streaming chat. The new part is the tools map.
Related patterns
Docs
Official API reference for this chapter.
Common questions
- What is an agent loop?
- An agent loop lets the model call tools repeatedly until it can produce a final answer.
- What will I be able to do after this lesson?
- You will be able to explain an agent without waving at “autonomy”: it is the same next-token model, allowed to request your functions, looking at the results, and repeating until it can write a final answer — or until you stop it.
- How long does this lesson take?
- About 18 minutes of reading. It is a free chapter in the AI SDK Patterns TypeScript course.
Written by Akash Panchal·Updated August 29, 2026