Every agent, no matter how it's built, runs inside something — a piece of infrastructure that interprets whatever instructions the agent has been given and actually executes the resulting steps. That infrastructure is called a harness, and it's one of the more invisible pieces of the whole picture, precisely because when it's working well, nobody thinks about it at all.
Why the harness matters
The reason to name the harness explicitly, rather than leaving it implicit, is that a great deal of what looks like a difference in "how smart" an agentic system is turns out, on closer inspection, to be a difference in harness design instead. Two systems can use the same underlying model and still behave completely differently in production, because one harness checkpoints state and resumes cleanly after an interruption while the other restarts from scratch, or because one harness supports a human-approval gate mid-run while the other has no mechanism for pausing at all. The harness is where questions like "who owns this infrastructure," "how does it recover from a crash," and "how much can a person intervene mid-run" actually get answered.
Three examples, spanning a spectrum of ownership
Three concrete harness examples are best understood as points on a single spectrum of who owns and operates the runtime. At one end sits a declarative, markdown-driven runtime: automation expressed as project instructions, reusable commands, and packaged skills, interpreted directly by an agentic coding runtime with no custom application code required at all. In the middle sits a Python state-machine runtime: automation expressed as an explicit graph of nodes and edges over a typed, shared state object, giving full programmatic control, testability, and the ability to checkpoint and resume a run exactly where it left off. At the far end sits a managed agent platform, where an outside provider takes over packaging, scaling, and observability entirely, and your team owns only the agent's own logic.
None of these three is objectively "better" — they represent a genuine trade-off between control and operational burden that gets progressively traded away as you move from the first to the third. A team that needs full visibility into every state transition, and has the engineering capacity to build and maintain that visibility, is well served by the state-machine end of the spectrum. A team that wants to move fast without owning infrastructure at all is well served by the managed end. Most real organizations end up using more than one of these simultaneously, for different systems with different needs — which is exactly why it's worth having language for the spectrum rather than treating harness choice as a single, one-time decision for the whole organization.
Questions to bring to your team
- Does your team currently own its agent runtime, or run on top of someone else's?
- What would tip you toward building your own harness versus adopting a managed one?