You can now describe what you want, and your agent can build it. But sooner or later you ask for something the agent can't just write — read a real PDF, crunch a column of numbers, fetch a live page, draw a chart from actual data. That's the moment your agent needs a real tool. This lesson is about how it gets one, and how you can tell it got a safe one.
You already met the engine — the sealed room where a workbook runs with only the powers you handed it. Hold onto that, because it's the reason this lesson can make a promise most software can't: your agent can pick up powerful, unfamiliar tools without you having to trust their authors with your machine.
the thing yoUr agent reAches for iS a toolkit
When your agent needs an ability it doesn't already have, it reaches for a toolkit. A toolkit is one packaged ability — “turn a spreadsheet into a chart,” “pull the text out of a PDF,” “scrape a web page” — bundled so the agent can find it, learn to use it, and run it safely.
Here's the part worth slowing down on. Out in the wider world, a useful tool is really three things that arrive separately, and you're left to glue them together:
- Code that runs — the actual working program that does the job.
- A safe place to run it — so the program can't wander off and touch the rest of your machine.
- An explanation of how to use it — instructions, examples, what it's for, when to reach for it.
Today those three come from three different places. You install code from one ecosystem, hope its safety story checks out, and read whatever documentation happened to ship with it. A toolkit's whole idea is that those three were never meant to be separate. It ships them as one object: the program, the manual, and the sandbox-shaped wrapper, bound together.
the threE layerS, in plaIn terms
You don't have to build a toolkit to use your agent well — but knowing its three layers tells you exactly what to expect when your agent picks one up.
The manual — the part that's just words. The top of a toolkit is plain text: a short set of documents saying what the tool does, when to reach for it, and how each command works, with worked examples. You read it like documentation. Your agent reads it like instructions — enough to discover the tool and use it correctly. Same words, both audiences. If you've ever handed an AI assistant a “skill file,” this is that, taken all the way.
The muscle — the actual program. Underneath the manual is a real working program, not a description of one. It's written in whatever language suited the job, then compiled into the same portable form that runs inside every web browser. The point isn't to reinvent software — a library that's existed for decades becomes a toolkit by being brought across, not rewritten.
The floor — the sandbox. A toolkit runs inside the engine's sealed room, with exactly the capabilities it was granted and nothing more. This is the quiet part that matters most. Installing an ordinary tool means trusting its author with your whole machine. Running a toolkit means trusting it with exactly what you handed it — a sealed compartment and a short list of grants. The floor is the same engine you already learned about, doing the vetting underneath every ability your agent uses.
Why the manual is the connection
Here's the design choice that makes toolkits feel different from the plugins and integrations you may have seen before.
It turns out AI agents don't work best with a hundred bespoke, custom-built connections. They work best the way a person at a keyboard does: with one general way to run small programs, and good notes on what each one does. So a toolkit doesn't bolt a new protocol onto your agent. It puts a command where the agent can find it, and the manual right next to it.
And because that manual is structured text rather than loose prose, it does double duty: it documents the tool for you, and it's precise enough to act as the tool's instructions for the agent. The documentation can't quietly drift out of date, because the documentation is how the tool is reached. There's no second, hidden source to fall out of sync — which means when you read what a toolkit claims to do, you're reading the same thing your agent reads.
“isn'T this juSt a plugIn?”
Fair question, and the honest answer is that every familiar alternative solves one of the three layers and hands you the other two.
A normal software package gives you code that runs — on your machine, at your risk. A tool-server gives you code and a way to call it, but hands the safe-place problem back to you. A platform plugin runs in someone's sandbox but is locked to that platform. Each is reasonable, and each leaves two of the three problems for you to solve.
A toolkit is the bet that code, sandbox, and manual were never three separate supply chains in the first place. And notice the stance: a toolkit doesn't try to beat those existing tools — it happily wraps them. The claim was never “a better protocol.” It's “these three things belong in one box.”
they stacK, and the Box keepS filling
Single tools are just the start. Because every toolkit shares the same shape — manual, muscle, floor — they stack without negotiation. Point a few at one job and you have a research rig or a publishing pipeline. Even your agent itself is a toolkit-shaped thing: its manual describes who it is, and the toolkits are what it reaches for.
And here's how the collection grows. Build something useful inside a workbook — a little parser, a chart helper, a scraper — and one step promotes it into a toolkit the next workbook can pick up. The shared parts bin is fed by the things people actually make, which is the only way a parts bin ever gets good.
where tHis honEstly Stands
Let's be straight, because this is the youngest part of the whole system — by the founder's own admission, toolkits are the least-mature prong of workbooks. Here's what that means for you, plainly.
The shape is real and the floor underneath it is solid: the engine, the sandbox, the safe-powers model are all proven and running, and several real tools have already been brought across. What's early is the collection itself — the parts bin is genuinely small, and it grows one conversion at a time.
And not everything crosses easily. Most software comes over cleanly; some puts up a fight, and a few corners of certain languages don't fully translate yet. That's the honest edge. But every fight won is permanent: convert a tool once and it works for every workbook, every agent, from then on. So if your agent reaches for an ability that doesn't exist yet, that's not a wall — it's the next thing someone brings across.
The quiet invitation buried in all of this: the easiest way to give your workbook a brand-new ability is often to bring across a tool you already love. And once you have, you've added it to everyone's box too. That's not “an app store” — it's smaller, more honest, and more durable than that. It's a shared toolbox that fills up from the work people actually do.