The Human Harness: Your Loop Runs First

Every serious agentic coding setup is running a harness right now. Not the model itself, but the machinery around it. The loop it runs in, the tools it can access, the context it receives, and the state it records so the next session doesn't start cold. The tech industry has settled on an equation for this: Agent = Model + Harness, and calls the practice of building the machinery: harness engineering. This post is about the half of the system that equation doesn't cover. Every agentic setup has two workers, and only one of them is a model. The other one is you, the person deciding, across many tasks and many sessions, what all of those agents should build. So the equation has a missing twin. Operator = Human + Harness. On this side, you are the raw capability; on the other, the model. The human harness is the machinery around you. Before we dive in, here are the key takeaways and steps you'll find in this article: What a human harness is, and how it complements the agentic harness Why orienting your work is essential before automating execution The core components that make up a human harness How to build a minimal, effective human harness in practice, complete with a concrete example you can implement in your own workflow What a harness actually is To understand what a harness is in an agentic system, we have to understand it from a physical standpoint. Picture a horse harness. Its purpose is to provide the mechanism needed for a horse to do work by transmitting power that already exists and turning it into useful work. Without it, you have a strong animal and a cart that goes nowhere. Call this the transmission function. Now picture a rock climber harness. This one transmits nothing. Its purpose is to secure the climber to a safe working condition (climbing without falling to the ground). It does this by catching a failed state (losing your grip) and taking a securing/remediating action. Without it, you have an unsafe working condition, one where a fail state is not caught and unremediated. Call this the securing function. Therefore, we can say a harness is something with these two functions, and in software the two live together in one environment. Look inside the agent harness you already use. Claude Code transmits for a language model. The raw model can reason but can't act, and the loop, tools, and context management around it are what turn reasoning into shipped work. The same harness also secures. Hooks block a dangerous command before it runs. Sandboxes limit what can be touched. LangChain's own anatomy of a harness lists both kinds of parts in one breath: tools and state to enable the work, "enforceable constraints" to secure it. The pattern is older than agents, too. Your IDE transmits for you, because nobody ships production software from Notepad. And every pre-commit hook, every CI wall, every branch protection rule is the securing function pointed at your code. So here is the definition this whole series stands on. A harness is a system that enables safe execution. It does that in two ways at once. As the environment that turns a worker's power into work, and as the gates that secure the work to safe conditions. What a loop actually is If a harness is a system that enables safe execution, then a loop is a component of that system that defines or manages repetitive execution/work cycles inside a harness. In agentic systems, this is quite apparent. For example, Boris Cherny, who created Claude Code, describes his job as writing loops now, not prompts, highlighting the importance of loops in agentic systems. We can think of a loop as an execution tool. It is created or takes place when one run of a cycle of work shares its state with the next cycle. A for loop is one body of work run many times, sharing a counter. Your Tuesday is a run of you that inherits Monday's state, meaning what shipped, what broke, what you decided. An agent session is a run that inherits whatever the previous session wrote down. Same tool at every scale. Loops consist of four main components. Something that starts a work cycle. Call that the trigger. It might be a user prompt, a morning, a bug report landing. Then there is the work cycle itself where work gets done. An agent session calls one of these a turn. Something decides whether to go again or stop. That's the exit condition. The tests pass, the day ends, the goal is met. And something survives into the next work cycle. That's the shared state. The first three give you repetition. Only the fourth makes repetition into a loop. What this adds up to is that a loop can also be defined as a repetition with shared state. Without it, you have no aggregated result, no compounding effect; each work cycle begins at zero, re-derives everything, deposits nothing. Hold that distinction, a loop versus starting over, because it's the entire agent-tooling industry in one sentence. A model's sessions are starting-over by nature, and the first job of the agent's harness is to carry state across the reset so those sessions become a loop. Now, if we take a step back to see how it all fits, we see that the harness enables safe execution. The loop is the execution tool that needs exactly what a harness provides. The transmission function gives the loop somewhere durable for its state to live between runs. The securing function checks conditions at the boundaries between runs. A harnessed loop compounds. An unharnessed one decays into starting over. The human harness and the agentic one Anthropic wrote the clearest picture of the agentic harness in Effective harnesses for long-running agents. A coding agent works in discrete sessions, and each new session begins with no memory of what came before, like a project staffed by engineers working in shifts where every engineer arrives with no memory of the previous one. Their harness does three concrete things about that. It writes the agent's state to disk, compacts the context so nothing important falls off the end, and leaves a handoff note for the next shift. In our vocabulary, it carries shared state across the reset. It turns the agent's starting-over into a loop. Read the scene once more, though, and count the workers. There are two. The agent is the executor. It takes one task and runs it, inside its harness. You are the operator. You decide what's worth doing at all, you hold every work thread at once (what's captured, what's in flight, what's half-finished, what's next), and you hand tasks down. That isn't supervision from somewhere outside the system. It's a second worker inside it, running its own loop on its own clock. The agent's runs are sessions, and they reset in minutes. Your runs are mornings, days, weeks. Which gives the human harness a precise definition. It is the same machinery, pointed at the upstream worker. An environment that carries your state across your resets, and gates that secure your work to safe conditions. That's the twin equation to Agent = Model + Harness. Operator = Human + Harness. And the two harnesses aren't strangers. Yours lives exactly where the agent's lives, in the same repo, on the same filesystem, built from the same hook primitives. It's less a second system than one more layer of the system you already run, the layer where the decisions come from. The relationship between the two can best be described as the human harness essentially being the frontrunner to getting work done; it runs whatever loop (orientation loop) that lives inside it first and passes that down to the agentic harness, which triggers execution loops for N threads of work or tasks it gets until the work reaches a done state. So both harnesses provide the system for safe execution of work; the only difference is one runs first and is used by the operator, and the other runs second and is used by the agent. What a human harness serves So what is the work of the upstream worker? If a harness enables execution, what execution does the human harness enable? The constant ma