Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system.
Made by builders.
For builders.
In Part 3, we looked at the Loop — the outermost machinery of a harness, the piece that drives everything else.
But a Loop on its own is a hollow shell.
It calls the model.
The model responds.
And then, if the model wants to affect anything outside the text it just produced, it needs to reach for a tool.
That's what this article is about: the Tool Layer.
The set of functions the harness makes available to the model, and the design decisions that separate a tool surface a model can actually use from one that constantly frustrates it.
What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop The Tool Layer ← You are here Part 5: Context Engineering Part 6: The Filesystem & Environment Part 7: The Memory Layer Part 8: Observability Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what tools actually are, why they exist, and — more usefully — how to tell a well-designed tool surface from a badly-designed one the moment you look at one.
Let's get started. 📚 Want to go deeper than the articles?
While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code.
Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers.
Both are optional — the series stands on its own.
But if you want the full studio-quality version, that's where it lives.
What The Tools Are The Tools are the set of functions the harness exposes to the model.
Concretely: the harness tells the model "here are the functions you can call, here are their names, here are the parameters they take, here's what they do." Then on any given turn, the model can decide to emit a structured request to call one of them.
Something like: The harness sees this request in the model's response, runs the actual function (in this case, opens and reads its contents), and feeds the result back into the model on the next Loop iteration.
That's the whole mechanic.
Two-way traffic: the model requests, the harness executes, the harness returns.
If you're coming from traditional software, think of the Tool Layer as the API the harness offers to the model — the same way an operating system offers system calls to a running program.
Same shape, different consumer.
Why The Tools Exist Tools are the model's surface area into the world.
Without them, the model produces text and that text goes nowhere.
With them, the model can decide to do a thing and have the thing actually happen.
Look back at Part 1 — the raw model problem.
Three of the five gaps we named there close through tools: No execution → tools that run code, touch files, hit APIs No fresh knowledge → tools that search, retrieve, or query external data No environment → tools are how the model reaches into whatever environment the harness sets up (The other two gaps — persistence and verification — are addressed by different components, which we look at in later parts.) Every capability you've ever seen an agent exercise came through a tool.
When Claude Code writes a file, that's an tool.
When a research agent searches the web, that's a tool.
When a customer-support agent looks up an order, that's a tool.
The Loop drives the cycle; the Tools are what the model asks for inside each turn.
What a Good Tool Design Looks Like If you look at ten agent frameworks, you'll see ten different opinions on how many tools an agent "needs" and how they should be shaped.
The good ones share three properties.
A Small Set That Composes Well There's a d