The Model Is Not The Product

Most AI products fail somewhere other than the model. They fail in the software around it: the part that decides what the model sees, what it can do, how actions run, and what gets verified. That software has a name, and almost nobody designs it on purpose.

This post is about that system: what it decides, why better models do not remove the need for it, and how to inspect the one you are already running.

The demo works. The product fails. The support agent gives the wrong refund, the coding agent edits the wrong file, the research assistant cites a source it never verified.

None of these is a question of how smart the model is. Yet, most early AI product conversations still revolve around the model. Which one to use. How smart it is. How large the context window is. Those questions matter. They are just not enough.

A model can reason, call tools, write code, and make plans. The product is everything else. That surrounding system is the harness.

The harness is where model capability becomes reliable product behavior.

It starts with a mistake almost everyone makes.

The mistake shows up when something breaks. Something happened that the product should have prevented.

The first instinct is usually to ask whether the model was good enough. That question can be answered, and still leave the failure unexplained. The better debugging move is to trace the system around the model: context, tools, permissions, state, and verification.

Take the three failures I opened with.

The wrong refund. The policy document was stale. Or retrieval returned the wrong source. Or the tool schema made a dangerous action look harmless. Or nothing in the system required approval above a dollar threshold.

The wrong file. The working directory was ambiguous. Or project instructions were missing. Or the file search tool truncated its output without saying so. Or nothing distinguished generated files from source files.

The unverified citation. The product allowed an unsupported claim into the final answer, because nothing sat between synthesis and output asking where the claim came from.

Notice what none of those are. Nothing crashed. No exception was raised. Every component did exactly what it was built to do.

What went wrong is that someone believed something untrue, and nothing was responsible for noticing. The user believed the agent read a file it never opened, because they mentioned it. The model believed a tool succeeded, because the error was buried on line 400 of a 2,000-line output blob. The system believed its own summary, which had quietly dropped the one constraint that mattered.

These are coordination failures, and they share a shape: a gap between what someone believes and what is true, in a system with no mechanism for closing it. Not one of them is a reasoning error. They are missing wiring.

The failure path runs through the harness.

A harness is the software boundary around the model. It includes the prompt, the tool boundary, execution rules, state, governance, verification, and observability. That boundary turns raw model capability into product behavior.

A harness decides how the user and model interact. Is this a chat interface, a background task, a code review comment, a voice workflow, a spreadsheet assistant, or a terminal agent? Does the user give one instruction and leave, or steer the work while it runs?

A harness decides what context the model gets. Files, documents, memories, retrieved passages, project instructions, previous turns, summaries, tool results, system state. The context window is only the container. The harness decides what goes into it.

A harness decides what the model can do. It defines the tools, their schemas, their descriptions, their permissions, and their execution behavior. A tool is a contract between the model and the outside world.

A harness decides how execution works. Does a command run immediately? Does it ask for approval? Does it have a timeout? Is output truncated? Are errors returned to the model? Are retries automatic? Can a long-running task be cancelled cleanly?

A harness decides what state survives. Some state belongs in the transcript. Some belongs in durable session history. Some belongs in a summary. Some should be discarded. Some should never be sent back to the model.

A harness decides what governance means. Which users can take which actions? Which tools are allowed in which workspace? Which secrets are hidden? Which operations need review? Which actions are impossible by design?

A harness decides how work gets verified. Did the test pass? Did the SQL query return the expected rows? Did the diff touch only the intended files? Did the answer cite the right source? Did the output satisfy the actual task, or only sound plausible?

A harness decides how humans inspect the system. What events are logged? What can be replayed? What can be exported? What can be audited after something goes wrong?

That is the product surface. None of it is the model.

The tempting counterargument is that models are improving fast enough to make some of this disappear.

I do not buy it.

Better models reduce some reasoning failures. They make the system more capable. They need fewer examples, recover from vague instructions better, and call tools more reliably.

Product boundaries still have to be designed.

A model can generate a migration. The harness decides whether that migration can touch production. A model can call a shell tool. The harness decides whether the command is blocked, logged, sandboxed, or escalated. A model can summarize a session. The harness decides which parts survive and which parts stay out of future context.

A more capable model can make a weak harness more dangerous. It moves faster through the wrong boundary, calls more tools, and produces more convincing output before anyone notices verification was skipped.

This is the same pattern we already know from ordinary software. A faster service still needs authorization. A better database still needs migrations. A stronger search index still needs source ranking.

The model is part of the system. It does not replace the system.

If you are building with models, inspect the harness before you debate the model.

Start with the failure path. What context did the model see? What could it do? What actually ran? What changed? What was verified? What can a human reconstruct afterward?

Most products cannot answer all six. They store history that records what was said rather than why an action was chosen. So when someone asks what went wrong, the trail ends exactly where the question begins. Without those answers, you have a model call with product-shaped aspirations.

Make the answers visible.

What that takes depends on what you are building.

A coding agent needs filesystem access, shell execution, project instructions, session state, diffs, tests, permissions, and recovery paths. A support agent needs source authority, customer identity, action approvals, refund limits, escalation, and audit logs. A research assistant needs provenance, citation checks, document scope, and a clear boundary between evidence and synthesis.

The model changes across those products. The harness changes more.

That is why harness engineering deserves to be treated as its own discipline. It is where AI becomes usable software.

The argument so far is abstract. But, it should not stay that way. Hugging Face recently open-sourced Tau, a small Python coding agent written to be read rather than deployed. Its stated goal is educational: No hidden machinery, every moving part is on the page.

Every boundary I have described here has a name in that codebase. If you want to see a harness instead of reading about one, that is where I would start.

The model is the engine.

The harness is the machine around it.

If the machine is weak, all that capability stops at the demo.

Harness Engineering is a three-part series. This post makes the argument. Part 2 takes Tau apart, line by line. Part 3 is about what production demands that a teaching system does not.

Reading a harness and designing one are different skills. This series is about reading. Designing is what Aishwarya Naresh Reganti and Kiriti Badam teach in Harness Engineering: Designing the Operating Layer for Reliable Agents.