Fussy Systems Need Fuzzy Harnesses

We keep trying to solve agents by putting a system on top of them.

We add an orchestrator, a workflow builder, a memory layer, a dashboard, a prompt library, a permission framework, and one more database to remember what all the other parts are doing. The result looks reassuringly like software we already know how to buy and operate.

Then the model changes. The tools change. The business changes. A failure teaches us that the instructions were incomplete. A new edge case does not fit the workflow. Six months later, the system built to control the agent has become the most brittle part of the stack.

I think the architecture is backwards.

Fussy systems need fuzzy, evolving harnesses. Not fuzzy authority. Not fuzzy financial records. Not fuzzy boundaries around actions that can harm a customer. The core should be firm.

But the machinery that helps an agent perceive, reason, and act should be expected to change.

Agents Are Fussy

Agents are unusually sensitive to their environment.

A tool name changes which capability they select. A result shape changes whether they can complete the next step. Too much context can be as damaging as too little. A prompt that works with one model becomes redundant or counterproductive with the next. The same task can succeed or fail because an identifier appeared twenty lines earlier in the response.

This is not merely an intuition. The SWE-agent research showed that changing the agent-computer interface—the commands and feedback through which a model operates—can materially change performance without changing the underlying model. The interface is part of the intelligence of the system.

That is why the harness matters. It supplies context, tools, feedback, memory, checks, and boundaries. It turns a general model into an operator inside a particular environment.

But a harness tuned to the current model and current task is not a durable home for the organization itself.

Organizations Are Fuzzy Too

Real organizations are not clean workflow diagrams.

Intent arrives half-formed. Exceptions are common. The same words mean different things in sales, support, finance, and engineering. A process that looked complete on Monday encounters a case it cannot express on Friday. Some outcomes can be checked mechanically; others require judgment from someone accountable.

Traditional software deals with this fuzziness by freezing a slice of the organization into an application. The database gets a schema. The workflow gets states. The interface gets buttons. Everything outside that shape is handled through meetings, spreadsheets, chat, memory, and heroic employees.

Agents make a different architecture possible because they can interpret intent, navigate incomplete information, and generate the small amount of software needed for the current job.

Yet we often respond by freezing the agent inside another rigid application.

We recreate the same problem one level higher.

A Harness Should Be a Binding, Not a Home

The harness is necessary. It just should not own the organization.

Prompts, skills, agent files, connectors, orchestration graphs, and model-specific instructions are bindings, not homes. They connect a particular agent to durable organizational state. They should be replaceable.

The durable layer should hold things the next model, tool, employee, or application will still need:

Purpose: what the organization exists to do now
Authority: who may decide, spend, send, publish, or change the rules
Roles: durable responsibilities that a human or agent can occupy
Processes: how a kind of work is performed
Tasks: what happened in one bounded performance
Records: the nouns the organization touches and the evidence behind claims
Decisions: exercises of authority, with reasons
Lessons: what experience taught and where it applies
Proposals: reviewable mutations to the way the organization works

This state should live in a neutral, inspectable form. Plain files and git are surprisingly good primitives: readable by a person, legible to agents, versioned, diffable, and independent of any one vendor.

A CLAUDE.md, AGENTS.md, skill, or connector can point into that state. Delete the binding and the organization should remain intact. Attach a new harness and it should be able to find the purpose, rules, evidence, and next action without reconstructing them from a chat history.

OpenAI’s account of harness engineering with Codex arrived at a related lesson inside software development. A giant instruction file rotted and overwhelmed the agent, so the team made the repository the system of record, kept the entry point as a map, added mechanical checks, and fed failures back into the environment.

That is a powerful pattern. I think it extends beyond the codebase.

The repository can hold the organization itself.

Fuzzy at the Edge, Firm at the Core

Calling the harness fuzzy does not mean letting an agent improvise the rules.

It means allowing the expression machinery to adapt while conserving the things that make the organization itself.

Biology offers a useful picture. An organism preserves a small genome while continuously replacing cells, learning from threats, and adapting its behavior to the environment. Stability and change are not opposites. The stable core makes safe adaptation possible.

An agent-native organization needs the same separation.

The conserved core contains purpose, authority, roles, and governed processes. Changing it requires an explicit proposal, evidence, validation, rollback, and a ruling from the person who holds judgment.

Around that core, almost everything should be free to improve: the model, prompt, tool descriptions, retrieval strategy, connector, scheduler, UI, evaluation set, and even the agent that performs the work.

The harness may be fuzzy. The boundary may not.

Keep the constitution stable enough to trust. Let the institution evolve fast enough to learn.

This resolves a false choice in agent design. We do not have to choose between a deterministic workflow that cannot handle reality and an autonomous agent with vague permission to do whatever seems useful. Anthropic’s distinction between workflows and agents is helpful here: fixed paths provide predictability for well-defined work, while agents provide flexibility where the path cannot be known in advance.

An organization needs both. Checks should be deterministic where facts can be established. Judgment should stay explicit where facts are not enough.

The Harness Should Learn From Work

An evolving harness needs a disciplined way to evolve. Otherwise, “adaptive” becomes a polite word for drift.

The loop I keep returning to is simple:

A person expresses intent.
An agent turns it into a bounded task under an existing process.
The work is performed against cited evidence.
Mechanical checks establish what can be proven.
A person with authority makes the judgment call.
The result produces a lesson.
Friction that deserves a durable change becomes a proposal.

If the intent does not fit an existing process, that is not a routing error. It is a growth signal. The agent should not silently stretch its authority or invent a permanent rule. It should propose a new process, explain why it is needed, and wait for a ruling.

This is directed evolution: variation is cheap, selection is deliberate, and useful experience becomes inheritable. A lesson earns weight from outcomes and evidence, not eloquence.

Over time, the organization becomes easier for agents to operate because it carries its own context and scar tissue. A recurring failure produces a check. A confusing system boundary becomes a record. A repeated judgment becomes a candidate process change. A new model inherits those improvements on its first day.

The compounding asset is not the prompt. It is the organization becoming more legible to every future operator.

Organizational Seed

I built Organizational Seed to explore this architecture as a working pattern.

It is not another agent platform. It is a small, file-based organizational kernel: purpose, authority, processes, work, evidence, decisions, lessons, and proposals kept in plain Markdown and YAML. Agent-specific files are deliberately treated as disposable mounts.

The pattern came from operating real business processes with agents—support, procurement, reconciliation, and governance—and watching where apparently good systems failed. Concurrent agents collided. Instructions accumulated until they contradicted one another. Scheduled work died silently. A tool connection was mistaken for permission. Every failure forced the organization to acquire a little more structure.

The answer was not a larger universal orchestrator. It was a smaller conserved core and a better way to learn.

The seed does not replace Gmail, an ERP, a help desk, a storefront, or a bank. Those systems remain sources of truth for the state they own. The seed records how they relate to the organization, what authority governs them, and what evidence a task used. Adoption starts with one painful recurring process, not a migration.

Build Less Permanent System Around the Agent

There will be many agent harnesses. They will improve quickly, specialize, merge, and disappear. Models will absorb capabilities that currently require elaborate scaffolding. Today’s clever memory layer may be tomorrow’s default context mechanism.

That is healthy—if the organization’s identity does not live inside any of them.

The goal is not to find the final system to bolt on top of agents. There will not be one.

The goal is to preserve a small, durable account of what the organization is, what it knows, how it acts, and who may decide—then let each generation of agents build the harness it needs around that truth.

Fussy systems need fuzzy harnesses.

And fuzzy harnesses need a firm seed.