The model can be right and the workflow can still fail.
That is one of the most important lessons in enterprise AI, and it is also one of the easiest to miss.
We keep evaluating AI as if the question was only whether the model can reason, summarize, classify, or generate. Those things matter. But in production, the answer is rarely consumed as a beautiful paragraph in a chat window. It has to become work.
A file has to be written in the right place.
A citation has to point to the right source.
A record has to be updated with the right schema.
An exception has to move to the right queue.
A human has to approve the right thing at the right moment.
That layer is not decoration around the model. It is the harness.
And in many enterprise workflows, the harness is where AI becomes operational.
A recent legal-agent benchmark discussion made this point very clearly. The interesting result was not just that a model improved after the wrapper around it was changed. The interesting part was that a poor score could reflect filenames, folders, schemas, citations, missing final files, or completion discipline more than legal reasoning.
In other words, the model may have understood the task, read the documents, found useful issues, and produced reasonable analysis.
But the system still failed.
Not because the model was incapable of thinking about the work.
Because the work had a required shape, a required place, a required output, and a required path to completion.
That distinction matters.
If we do not separate model failure from harness failure, we end up buying the wrong fix. We change the model when the file handling is wrong. We increase context when the schema is missing. We add another agent when the real problem is that nobody defined what “done” means.
I have seen the same pattern outside legal work.
In field operations, a workflow can fail even when the human explanation is correct. A technician can understand the job and still lose the trace if the scanner handoff fails. A delivery step can be obvious and still break if the required field is missing. An exception can be correctly identified and still sit in the wrong queue. A customer record can be updated with the right intention and still create downstream rework because the system of record was not touched properly.
AI does not remove those constraints.
It makes them more important.
A model can generate a good answer, but enterprise systems need more than answers. They need state transitions, permissions, source references, validation, ownership, and escalation paths. They need a way to know that the work reached the right place, in the right format, under the right authority.
That is why the harness is not plumbing.
It is the product boundary.
This is also where many AI pilots become misleading.
A demo can show reasoning. Production has to show completion.
A demo can show a draft. Production has to show where the draft came from, who approved it, which data was used, what was changed, and what happens when the output is wrong.
A demo can ignore edge cases. Production lives in them.
That is why the first useful question is not always, “Which model should we use?”
Often it is:
- What can be deterministic here?
- What should the model be allowed to read?
- What should it be allowed to change?
- Where does the output have to land?
- What proves that the task is complete?
- Who reviews the exception path?
- What gets logged for audit?
These are not secondary questions. They decide whether the AI output becomes work or remains text.
The best AI architectures I see do not put the model at the center of everything.
They put the workflow around it.
The model handles ambiguity, language, classification, summarization, and reasoning where those capabilities are useful. The harness handles the parts that need precision: file names, schemas, permissions, routing, retries, approvals, citations, queue movement, write-back, and audit trails.
That separation is not old thinking.
It is what lets AI survive contact with real operations.
Because when a workflow fails in production, the customer does not care whether the model was “right” in some abstract sense. The customer cares that the shipment did not move, the approval did not happen, the record was not updated, or the exception disappeared into the wrong place.
The harness is where that difference shows up.
This is why I am increasingly skeptical of AI evaluations that only report model performance without explaining the operational layer around the model.
A 0 percent score can mean the model could not reason.
It can also mean the harness did not enforce the work.
An 80 percent score can mean the model improved.
It can also mean the runtime became better at context selection, output discipline, retrieval boundaries, validation, and completion.
Both matter. But they are not the same problem.
If we confuse them, we learn the wrong lesson.
For enterprise AI, the harness is where accountability starts.
Not in the prompt alone.
Not in the model card alone.
Not in the demo alone.
In the boring layer that decides what the system can read, what it can change, where the result goes, how the exception is handled, and how a human can reconstruct what happened later.
That is where AI stops being a clever answer and starts becoming an operational system.
Still one of the least glamorous parts of the work.
Still the part that decides whether the work actually happened.