Lesson 20.120.1 What an agent is, in code

Where this fits. Start here told Ana's question in plain words. This concept tells the same story the way your program sees it: as requests and responses, and five steps that repeat.

In everyday life. A head chef stands at the pass, the counter where finished plates go out, and calls orders: "Two salmon, one with no sauce." She never cooks. The line cooks cook, and they decide whether an order can be made at all: if the salmon has run out, they say so. Each plate goes back to the pass, the chef looks at it, and calls the next order or sends the meal out. In this concept, the chef is the model, the line cooks are your code, and each order is a tool call. It is the advisor from Start here again: the cooks, like you outside her door, may refuse an order.

What you will learn. What an agent looks like inside a program: the five steps it repeats, and the three decisions only your program makes.

Why it matters. Every action an agent takes passes through code you control and can test. That is what makes an agent safe to build.

One request, start to finish. Ana asks: "Which invoices are due this week?" Here is everything that happens:

1. Your code sends the first request (call). It holds the instructions (what the worker is for), the conversation so far (just Ana's question) and the four tools, each with its name, a description and the shape of its inputs.
2. The model answers with a request, not an answer (your code keeps it, and checks why it stopped). It says, in effect: "Please run list_open_invoices with due_on_or_before set to Sunday's date." This is a tool call, and it carries a call id, a unique label for this one request. The model also says why it stopped: it wants a tool.
3. Your code runs the tool (run). It calls the connector (Start here), over MCP, the same way any AI app calls a connector, and gets back ten invoices.
4. Your code adds the result to the conversation (return). The model's request is already there, unchanged, from step 2. After it goes the tool result, your answer to the call, marked with the same call id.
5. Your code sends the second request (call again), with the whole conversation, now three entries long: the question, the model's request and the result.
6. The model answers in words (check: finished). It names ten invoices, $24,927.63 in all, nine of them already late. This time it stopped because it was finished. Your code sees that and ends the loop.

Two calls to the model, one call to a tool. The model did no work on any invoice. It asked, and it read.

What is an agent, in code?

An API (application programming interface) is a way for one program to ask another to do something, over the internet. A model's API has an endpoint, one web address that takes a request and returns a response (Chapter 14 taught the shapes: JSON in, JSON out). An agent, in code, is a loop around that endpoint:

1. Call the model with the instructions, the whole conversation and the tools.
2. Keep what the model sent back by adding it to the conversation.
3. Check why it stopped. If it did not ask for a tool, the loop ends.
4. Run each tool it asked for.
5. Return each result, added to the conversation, then go back to step 1.

Figure 20.4. The loop in five steps. Every agent you have used runs some version of it.

Three things in this loop belong to your code, and only your code:

This is the whole reason an agent can be made safe. Every effect on the world passes through code you wrote, can read and can test.

At work. In Lab 20, Task 3, your coding agent shows you the first API's loop file, in TypeScript and in Python. Before anything runs, you find the five steps in the code (each has a comment, Step 1 to Step 5) and predict which line ends the loop. Then the agent runs Ana's question and prints every request and response, and you match each one to a step.

The operating rule: the model only asks. Read every tool call as a request your code may refuse, and keep every effect in code you can read.