Order, Not Tools: Why Agent Harnesses Are a Category Error
There is a consensus in 2026: Agent = Model + Harness.
Harness is everything outside the model. Tools, memory, context management, permissions, observability. Open any agent framework’s documentation and look at the harness section. That is what they talk about.
This is not a mistake. It is a category error.
It answers HOW — how to make agents execute better. It does not answer WHY — why the agent exists. It does not answer WHAT — what should be done and what should not.
An agent with 19 tools, 5 memory strategies, and perfect context management, but no goal and no boundaries, is just a very efficient machine spinning in circles.
Order
Every system tends toward chaos.
Not because the system is poorly designed. Because chaos requires no effort. Order does. An agent without rules will do everything. Doing everything is doing nothing.
The question is not “how do we make the agent better.” The question is: what does “better” mean?
If you have not first defined what order looks like, then every version might be chaos. Roll back to where? Optimize in what direction? You don’t know. You can only go back to the beginning.
So before discussing tools, memory, and context, answer a more basic question: what state is ordered, and what state is chaotic.
The Framework
Why do companies exist?
To achieve a goal.
Why use multiple agents?
Because multiple agents can achieve the goal better than one.
Why do you need a harness?
Because without boundaries, agents do random things. Without boundaries there are no rules. Without rules, they spin in circles.
This is not an analogy. A company is the prototype for an agent organization. Agent organizations face the exact same problem.
Goal. A company exists to achieve a goal. An agent exists to achieve a goal. An agent without a goal is noise. The goal is not “answer user questions” — that is too vague. The goal is specific and measurable.
Scope. Employees have job descriptions — that is scope. Employees have KPIs — that is the objective function. Best practices are not static rules. They are forward-looking frameworks: combining the current situation with a prediction of future direction, not just chasing tomorrow’s short-term gain. Boundaries should become clearer over time, and the cost of maintenance and change is also a factor.
Governance. Moving toward the goal? Continue. Moving away? Roll back. Promotions, demotions, restructuring — all governance. This is not a bureaucratic model. It is an evolutionary model. Like gradient descent: move in the direction that reduces loss.
A harness is not a collection of tools. A harness is recursive Goal + Scope + Governance.
Defining Order
The purpose of design patterns, architecture, and object-oriented programming is not “how to write code.” It is defining what order looks like.
Interfaces define contracts between components. SOLID defines the order of change. Tests define the boundaries of “correct.” These are not programming techniques. They are order definitions.
Best practice is not a starter template. Best practice is the definition of order. It tells you what “good” looks like, what behavior is ordered, and what is chaotic. Without best practice, there is no order definition. Without order definition, you cannot tell good from bad.
Once you fall into disordered chaos, it seems the only option is to start over, or roll back to a previous version. But if you never defined what order is, then every version is a chaos version. You can only go back to the very beginning.
Governance has three layers. Each is a prerequisite for the next:
Layer 0: Order definition. What is a “good state”? Without answering this first, optimization and adaptation have no foundation.
Layer 1: Optimization. Given the order definition, is today better than yesterday? Closer to the goal? Continue. Further away? Roll back.
Layer 2: Adaptability. Not just “is today better than yesterday.” If tomorrow brings a situation that does not exist today, can the system adapt quickly? Bad code runs today but breaks when requirements change. Good architecture runs today and adapts fast when things change tomorrow.
A good harness satisfies all three layers. Layer 1 alone is a local optimum — it falls apart when the environment changes. Layers 1 and 2 without Layer 0, and you don’t know what you’re optimizing for.
Recursion
Multiple agents form a department. But to another department, those agents are one agent.
A department has its own Goal, its own Scope, its own Governance. Externally, it is a single entity. Internally, it is multiple agents each with their own harness.
Individual Agent: Harness(Goal, Scope, Governance)
↓ compose
Department: Harness(DeptGoal, CombinedScope, DeptGovernance)
externally = one agent
↓ compose
Organization: Harness(OrgGoal, CombinedScope, OrgGovernance)
externally = one agentNo separate “collaboration” mechanism is needed.
If collaboration has to be designed as a standalone concept rather than emerging from recursive composition, the abstraction level is wrong. Communication is an implementation detail — how agents pass messages. Collaboration is a byproduct of recursive composition — multiple agents composing into a whole that naturally operates as one agent.
Companies have already proven this. You do not need a dedicated mechanism for “inter-department collaboration.” You need each department to have clear Goal, Scope, and Governance, and then another layer of Goal, Scope, and Governance at the company level. Collaboration emerges from structure.
Where the Recursion Leads
Order definitions become outdated.
When the environment changes, the old definition of “what makes a good organization” no longer applies. From assembly lines to networks, from command chains to self-organization, from waterfall to agile — the old order was not broken. The old order definition stopped matching reality.
So you need a new order definition. A new answer to “what is good.” This is Layer 3.
But the new order definition will also become outdated. So you need to find the order definition of order definitions. Layer 4.
Does this recursion have an end?
Humans have been doing one thing since the beginning: finding patterns. Then finding patterns of patterns. All patterns can be expressed in mathematical logic. Mathematics is the ultimate form of order definition — not because mathematics is omnipotent, but because mathematics is the only language that can precisely express “what is order.”
Organizational restructuring and code refactoring are different instances of the same recursion. A company adjusts its structure to better serve its goal. An agent adjusts its workflow for the same reason. This is not a metaphor for “development” — it is development. Event-driven organizational development. The core objective is making the organization serve its goal better.
Some are already exploring the bottom of this recursion through machine-assisted proof. Not to find the final answer. The one who pushes the stone is not tragic, because the process of finding patterns itself produces order.
The market is giving agents better tools.
We are asking a different question: what is order.
These are two entirely different kinds of engineering.