Lesson 21.121.1 From your loop to a library

In everyday life. A family that cooks from scratch knows every ingredient. A meal kit saves work, and a caterer saves more, but each step means knowing less about what went into the food. In this concept, cooking from scratch is your loop, the meal kit is a library that runs the loop, and the caterer is a hosted platform.

What you will learn. What each rung above your own loop takes over, and what stays yours on each one.

Why it matters. Each rung saves you work and shows you less of it, and even the smallest one makes choices you did not ask for.

One request, start to finish. Ana asks: "Which invoices are due this week?" The same question goes up three rungs:

1. Your loop (Chapter 20). Your code calls the model, keeps its reply, reads the stop reason, runs list_open_invoices, adds the result and calls again. You can point to every step.
2. A tool runner. A helper in the client library runs the same loop. Your code hands it the instructions, the tools and the question. Steps 2 to 5 are gone from your file.
3. An agent SDK. One call starts a whole agent. It runs the loop and the tools, and keeps or returns the conversation. Your file holds options, not steps.

The answer is the same each time. What changes is how much of the work you can see.

What are a tool runner, a harness and an agent SDK?

A library is code someone else wrote that your program calls. A tool runner is the smallest library for agents: it runs the loop around one model API, and leaves everything else to you. A harness is a bigger piece: the program around a model that runs the loop, offers tools, keeps the conversation, checks permissions and enforces limits. A coding agent is a harness. An agent SDK lets you run a harness, or a loop like it, from your own code. The runtime is what a worker runs on: the process, the computer and the credentials. The provider is the company, or the server, that answers the model calls.

A container is a sealed box on a computer where a program runs with its own files and limited reach.

What did the tool runner choose for you?

Each rung chooses things for you. Even the tool runner did. When the lab ran it, it kept the conversation on the provider's side by default (the stateful mode of Chapter 20.7), until one option changed it. You only find a default like this by reading a request the library sends.

At work. Lab 21, the optional Task 1: the tool runner beside your Chapter 20 loop.

The operating rule: before you climb a rung, write down what the rung will take over, and read one request it sends to check, or, where your program cannot see the requests, the SDK's own record of them (Task 11 shows one).