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 management of every task being executed (Execution management aka Orientation). In an agentic setup, this job is irreducibly yours. Knowing where everything stands, which tasks exist, which are moving, which are stuck, which matter today. And maintaining a picture true enough to hand down for execution. The interesting thing is that the relationship between orientation and execution is domain-agnostic; it's the same for a software engineer working with agents as for a content creator or a product manager. Whatever your role requires you to execute, you must first orient that task.

I've written about what it costs to run that job from memory, in the orientation tax. The short version: once several threads of agent-driven work are in flight, just staying oriented gets expensive, and the faster you ship, the steeper it gets. Kief Morris places the human "on the loop", shaping the harness rather than inspecting every artifact, and that's the right position. But position isn't the point here. Work is. Orienting is a real workload; it's yours alone, and today it runs bare.

The human harness and the orientation loop

The human harness exists to keep the operator oriented across work. Orientation is the loop that runs before execution: you keep a current picture of the work, use it to decide what matters next, and carry the updated picture into the next run.

For a builder running parallel threads, that loop has four steps. Capture what is on your plate. Check where each piece actually stands. Prioritize what needs attention next. Review what changed after the work runs. Then the cycle starts again. The work itself happens between the steps. The steps are what carry the state from one stretch of work to the next.

That gives us the anatomy of the orientation loop. The trigger is usually a morning, a context switch, or some other moment when you need to re-establish the picture. The run is the four-step orientation process. The shared state is the current picture of the work: what exists, what is moving, what is stuck, and what comes next. The loop persists because each run leaves that picture for the next one.

Without shared state, orientation is not a loop. It is starting over. Every morning, every context switch, you reconstruct the picture from memory, scattered notes, and whatever you can still remember from the last run. That is the orientation tax in structural form. The problem is not that you failed to pay attention. The problem is that nothing carried the state forward.

The difficulty is that there are two reset cycles in the system. Your orientation runs across days and weeks. An agent's execution resets every session. Both workers need the same picture of the work, but neither worker can carry that picture across the other worker's reset. The state therefore has to live outside both of them.

That is where the human harness comes in. Its transmission function gives the orientation loop a durable place to keep its state, one that the human can update and the agent can read. Its securing function controls the handoff from orientation into execution, so the agent does not start from a picture that has already gone stale.

The point is not to make the human do more processing. It is to give the loop somewhere to persist and a boundary that keeps execution attached to the current state. The human runs the orientation loop first. The agent runs its execution loops from the picture that the loop produces.

Build one in twenty lines

Grounding this in practice, these harness concepts can be directly implemented in code using current agentic frameworks. For example, in LangChain or Claude Code, you can write hooks or callbacks that save the agent's state to disk at the end of each session, load the relevant context at the beginning of the next, and log explicit handoff notes as structured data or markdown files inside your project directory.

This not only keeps the agent oriented, but also lets other agents or humans resume work seamlessly. Most frameworks provide APIs or configuration points to plug in these actions as part of the execution loop, so you can use their built-in storage, event hooks, and context management features to realize your own harness, both for models and humans.

To paint the picture more clearly, here is a complete human harness at prototype size, running a one-step orientation loop. It uses Claude Code hooks, the same primitive a pre-commit hook gives you (a script that fires before an action and can refuse it), pointed at your orientation instead of your code.

The rule it enforces is one line long: before your agent touches a file today, you write down what you did yesterday and what you're doing today.

Two pieces. First, tell Claude Code to check before it edits anything:

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/orient-gate.sh" }
        ]
      }
    ]
  }
}

Then the gate. Has today's orientation been written? If not, refuse, and tell the human exactly how to clear it.

#!/bin/bash
# .claude/hooks/orient-gate.sh  (chmod +x)
FILE="$CLAUDE_PROJECT_DIR/.orient/$(date +%F).md"

# Oriented today? Say nothing, get out of the way.
[ -f "$FILE" ] && exit 0

cat <<'EOF'
{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "You haven't oriented today. In your terminal, run: ./orient  — it asks what you did yesterday and what you'll do today, writes it down, and clears you to work. Then retry."
  }
}
EOF
exit 0

The hook can't prompt you itself, because Claude Code hooks don't get a terminal. So it hands you a one-liner to run. That's orient, the piece that actually asks:

#!/bin/bash
# orient  (chmod +x) — say what you did + what you'll do; get cleared to work.
DIR="${CLAUDE_PROJECT_DIR:-.}/.orient"; mkdir -p "$DIR"
FILE="$DIR/$(date +%F).md"
[ -f "$FILE" ] && { echo "Already oriented today → $FILE"; exit 0; }
read -rp "Yesterday I… " DID
read -rp "Today I will… "  WILL
printf '# %s\n\n**Did:** %s\n\n**Will:** %s\n' "$(date +%F)" "$DID" "$WILL" > "$FILE"
echo "Oriented → $FILE. You're clear to work."

The whole loop, from the agent's side:

you: "edit the config"
  → DENIED: you haven't oriented today. run ./orient, then retry.
you: ./orient
     Yesterday I… shipped the loop-map post
     Today I will… revise the flagship
     Oriented. You're clear to work.
you: "edit the config"
  → allowed.

Now let's see how this prototype ties back to the orientation loop and human harness. There's a trigger: the first time your agent tries to touch a file today. There's an exit condition: today's note exists. There's shared state, because the note lands in .orient/, dated, so tomorrow's run starts with yesterday's answer sitting right there. Which means there's a loop. Each day reads the last one and feeds the next, and your days compound instead of starting over. And both functions of a harness are present. The orient script is the transmission, the environment that makes the act take thirty seconds. The hook is the gate, the securing function that makes it non-skippable. Environment plus gate, wrapped around a loop, pointed at a human. A complete human harness, at prototype size.

What a complete human harness looks like

The prototype gives you mostly the gate, but a complete human harness is a system. It provides one current picture of the work tasks, kept where you and your agents can both read it. I keep mine as a board: a simple view of work moving from backlog to done. You then run the orientation loop against that picture, once a day and again at a wider lens when needed. And the gate sits at the boundary between orienting and executing, refusing to let work continue when the picture is stale.

That is the whole shape. Durable state gives the orientation loop somewhere to persist. The orientation routine keeps that state current. The gate makes the handoff into execution explicit. Updating the picture stays free; only building on a picture you have not checked is gated.

At this point you might be asking yourself: I have seen the prototype, but what does the actual thing look like in a live environment? My answer to that is 4loops, a tool I've been building for quite some time. It exists because I found myself paying the orientation tax. My orientation used to live outside the environment where the work happened, in tools like Asana and Notion, in a browser tab far from the repo. Good tools, wrong place. My agents couldn't read them natively; hence, it was difficult to build an orientation loop around them, enabled by the transmission and securing function of the agent's harness.

What it changed was simple. The state I hand down is current, so agents start from the same picture I am working from instead of reconstructing it. Execution became faster, but more importantly, it became easier to keep moving in the right direction. The most direct proof came while writing these posts. I let the board drift behind the real work, and the gate stopped me mid-edit: you're about to build on a picture you haven't checked. Orient first.

That is the point of the harness. It turns orientation from something you have to remember to something the system carries and enforces.

Your loop runs first

The agent's harness solved one problem: it gave the executor an environment that carries state forward and gates unsafe execution. The human harness applies the same idea one level upstream, to the worker that decides what gets executed in the first place.

That ordering matters. Your orientation loop runs across days and weeks. It produces the picture from which the agent's execution loops begin. If that picture is wrong or stale, the agent's harness can preserve it, enforce it, and execute against it perfectly. It cannot correct the decision that produced it.

So the problem is not that agents need more supervision. The operator needs the same machinery we already built for the agent: a durable state that turns repeated work into a loop, and a gate that keeps execution attached to that state.

Okay guys, that's it for this one. If there's one thing I want you to remember from this long post is your loop runs first, so you have to find a way to harness it.

---

Part 3 of 3. The cost: the orientation tax. The map: everyone harnesses the agent's loop, here's the human's. This one: the foundations and the answer.

Sources

• Agent = Model + Harness: LangChain, The Anatomy of an Agent Harness ("a harness is every piece of code, configuration, and execution logic that isn't the model"). Its component list carries both functions in one harness: tools and state to enable the work, "enforceable constraints" to secure it. The practice is named by Birgitta Böckeler (Thoughtworks), Harness engineering for coding agent users. Addy Osmani's Agent Harness Engineering is the practitioner synthesis the Claude Code description draws on.
• The shift-change picture and the agent harness's three jobs (state to disk, context compaction, handoff notes): Anthropic, Effective harnesses for long-running agents (Nov 2025).
• "My job is to write loops": Boris Cherny, via productmarketfit.tech.
• The human "on the loop": Kief Morris, Humans and Agents in Software Engineering Loops (hosted on martinfowler.com, not written by Fowler).
• Orientation as the pivot of a decision cycle: John Boyd's OODA loop.
• The gate primitive: Claude Code hooks, specifically PreToolUse, which fires before a tool call and can deny it. The twenty-line example was tested before publishing (deny, then orient, then allow, plus idempotency). Build-side gates referenced: pre-commit · Husky · Trunk · branch protection.