Reading Your Own Logs Before Blaming the Model: A Founder's Guide
When an AI-driven feature misbehaves in production, the first instinct is often to blame the model and switch to another one. That instinct is expensive. Models are only one layer in a stack that also includes prompts, retrieval, tool calls, parsing code, caching, and the human process around them. A failure that looks like a model problem frequently originates somewhere else, and swapping models hides the real cause rather than fixing it. This article offers a method for diagnosing where a failure entered the system, written for technical founders and operators who need answers they can act on. Open Harness is one way to expose output variation across models from a single prompt, which can help you tell whether a problem is model-specific or structural. The method below applies whichever tools you use.
Start by reconstructing the exact request
The first step in any diagnosis is recovering precisely what the system sent to the model. This sounds obvious, yet many teams cannot do it. The final prompt is often assembled from a template, several variables, retrieved context, system instructions, and conversation history. Each of these can change independently. A prompt template edited last week, a retrieval index that returned different documents, or a truncated history field can all produce an output that looks like the model went wrong.
Before you evaluate the model at all, write down the full input as it was received at the moment of failure. If your stack does not record this, that gap is itself the finding. Note the template version, the model identifier and settings such as temperature, the retrieved passages, and any tool results injected into context. Compare the reconstructed input against what you believed the system was sending. Mismatches here are more common than teams expect, and they are the cheapest bugs to fix.
Separate model variance from pipeline defects
Once you know the input, ask whether the same input reliably produces the failure. Run the identical request several times against the same model and see whether the output varies. Then run it against one or two alternatives. If the failure appears only sometimes, you may be looking at sampling variance, which calls for constraints on output format or lower temperature rather than a new model. If it appears every time for one model and never for another, the model's behavior on this task is the likely cause, though you should still confirm the input was identical.
If the failure shows up across all models with identical input, the problem is probably upstream of the model. Check whether the instructions are ambiguous, whether the task requires information absent from the context, or whether the parsing code expects a shape the model rarely produces. Multi-model comparison is useful here because agreement across independent models is a signal that the input itself may be underspecified.
Check the boundaries between steps
In multi-step workflows, errors often enter at the handoff between one step and the next. A model returns a plausible but slightly wrong structured field, a downstream step reads it as authoritative, and by the final output the error has been laundered into confident prose. Examine each boundary. What does step two assume about the output of step one? Is that assumption validated, or is it trusted implicitly? Are there places where a value is inferred rather than extracted?
A useful exercise is to pick the final incorrect output and walk backward, asking at each stage whether the value was already wrong. The earliest point where a wrong value first appears is the one to fix. Fixing a symptom two steps downstream leaves the source intact and guarantees recurrence.
A practical diagnostic checklist
Use the following questions as a checklist when a model-related incident occurs. Did we record the full input and model settings? Is the input identical to what we intended? Does the failure reproduce on repeated runs with the same model? Does it reproduce across other models with the same input? Did a prompt, template, or retrieval source change recently? Does the parser or validator accept malformed output silently? Does any downstream step treat model output as verified without a check? Who owns the decision to act on this output, and is there a record of it?
Answering these questions usually narrows the cause to one of three places: the input construction, the model's behavior on this task, or the code and process that consume the output. Each calls for a different fix. Input problems need better templates or retrieval. Model behavior may need a different model, tighter constraints, or a review step. Consumption problems need validation and clearer ownership.
Decide what to change based on evidence
Only after this diagnosis should you change the stack. Replacing a model is a reasonable response when the evidence shows a consistent, model-specific failure on a task that matters to you. It is a poor response when the failure lives in the input or the handoff, because the replacement will inherit the same defect. Write down what you found, what you changed, and how you will know the change worked. Then monitor the specific failure you diagnosed rather than general quality. A diagnosis that cannot be checked afterward was only a guess.