# Harness Engineering 101 Leaves the Sandbox as Homework **Summary:** Harness Engineering 101 makes agent control flow easy to inspect, but its toy leaves a real sandbox as an exercise. I would enforce tool permissions and check task results before trusting it with valuable work. - Canonical: https://markhuang.ai/news/harness-engineering-101-sandbox-homework - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-10-19 - Section: News - Tags: Harness Engineering, AI Agents, Python, Sandboxing, Tool Permissions, Agent Reliability - Source: [Harness Engineering 101 on GitHub](https://github.com/IsuruMaduranga/harness-engineering-101) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A brass agent-loop teaching model inside a partially assembled glass enclosure, with its final panel resting on the bench](https://cdn.markhuang.ai/news/harness-engineering-101-sandbox-homework/hero.webp) *The loop is assembled. Its protective enclosure still needs work.* [Harness Engineering 101](https://github.com/IsuruMaduranga/harness-engineering-101) teaches agents by following a small Python program as each failure forces another change. Isuru Wijesiri labels the book version 1.0, September 2026, and develops the idea across 16 chapters around a roughly 300-line toy harness. The detail I would pay closest attention to is in the [epilogue](https://github.com/IsuruMaduranga/harness-engineering-101/blob/main/src/16-epilogue-build-your-own.md): adding a real sandbox is homework. The author calls the permission gate a sketch and lists missing production features, including retries and compaction. Getting this agent to run leaves substantial work before I would trust it. I would use the book to understand where an agent gets its authority before deciding what to build around it. Its small size makes the control flow easy to inspect. My concern is what a reader might infer from that simplicity: understanding the loop does not establish that it should inherit access to a working machine. ## The failure behind each feature The README gives every chapter the same structure: a failure, a minimal patch, and the patch's cost. Features arrive because tool results grow too large, work outlives a synchronous call, or information no longer fits in the conversation. Those are concrete reasons to add machinery. They also give beginners a way to question a framework's feature list. Before adding memory or delegation, I want to know which observed failure it fixes and what new failure it introduces. That makes this book useful for a developer who can call a model but cannot yet explain why an agent gets stuck or loses context. The program is small enough to follow those decisions through the code. [LangChain reported](https://blog.langchain.com/improving-deep-agents-with-harness-engineering/) improving its coding agent from 52.8% to 66.5% on Terminal Bench 2.0 while keeping the model fixed. That result comes from the vendor's own agent and does not evaluate this repository. It gives me a reason to study the surrounding software, while leaving the question of how to build my own harness open. ## Read the gate before trusting the shell I would inspect the [toy implementation's `gate` function](https://github.com/IsuruMaduranga/harness-engineering-101/blob/main/src/harness/harness.py) alongside the prose. It checks protected path strings for `write_file` and `edit_file`, and makes edits depend on a prior read. Shell commands follow a different branch: selected command substrings trigger a human approval prompt. The dispatcher then uses `subprocess.run` with `shell=True` for foreground commands. Reading that control flow shows why the sandbox exercise matters. A path check attached to a file-editing tool does not automatically govern file changes performed through the shell. I would trace every route to the same effect before describing a permission as enforced. Recognizing selected command strings and restricting what a process can access require different controls. The author is clear about this boundary. [Chapter 13](https://github.com/IsuruMaduranga/harness-engineering-101/blob/main/src/13-reflexes-and-guardrails.md) describes layered defenses, including limiting tools, deterministic checks, human approval, and sandboxing. The epilogue leaves the stronger boundary for the reader to implement. I appreciate that candor, and I would treat the exercise as a prerequisite for valuable work. > **Info:** > > Before adding another agent feature, I would define what the process may read, change, and contact. Then I would check that those limits hold through every exposed tool. ## Containment still leaves correctness open Even a well-contained agent can finish the wrong task. In [Birgitta Böckeler's analysis of harness engineering](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html), guidance before an action and feedback afterward serve different purposes. She also identifies a harder limit: checks cannot reliably establish functional correctness when the human has not clearly specified the desired behavior. That is the objection I find most persuasive to treating a small loop as an explanation of the whole engineering job. The loop explains how the agent keeps acting; someone still has to decide whether the result solves the user's problem. A sandbox limits consequences. An acceptance check asks whether the work was useful. I would budget for both. The [Hacker News discussion of the book](https://news.ycombinator.com/item?id=50151390) includes appreciation for the resource and objections to its biological metaphors. I share the concern when an analogy substitutes for an explanation. Here, I would turn to the code: can I find the branch that refuses an action and follow what happens to the result? Can I explain why the run stops? Those questions make the metaphor less important. ## The exercise I would do first I would start with a disposable project and one modest task. Before the run, I would define the expected output and an action the process must be unable to perform. Then I would pair that denial check with a legitimate task that still needs to succeed. Blocking everything would tell me little about whether the boundary is usable. For debugging, I would follow [chapter 12's request-capture approach](https://github.com/IsuruMaduranga/harness-engineering-101/blob/main/src/12-debugging-the-array.md), using synthetic inputs to inspect what actually reaches the model. After that, I would add features when a failed run gives me a reason. This fits my earlier argument that [each harness component should earn its place](https://markhuang.ai/news/stronger-coding-agents-fewer-tools). I recommend Harness Engineering 101 because it gives readers code they can follow from a model request to an action. The sandbox exercise is where I would pause the reading and start doing the engineering. Before giving that program anything I care about, I would want to explain which actions it cannot perform and what enforces those limits.