Lesson 21.921.9 What an SDK still leaves to you

In everyday life. A washing machine washes by itself, but someone still plumbs it in, decides what goes in it, and notices when it leaks. In this concept, the washing machine is the SDK, and the house is the process, the computer and the credentials it runs with.

What you will learn. What an SDK in your own process does not take over, and which decisions about the computer it runs on stay yours.

Why it matters. A worker started on a developer's computer can pick up that computer's settings, tools and details, unless you decide what it gets.

One request, start to finish. On the lab's first run of the first SDK, before the lab's options were added, Ana's question worked. Then the builder read what the harness had sent to the model:

1. The tool list held more than the worker's five tools. It also listed tools for driving a web browser. They came from the computer's own setup for its coding agent, which the harness read because nothing told it not to.
2. The conversation held a note the worker never wrote, with details of the person signed in on that computer. It came from the environment the program was started in.
3. The request carried settings the lab's code never sets, such as today's date and a description of the computer.
4. The fix was three options and one habit. Read no settings files. Use only the MCP servers you name. Pass the harness only the environment variables it needs. And read one request, or the SDK's record of it, before you trust a worker.

A harness built for a developer's computer uses that computer's setup. A worker is not a developer.

What does an SDK leave to you?

An SDK in your own process takes over the loop. It leaves you the runtime: the process, the computer it runs on, and everything that comes with them. The lab keeps this list in docs/sdk-map.md, and Chapter 22 hands it, item by item, to a hosted platform:

Does your language change what the worker inherits?

One language difference matters for safety. On the first SDK, the option that lists the environment variables replaces the environment in TypeScript, but only adds to it in Python. So in Python the worker could still inherit everything. The lab trims the environment itself, in both languages: Task 5 shows the option, and in Python a small function, isolate_environment(), also trims the program's own environment first.

Figure 21.12. Your process, and what a hosted runtime would take off your hands.

How do you judge another framework?

Judge any agent framework the way this chapter judged two SDKs: map it to the loop, read its defaults, and list what it leaves to you.

At work. Lab 21, Task 15: write what this still leaves to you, one line per row of the table above.

The operating rule: an SDK runs the loop, not your runtime. Decide what the process inherits, where its files and traces go, what it may spend, and how it is upgraded, and write each decision down.

What is harness engineering?

What you just did has a name: harness engineering. A harness is everything around the model: the loop, the tools, the permissions, the checks and the limits. Your Chapter 20 loop was a small harness you built. The first SDK is a harness someone else built, which you shaped mostly by switching things off. The second SDK is a kit for building one, which you shaped mostly by adding to it. Either way, the work of deciding what the harness allows is harness engineering, and it comes down to five verbs:

Each rung of the ladder moves the harness machinery further from your code. The five decisions stay with you on every rung.

Part D in one minute. An SDK in your own process takes the loop and leaves you the runtime (21.9). Chapter 22's hosted runtime takes over most of that list. What counts as done stays yours. Now do Sitting 4.

Now do Lab 21, Sitting 4 on the lab page: Tasks 14 and 15, and the optional Task 13 (about 40 minutes). It ends with your reviewed pull request. Then come back for the reference.