When someone asks which model I use, the question makes sense. But it is still looking at the engine and calling that the car.

The engine matters. A weak engine limits the trip. A better one can make some work faster, cheaper, or possible at all. But nobody crosses a road by putting a powerful engine on the garage floor.

You still need a chassis, steering, brakes, a dashboard, maintenance, a route, and someone accountable for choosing the destination.

AI works the same way. A model can write, summarize, classify, extract, and reason about what it receives. It does not know by revelation which file governs a decision, which data it may read, what it may not publish, when it must stop, how to test a change, or how to undo it.

That structure around the model is what I call a harness.

TL;DR

An AI harness is not a conscious brain or a conversation window with accessories. It is the system that turns a model’s general capability into directed work: written rules, context, memory and an organized base of decisions, tools and reusable procedures, specialized parts, permissions, policies, validation, operational follow-through, security, publication, and the ability to return to an earlier state. The term has no universal definition—platforms draw its boundaries differently—but the useful idea is simple: the model is a component; reliable operation depends on the environment around it. That does not make vendors irrelevant or erase differences between models. It makes dependencies, decisions, and limits visible so replacing one part does not destroy the whole car.

The model is not the operation

A language model receives context and produces an output. It can be excellent at that and still be insufficient for an entire job.

To publish an article, for example, generating paragraphs is not enough. The system needs to know the author’s thesis, where sources live, how to check a reference, which text versions exist, what image explains the idea, which language is missing, what the site must validate, and where publication must wait for a human decision.

That is not bureaucracy bolted on afterward. It is the work.

In the engineering of Codex, OpenAI’s coding agent, the company calls the layer that coordinates the user, model, and tools a harness. Another OpenAI account expands that scope to thread persistence, configuration, authentication, tool execution, and extensions. Anthropic likewise describes agentic systems as models augmented with retrieval, tools, and memory.

Those sources do not establish one universal definition. That is why I do not treat harness as a magical product name: it is a useful word for the coordination infrastructure that makes a model useful in a real context.

Five things people keep mixing up

Layer	What it is	What it cannot solve alone
Model	The component that interprets input and produces output	It does not know the operation without context or manage the world outside the conversation on its own
Chatbot	The interface through which a person talks to a model	It does not define policy, the authoritative record used when information conflicts, or accountability
Automation	A defined sequence: when X happens, do Y	It does not handle ambiguity because someone gave it an ambitious name
Agent	A system that can choose next steps and use tools within an objective and boundaries	It should not receive unlimited autonomy or generic context
Harness	The structure that connects the pieces, defines contracts, and makes behavior verifiable	It does not replace human judgment, good data, or a process the company never managed to explain

The collection already has, in “AI Is Not One Thing”, a map of models, automations, agents, and harnesses. Here I add the chatbot to the conversation and deepen the harness: not as the fifth box on a list, but as what keeps the other pieces from becoming a pile of tools with too much self-esteem.

What goes into the whole car

This article’s visual metaphor does not show a brain. It shows an engine surrounded by the rest of the operation.

At the center is the model. Around it, I think about at least four sets of responsibilities:

1. Context and memory. Where the system finds requirements, current decisions, sources, confirmed preferences, and the distinction between an old conversation and a current contract. A long conversation can help us think; it should not be the only source of truth. That was the boundary I found when AI forgot a decision I had already made.
2. Tools, skills, and agents. A tool is the ability to search, read, edit, query, or execute something. A skill is a reusable procedure that explains when to use that ability, what inputs it needs, what limits it respects, and how to verify the output. Subagents divide work when there is a real division of responsibility; they are not an expensive way to turn a simple task into a condominium meeting.
3. Policies and control points (gates). Permissions, approvals, time and cost limits, and criteria for asking, refusing, escalating, or stopping. They are the points that allow or block an operation from continuing. An agent that does not know when to stop is not autonomous; it is merely too fast for its own good.
4. Verifiable operation. Validation, proportional event records (logs), tests, monitoring, security, releasing a version into operation (deployment), and returning to a known earlier state (rollback). If the output cannot be inspected, corrected, or undone, it is still a bet—even if it comes with a nicely formatted table.

These layers do not all need the same complexity. A good harness is not the one that accumulates modules. It is the one that gives a problem the protections and capabilities it actually needs.

When a simple structure is enough

This is where people bring the bazooka.

If a task has predictable input, a clear rule, and a known output, conventional code, a small automation, or removing a useless step may be best. There is no medal for calling a freight calculation form an “agent” when it follows a table.

A data check can start with a rule-based check that yields the same result for the same input (deterministic validation). A recurring notification may only need a schedule and a rule. A confused process may need requirements discovery before it needs AI.

The model belongs where language, varied documents, controlled ambiguity, or contextual comparison add value. An agent belongs where it also needs to choose a sequence of steps within limits. The harness grows when the cost of error, duration of work, number of integrations, or need to reconstruct and examine what happened (auditability) justifies it.

That is the discipline I argued for in “Everyday AI Is Not Enough”: utility is not decorating a simple task with an architecture nobody can maintain.

Portability is not absolute independence

I have no interest in building an operation that collapses because a vendor changes a screen, a price, or a model’s behavior.

But I do not sell the fantasy of absolute independence either. Models differ in capability, cost, context limits, tools, policies, and response quality. Some integrations remain external. Migration can require adaptation, testing, and a real economic decision.

The more honest objective is to keep what is yours portable:

• contracts and instructions that explain how work happens;
• decisions, sources, and memory with clear provenance;
• tests and acceptance criteria that compare behavior;
• explicit interfaces for tools and data;
• generated artifacts that can be reviewed outside a chat;
• records sufficient to understand what changed;
• a rollback path when a change does not hold up.

If changing models requires tuning a few parts, normal. If it requires relearning the entire business because context was trapped in a conversation or a closed box, the problem is not just the model.

It is architecture.

What I learned building mine

My work has crossed the whole delivery line: talking to understand a requirement, turning it into a system, choosing architecture, implementing, publishing, monitoring, protecting, and recovering when necessary.

That is why I distrust solutions that start with the tool. A company can have a great idea and still not have defined who approves, which data wins, where an exception belongs, or what happens when something fails. AI does not fix that void through telepathy. It only crosses it faster.

My personal harness began to prevent another waste: explaining my whole way of working from scratch in every conversation. But it does not turn every inference about me into a rule. As I wrote in “ChatGPT Already Knows a Lot About You”, accumulated context becomes a hypothesis; only confirmation becomes a contract.

And a contract cannot become hidden dogma. In “A Hypothesis Does Not Become Fact Because AI Repeated It”, I explain why a wiki preserves origin, uncertainty, affected consumers, and a review condition. That is how the system learns without quietly rewriting the past.

I do not need an agent that only agrees

A harness does not only improve execution. It can improve the quality of the conversation that comes before it.

I want a system that finds gaps, shows contrary evidence, says when a source does not support the whole thesis, and returns a decision when it is still mine. That is the opposite of programming a voice to validate me with excellent diction.

This principle appears in “The Best Answer Is Not the One That Pleases Me Most”. It is not enough for an agent to be fluent, friendly, or fast. It needs permission and structure to disagree, ask for more context, and not execute what is still poorly defined.

That is also why I distrust generic agents sold as ready-made solutions. A reusable base is great. Pretending it already knows a company’s names, exceptions, and responsibilities is another matter.

The useful question is not “which AI should I buy?”

Before choosing a tool, I would start here:

• What decision or work needs to improve?
• Where is the source of truth?
• What is repetitive, what is ambiguous, and what should not be automated?
• What data may the system read, change, or never see?
• When should it proceed, when should it stop, and who receives the exception?
• How will we know it worked—and how will we go back if it did not?

Once those answers exist, model, chatbot, automation, and agent stop being a tool religion. They become architecture choices.

That is where i-9.ai works: turning diffuse context and real requirements into systems that can be operated, verified, and evolved. Sometimes that calls for AI. Sometimes it calls for a simple automation. Sometimes it calls for removing a useless step before either one.

The model can be excellent.

It still needs a car that knows where the brakes are.

Continue reading

• AI Is Not One Thing: model, agent, automation, and harness: basic vocabulary before designing architecture.
• Everyday AI Is Not Enough: I Built an Operation: moving from isolated use to operational capability.
• The Best Answer Is Not the One That Pleases Me Most: the quality contract that guides my agents.
• ChatGPT Already Knows a Lot About You. Before Trusting It, Make It Prove It: turning personal context into a revisable rule.
• A Hypothesis Does Not Become Fact Because AI Repeated It: the receipt needed when an assumption governs an action.
• Generic Agents Can Be Your Worst First Contact with AI: why a demo does not replace discovery.

References and limits of use

The references below explain practices and terminology from specific platforms. They do not prove every harness works the same way, or that any architecture eliminates error, risk, or human responsibility.

• OpenAI, “Unrolling the Codex agent loop”: describes the user-model-tool loop OpenAI calls the Codex harness; it is OpenAI’s own product and engineering account.
• OpenAI, “Harness engineering: leveraging Codex in an agent-first world”: reports how documentation, repository structure, tests, and feedback loops were used in an internal project; it is not a universal recipe or a promised outcome for another company.
• Anthropic, “Building Effective Agents”: distinguishes workflows from agents and describes models augmented by retrieval, tools, and memory; it reflects that company’s engineering recommendations.
• U.S. National Institute of Standards and Technology (NIST) — AI Risk Management Framework 1.0: a voluntary framework to govern, map, measure, and manage AI risks; it does not certify this architecture or replace context-specific controls.