Act 07 · The agent turn 2:30 Structure's cost, and how tools get called

Your tools are eating your prompt.

Every tool you give a model must be described in the context — and those schemas are tokens: paid for on every call, eating context budget, and degrading tool selection when you pile on too many.

Video rendering soonThe cinematic render for this episode is being generated. The article, transcript and key ideas are all here now.

Key ideas

  • The one idea — Every tool you give a model must be described in the context — and those schemas are tokens: paid for on every call, eating context budget, and degrading tool selection when you pile on too many.
  • How it is shown — A lean prompt with two tools versus the same prompt buried under forty tool schemas — the token meter spiking, the context desk crowded, the model choosing worse.
  • The trap to avoid — Adding every tool "just in case" — it feels safe, but it's expensive on every call and makes the model pick worse.
  • What it sets up — A model that can call tools, wrapped in a loop, becomes something new.

Every tool you bolt onto your agent gets described in words, inside the prompt, on every single call. You're paying for tools it never even uses.

The one idea

Every tool you give a model must be described in the context — and those schemas are tokens: paid for on every call, eating context budget, and degrading tool selection when you pile on too many.

You gave your model tools; now it can act. But those tools came with a bill you might not have noticed. Every tool you hand the model has to be described, in words, inside the context. And those words are tokens, paid for on every single call. Recall how tool calling works. The model knows a tool exists only because you pasted its schema into the prompt: name, description, every argument and type. That's not built-in knowledge; it's text in the context window, beside the user's actual question, on every request. Now do the math. One tool might be fifty tokens. Ten rich tools, with careful descriptions and examples, can run to thousands.

How it works — the demo

A lean prompt with two tools versus the same prompt buried under forty tool schemas — the token meter spiking, the context desk crowded, the model choosing worse.

And recall, tokens are money, charged every call. That schema block is a fixed tax you pay on every request, whether or not any tool is used. It costs more than money. The context window is finite, a fixed desk. Every token spent describing tools is one not holding the conversation, the documents, the actual work. Load in fifty tools, and a big slab of that desk is just the menu. There's a quality cost too. Bury the model in forty tools and it chooses worse: more options, more near-duplicates, more ways to pick wrong. Like handing someone a hundred-page catalog for a job needing one wrench. More tools can mean worse decisions.

The trap to avoid

Adding every tool "just in case" — it feels safe, but it's expensive on every call and makes the model pick worse.

Why it matters — and what’s next

A model that can call tools, wrapped in a loop, becomes something new.

The trap: adding every tool just in case. It feels safe; it's expensive, and it degrades selection. The fix: give the model only the tools this task needs. Keep the schemas lean. For big toolsets, fetch the relevant tools on demand instead of pasting them all in. So your tools quietly eat your prompt: tokens, context, and decision quality, every call. Budget them deliberately. But now you have a model that can call a tool and get a result back. Wrap that in a loop, and something new appears: an agent. Next: the loop that makes an agent.

This is one short episode in AI: Zero → Frontier, a step-by-step climb through how AI actually works. Each episode builds only on the ones before it.

Full transcript 2:30 of narration

You gave your model tools; now it can act. But those tools came with a bill you might not have noticed. Every tool you hand the model has to be described, in words, inside the context. And those words are tokens, paid for on every single call.

Recall how tool calling works. The model knows a tool exists only because you pasted its schema into the prompt: name, description, every argument and type. That's not built-in knowledge; it's text in the context window, beside the user's actual question, on every request.

Now do the math. One tool might be fifty tokens. Ten rich tools, with careful descriptions and examples, can run to thousands. And recall, tokens are money, charged every call. That schema block is a fixed tax you pay on every request, whether or not any tool is used.

It costs more than money. The context window is finite, a fixed desk. Every token spent describing tools is one not holding the conversation, the documents, the actual work. Load in fifty tools, and a big slab of that desk is just the menu.

There's a quality cost too. Bury the model in forty tools and it chooses worse: more options, more near-duplicates, more ways to pick wrong. Like handing someone a hundred-page catalog for a job needing one wrench. More tools can mean worse decisions.

The trap: adding every tool just in case. It feels safe; it's expensive, and it degrades selection. The fix: give the model only the tools this task needs. Keep the schemas lean. For big toolsets, fetch the relevant tools on demand instead of pasting them all in.

So your tools quietly eat your prompt: tokens, context, and decision quality, every call. Budget them deliberately. But now you have a model that can call a tool and get a result back. Wrap that in a loop, and something new appears: an agent. Next: the loop that makes an agent.

AgentsTool CallingContext Engineering