Agent harness engineering: build the minimum, avoid overengineering as models improve

The article argues that “agent harness” engineering should match the real job, not the hype around coding and personal agents. It defines an agent as an LLM with tools in a loop, and the agent harness as the runtime “body” that provides loop control, tool execution, context management, state persistence, and safety. A key message is to avoid overengineering by mapping complexity on two axes: action complexity (how many tools, decisions, dependencies, and handoffs the agent must coordinate) and context complexity (how much information the agent must gather, retain, and retrieve). If both are low, the harness should stay small. For coding and deep-research agents, context management is often heavier: the article highlights patterns like Reduce, Offload, and Isolate, plus mechanisms such as sub-agents, citations, and hooks for logging/tracing outside the core loop. For support and sales/enterprise agents, the harness focus shifts toward structured outputs, routing, guardrails, and explicit human handoffs rather than heavy memory or compaction. A major theme is the “Kirby effect”: as frontier models improve their tool calling and reasoning reliability, assumptions embedded in existing agent harness components expire, making yesterday’s workarounds dead weight. The recommendation is to revisit and prune harness features with each model upgrade. Named example builders include Hugo Bowne-Anderson (author), Anthropic, Google DeepMind, LangChain, and Anthropic’s Claude Code; it also references systems such as Pi and OpenClaw, and a support agent called Maven Assistant (Maven Clinic). In short: build a minimum viable agent harness, test the loop, then evolve it as models absorb more capabilities.