Building agentic applications today means writing what the author calls “harness code”—the layer between a foundation model and the outside world. That harness includes system prompts, tool wrappers (like bash or filesystem calls), planner-executor loops, retry policies, context-compact strategies, allowlists, judges, fallbacks—anything that orchestrates model behavior. Every team ends up building parts of this, and the best teams build most of it. Yet as models grow smarter, much of that code will become obsolete, and teams that treat it as a permanent product layer will waste months ripping it out. The post unpacks the harness into components: system and persona prompts; tool surfaces with schemas and examples; rollout protocols (ReAct, plan-and-execute, multi-agent); context managers that decide what to carry over or discard; memory stores; sub-agent topologies; guardrails; verifiers; and observability hooks. Some harnesses stay minimal (“pi”), others pack every feature (“Claude Code”). Use cases vary—local assistants like OpenClaw, memory-focused agents like Letta, recursive long-context models, massive multi-agent systems like Gas Town—much as different Linux distributions target different needs. Beyond this core “inner” harness, the author highlights an “outer” harness built by end users: custom skills, MCP servers, organization-specific code-review agents. These two layers evolve on different cadences and accrue different technical debt. Industry posts from OpenAI, Anthropic and others all emphasize that environment design, feedback loops and control systems have become as important as the model itself. Anthropic’s two-prompt harness example, for instance, uses an initializer agent to generate an init.sh and progress JSON, then a coding agent that commits changes and updates progress—a deliberate loop stretching beyond a single context window. Finally, the article draws a clear line between research harnesses and production harnesses. In production you need tight tool allowlists, scoped credentials, approval tiers, idempotent retries, audit logs, kill switches—principle of least privilege and “deny by default.” In research you want broad exploration: open tools and flexible environments so the optimizer can learn new capabilities. Treating one harness for both will either stifle learning or expose users to unacceptable risk.