If you work with a coding agent, count the things watching it right now. Linters. Git hooks. CI. Specs. A memory store. A rules file it's supposed to obey. Half a dozen systems, all making sure the agent builds the right thing the right way.
Now count what keeps you oriented across the eleven things you have in flight. For most of us it's a markdown file we hope we remembered to update.
We spent two years building harnesses for the agent and left our own work on the honor system. Map the tooling on two axes and that gap turns into a specific, hard-to-unsee hole. This post is the map.
(This is part two of three. Part one, The AI orientation tax: it's missing context, not discipline, argued that the cost you're paying is a context bug rather than a character flaw. If you haven't read it, you don't need to. This one stands alone.)
Two loops, not one
The thing people lump together as "agent workflow" is really two loops at different altitudes:
- The execution loop: "is the agent building **this one task* right?"* Scope it, design it, write it, test it. One unit of work.
- The orientation loop: "do you and the agent share an honest picture of **what you're working on* across all the units?"* Capture, check state, prioritize, review, run over the whole board, daily and weekly.
Almost every tool you've heard of lives in the first loop. That's not a criticism. It's just where the money and the visible pain were. But it means when people say "we solved agent memory" or "we solved context," they solved it for the execution loop. The orientation loop got left to you and a markdown file.
You feel the difference the moment each one breaks. When the execution loop breaks, something yells: a failing test, a red build, a review comment. When the orientation loop breaks, nothing yells. The agent confidently re-suggests the thing you rejected yesterday. You rebuild a mental map you already had this morning. The only signal is a vague sense that you're moving slower than the tools promised. One failure is loud and tooled. The other is silent, so it got moralized instead.
Kief Morris, writing on martinfowler.com, maps this carefully in Humans and Agents in Software Engineering Loops. His subject is where the human sits inside the agent's loop: in the loop (inspecting every artifact) or on it (shaping the harness that produces them). As he puts it, "the 'on the loop' way is to change the harness that produced the artefact." Birgitta Böckeler gives that practice a name in the companion piece, Harness engineering for coding agent users.
This post is the next square over. Not where you sit in the agent's loop, but the loop that's yours, and whether anything harnesses it the way we've now learned to harness the agent's. Harness engineering, pointed back at the operator.
The map
Two axes do the work.
- Horizontal, what layer the tool serves: Execution (one task) to Orientation (across tasks).
- Vertical, how it holds: Advisory (you hope it gets read and kept current) to Harnessed (it's hooked on, so it can't quietly drift or go stale).
That vertical axis is the one that matters, and researchers at ETH Zurich put a number on it. Testing four coding agents across 138 tasks, they found that AGENTS.md files barely help: a developer-written one buys a marginal gain, an AI-written one slightly hurts, and either way the context costs over 20% more to run. The reason is the axis. A file is just advice. Nothing forces the agent to follow it, and nothing checks whether it did, so it follows sometimes and skips other times. A harness doesn't ask. That difference is why every enforced tool below exists, and it's exactly what the empty corner is missing.
Walk it corner by corner.
Execution and advisory, the crowd. CLAUDE.md and AGENTS.md, spec-driven dev (Spec Kit), external memory stores, Claude Code's native Tasks, agent-orchestration boards like Vibe Kanban. Enormously useful, and advisory by design: a file you hope the agent reads, a spec you hope stays current. This is where almost everyone is.
Execution and harnessed, productized enforcement for builds. This corner is real and mature: Husky, Lefthook, pre-commit, Trunk, GitHub branch protection, on top of the underlying primitives (git, Claude Code hooks, CI). These don't hope your code is clean. They refuse the commit, fail the build, block the merge until it is. Enforcement isn't exotic. It's a solved, shipping product category.
Orientation and advisory, hand-rolled and honest by discipline. Here's where your own loop lives today: a STATUS.md or CURRENT-FOCUS you re-read each session, todo.txt, Taskwarrior, a Linear board you run solo. All operator-facing, all real, and all kept honest by you remembering to update them. No enforcement.
Orientation and harnessed, empty. A harness for the loop you run: one honest, shared picture of what you're working on that you can't quietly let rot and keep building on, that you and the agent both read. Map every tool you can think of and this corner stays blank.
Try it on tools you actually use
The lens is only worth anything if you can run it yourself, so place a few real tools.
Take a memory MCP, an agent that stores and recalls context across sessions. Genuinely useful, and tempting to file under "solved orientation." But put it on the axes. It serves the agent's recall inside a task, so it sits execution-side. And it's advisory: it surfaces what it guesses is relevant, and nothing forces you or the agent to reconcile the whole board before acting. Bottom-left. It makes execution smoother; it doesn't hold your orientation loop honest.
Take Claude Code's native Tasks, or a board like Vibe Kanban (whose hosted product is now winding down, though the project continues as open source). Closer to orientation, because they track units of work across a session. Still advisory, though: the board reflects reality only as well as whoever last updated it, and nothing blocks the next action when it's stale. Left of center, low.
Take a Linear board you run solo. Now you're genuinely orientation-layer: operator-facing, across tasks. It lands bottom-right. But it's still advisory. Linear will never refuse to let you start work because your statuses are three days old. The honesty rides entirely on you.
Do this with any tool you like and the pull is the same. Things drift left toward execution and down toward advisory. The top-right stays empty. And you start to see what would move a tool into it: the thing would have to gate (refuse the next build until the board is reconciled, the way pre-commit refuses a dirty commit), and it would have to serve both readers off one surface (the list you prioritize is the one the agent reads to re-orient). Bolt a gate onto Linear-for-one and you're most of the way there.
Why three corners filled and one didn't
It's not an accident, and it's not that the orientation problem is small. Two forces left this corner empty.
- Effort pooled where the pain was visible and monetizable. "The agent wrote bad code" is loud, demoable, and sellable, so the execution loop got tools. "I lost track of what I was working on" reads as a personal failing, so it got advice: be disciplined, start fewer things.
- Enforcement never got pointed at orientation. Look again at the harnessed column. Every occupant enforces build correctness: lint, tests, secrets, merge rules. The enforcement primitive, a hook that blocks until a condition holds, is sitting right there, productized, in wide use. Nobody aimed it one layer up, at the question of whether your board is telling the truth.
So the empty corner isn't "enforcement is rare." It's "enforcement is everywhere, for builds, and absent for orientation." That's a much more specific, and more fixable, gap. And the split is worth naming plainly: the agent's job is execution, and ours is orientation. We decided execution was too important to leave to advice, so we made it enforceable. Orientation, the part that decides what the agent works on at all, we left to memory.
It's worth being concrete about how close the missing piece actually is. A pre-commit hook is just a script that runs before an action and can block it. Claude Code ships the same primitive: a hook that fires before a tool runs and can deny it. The entire enforced column is built on that one idea, pointed at code. Pointing it at orientation isn't a research problem. It's the same hook with a different condition: has the board been reconciled today, before you build on it. Nobody shipped it not because it's hard, but because nobody framed staying oriented as a thing you enforce rather than a thing you should just have.
The empty corner is the interesting one
Put the two findings together and the shape of what belongs there is obvious.
- It's orientation-layer: story-grained, across the whole board, not inside one task.
- It's harnessed: a deterministic gate, the way a pre-commit hook gates the commit. It blocks the next build until you've reconciled. You don't hope the board is current; you reconcile it before you build on it. The gate doesn't keep it honest for you. It makes you.
- It serves both readers off one surface: you set priority and capture; the agent reads the same list to re-orient each session and marks state as work lands.
None of those properties is new on its own. Files are a solved substrate. Agent-readable state exists (CC Tasks, AGENTS.md). Boards exist. Enforcement exists (hooks). What's missing is the combination, aimed at the orientation loop. The rarest ingredients are the two this map makes visible: harnessed and serves-both-off-one-surface.
Take the map, not just the conclusion
The useful thing to keep here isn't "4loops goes in the empty corner." It's the map. Next time you evaluate an agent tool, a memory MCP, a kanban, a rules-file convention, place it on these two axes. Which loop does it serve: the agent's task, or your orientation across tasks? And does it hold (gate, enforce, can't-drift), or merely advise (hope it's read)? Almost everything clusters in the same three corners, and you'll feel the fourth one's emptiness yourself.
What goes in that corner, a harness for your orientation loop with honesty enforced the way builds already enforce correctness, is the next post. This one only had to draw the map clearly enough that the hole is impossible to miss.
Sources
The framing this post branches off
- Kief Morris, Humans and Agents in Software Engineering Loops (martinfowler.com, 4 March 2026) — in the loop vs. on the loop.
- Birgitta Böckeler, Harness engineering for coding agent users (martinfowler.com, 2 April 2026) — where the term "harness engineering" comes from.
The measurement of the advisory corner
- Gloaguen, Mündler et al. (ETH Zurich), Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (Feb 2026) — arXiv · InfoQ summary. Four agents, 138 tasks: developer-written context files give a marginal gain, AI-written ones slightly hurt, and both add 20%+ to cost.
The advisory corner (execution-layer, hope-it-gets-read)
- AGENTS.md — the open convention for agent instruction files, now stewarded by the Agentic AI Foundation.
- Spec Kit — GitHub's spec-driven development toolkit.
- Vibe Kanban — agent-orchestration board (hosted product winding down; continues as open source).
- Claude Code's native Tasks — cross-session agent state.
The harnessed corner (enforcement, productized, for builds)
- Husky · Lefthook · pre-commit · Trunk · GitHub branch protection
- The underlying primitive: Claude Code hooks — a script that runs before a tool call and can deny it. The whole enforced column is this one idea, pointed at code.
The hand-rolled orientation corner
-
todo.txt · Taskwarrior · hand-rolled
STATUS.md/CURRENT-FOCUSconventions.
Part one of this series

Top comments (2)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.