The Agent Harness Ate My Workflow

A year ago I wrote about keeping a 6,000-line Python-to-TypeScript migration coherent with a markdown file. The pattern was simple: I owned the plan, the model executed small steps against it, and the current state lived in a ConversionProgress.md I re-injected at the start of every session. It worked. I finished the migration over a weekend without the drift and rework that had killed earlier attempts.

Most of that scaffolding is now a product feature.

I want to be precise about the timeline, because it’s humbling. Some of what I was maintaining by hand already existed when I published. Claude Code had CLAUDE.md auto-loading and session resume before my post went up, and I was mostly working around features I hadn’t adopted. The rest arrived within months: hooks in July 2025, custom subagents that same summer, checkpoints and rewind in the 2.0 release that September. The loop I described as “checkpointed execution” is literally a slash command now. I predicted my scaffolding was the durable part, and it lasted about a quarter.

I also wasn’t the only one who landed on the pattern. Progress files, todo.md loops, plan recitation. Half the industry converged on some version of external state for agents around the same time, which is exactly why the harness vendors built it in. That’s not a knock on the pattern. Convergent workarounds are how missing product features get discovered.

What the harness absorbed

The mapping from my hand-rolled 2025 workflow to today’s built-ins:

• The progress file itself → persistent task lists. The agent tracks its own plan, the tasks survive a crash, and a resumed session picks them back up.
• Re-injecting the plan every session → auto-compaction and session resume. Both existed in mid-2025 and both got dramatically better. Compaction is near-instant now and resume actually restores working state instead of a lossy transcript.
• “Don’t mark it done until tests pass” → hooks. You can wire a check that blocks the agent from declaring completion until the test suite is green. My checkpoint discipline, enforced by the tool instead of by me remembering.
• Small steps to limit blast radius → checkpoints and rewind. A bad step is an undo away instead of a git archaeology session.
• Manual context injection → project memory as a cross-tool convention. CLAUDE.md, AGENTS.md, auto-memory directories. Every serious agent CLI now loads project context without being asked.

This is real progress and I’m glad the manual versions are dead. Nobody should be pasting a markdown file into a prompt in 2026.

What didn’t transfer

Everything the harness absorbed was state: where the plan lives, what’s done, what’s next. What it didn’t absorb is ownership of “done.”

Hooks are the sharpest way to see the boundary. A hook that blocks completion until tests pass is a verification gate shipped as a feature, and that much genuinely transferred. But the hook runs whatever check you gave it. I’ve had an agent mark a task complete with a green suite because the tests it wrote exercised the wrong behavior: the gate fired, the gate passed, and the gate was checking the wrong thing. The harness can enforce your definition of done. It cannot supply one.

An agent grading its own step-completion is an unchecked judge. That’s the same problem I wrote about in ground-truthing LLM judges - a plausible-looking verdict from a model with the same blind spots that produced the work. The fix is the same too: the standard of “done” has to come from outside the loop that’s being graded.

There’s a quieter version of this that took me longer to notice. The hand-maintained file had a side effect I didn’t value at the time: I read it. Every session started with me re-reading the plan, which meant I re-anchored to the goal as often as the model did. Built-in task lists and compaction summaries are state the human rarely looks at. The state management got better and my visibility into it got worse. Drift didn’t disappear, it just stopped being something I’d naturally catch. A compacted plan is the model’s summary of the plan, and intent is exactly the kind of detail summaries drop. I now keep one human-owned document per long-running project anyway. The agent doesn’t need it. I do.

The steelman

The obvious pushback: plenty of people run agents overnight on a one-paragraph prompt and wake up to working code. No decomposition, no progress artifact, fine results. Maybe judgment is getting commoditized too, just a release or two behind state.

I think the honest answer is that it works when “done” is machine-checkable. Ports, migrations, making a red suite green, upgrading a dependency: the verification is crisp, so the agent can self-serve its own feedback and the human plan adds little. Where I still see long runs go sideways is work with a fuzzy definition of done: the agent produces something plausible, every local check passes, and it’s two days before anyone notices it solved an adjacent problem. So the real frontier is the set of work where done is checkable, and expanding that set is an eval problem, which makes it our problem more than the model’s.

The takeaway

I was wrong once already about where the human/harness boundary sits, so treat this as a position I’ll keep updating. But a year of running these tools daily has moved my confidence in one direction: the harnesses commoditized state management, and they haven’t touched accountability. Somebody still decides what the gates check, owns the decomposition that makes “done” checkable, and reads the plan often enough to notice drift. Today that somebody is you.