Harness Engineering

“Most people do not know that they can just point their agents at my writing, tweets, podcasts, and talks and improve the output of their agents by 100x.”

— Ryan Lopopolo

Harness engineering, the practice of improving agent output by shaping the environment around it, holds a chosen model and coding agent constant as a black box. It improves the two external levers—context and tools—and curates the environment around them. The worker should be able to recover intent, operate the real system, respect authority, prove the outcome, and leave the next run better equipped.

A central purpose of that environment is to carry an organization's nonfunctional requirements: the quality attributes and constraints governing reliability, security, compatibility, maintainability, performance, operability, risk posture, and polish. The harness also carries local decisions about how to prioritize, trade off, and satisfy those requirements. Ryan adopted a systems-level framing from 2026’s [un]prompted conference that describes this as getting the whole universe of nonfunctional requirements into code. Make the Repository Teach the Agent develops how the requirements and decisions become retrievable context, examples, tools, and executable constraints.

Because work is an iterative game, a harness can make organizational judgment cumulative. Lessons from accepted work, corrections, failures, and user responses become context, boundaries, tools, examples, and checks that shape later trajectories. Over time, that feedback loop can make coherence cumulative across agent-maintained artifacts.

[Code is how an agent uses a computer]. That internal action language can produce reliable domain outcomes for people who never review the implementation when [last-mile deployment] supplies the organization’s context, capabilities, authority, and proof.

[Code is how an