Arda Tasci’s essay on agent harnesses is the clearest articulation I’ve read of a thing most agent frameworks get backwards: the harness is not where you show off abstractions. It’s where you cut the cognitive load — measured in tokens — that you put on the model, then get out of the way.

The principles that match what I’ve seen hold up under production load:

• 🎯 Determinism where you can. The LLM picks the goal; the path toward it should be well-defined steps, not open-ended deliberation the model re-derives every turn.
• 💡 Keep the core prompt tiny and let the agent load skills into context at runtime. A bloated system prompt is budget you’ve spent before the task even starts.
• ⚡ Play to the model’s training density. Coding and shell administration are wildly overrepresented in pretraining, so a bash-and-filesystem environment costs fewer tokens to wrangle than a bespoke DSL the model has never seen.
• 🔍 The harness should feel light to the model but do heavy work underneath — logging, sanity checks, sanitization, failsafes it never has to think about.
• ⚠️ Design for failure survival. Agents fail at the LLM level and the harness level; only the second is directly patchable, so make everything auditable and self-healing.

The contrarian bite is in “don’t play the odds, play the bot.” Most orchestration effort goes into clever routing and control flow; the higher-leverage move is meeting the model where it’s already fluent and spending your token budget on the actual task. The HN thread argues over how much of this survives smarter models.

My bet: the lean, auditable harness outlives the clever one, because the failure modes it guards against are structural, not tied to a model version. What’s the first thing your harness does silently in the background that the model never needs to know about?