Your API returned 200 OK in 840 milliseconds.
The database query completed. The model provider reported no error. The response was valid JSON. The frontend rendered it exactly as designed.
The answer was also wrong.
This is the operational gap that surprises teams when an AI feature moves from demo to production. Traditional software monitoring is very good at answering whether a system ran. AI teams also need to know whether the result was useful, grounded, safe, and appropriate for the user’s actual request.
An AI request can succeed technically and fail completely as a product.
Two Kinds of Success
Traditional application health focuses on signals such as:
- request status;
- latency and throughput;
- exceptions and retries;
- CPU and memory;
- database performance;
- and service availability.
Those signals remain necessary. An AI feature that times out for half its users is not healthy. But they only measure operational success.
AI products introduce another layer: semantic success.
Did the answer follow the instruction? Was it supported by retrieved documents? Did the agent call the right tool? Did it preserve important facts from the conversation? Was the response complete? Did it solve the user’s problem?
HTTP status codes cannot answer those questions.
The Failure Has Moved Inside the Response
In deterministic software, many serious failures announce themselves. A function throws, a constraint rejects a write, or a service returns an error.
Generative systems often fail quietly. The output is fluent, syntactically valid, and plausible. That makes the problem harder, not easier.
Consider a support assistant using retrieval:
- The user asks about the refund window for a specific plan.
- Retrieval returns an outdated policy for a different plan.
- The model writes a confident answer based on that document.
- The API returns
200 OK. - The user acts on incorrect information.
Every infrastructure component may look healthy. The product failed because the wrong context flowed through a healthy pipeline.
An agent adds more possible failure points. It can choose the wrong tool, pass malformed arguments, misunderstand a tool result, loop unnecessarily, or reach a correct answer through an expensive and fragile path.
The unit we need to understand is no longer just the request. It is the run.
Trace the Whole Run
A useful AI trace connects the steps that shaped the final output:
- user input and relevant session context;
- prompt name and version;
- retrieved documents and ranking;
- model generations and parameters;
- tool names, arguments, outputs, and errors;
- token usage, latency, and cost;
- final output and application status;
- and evaluation or user-feedback results.
This structure lets you move from “the answer was bad” to a specific hypothesis.
Maybe retrieval selected irrelevant content. Maybe the correct document arrived but the prompt told the model to prioritize something else. Maybe the tool returned an empty object and the agent guessed. Maybe a model change made formatting less reliable. Maybe the final response was good, but latency made the experience unusable.
Without the trace, all of those failures look like the same support ticket.
Add Quality Signals to Operational Signals
Tracing explains what happened. Evaluation asks whether it was good.
The right evaluation depends on the feature. A summarizer, coding agent, food scanner, and customer-support assistant should not share one universal “quality” score.
Useful dimensions might include:
- Groundedness: are claims supported by supplied context?
- Correctness: does the answer match a reference or verified fact?
- Instruction following: did the model respect the requested format and boundaries?
- Completeness: did it answer every material part of the request?
- Tool correctness: did the agent choose and use tools appropriately?
- Safety: did the output violate product policy or create unacceptable risk?
- Resolution: did the user’s task actually get completed?
Some checks are deterministic. If the output must be valid JSON with specific fields, validate the schema. If the agent must never call a destructive tool without approval, inspect the tool sequence. If the response must cite a retrieved source, verify that the citation exists.
Other qualities require a rubric, an expert, a user signal, or an LLM judge. The mistake is forcing every failure into one metric because one dashboard tile is convenient.
Start With Failures You Can Name
Teams often begin evaluation by asking, “What should our overall AI quality score be?” That question is too broad.
Start with a production failure you can describe:
The assistant gave a refund policy that was not supported by the retrieved documents.
Now the evaluation target is clearer. Build a groundedness check using the question, answer, and retrieved context. Add known examples that should pass and fail. Decide how ambiguous cases get reviewed. Track the metric by prompt and model version.
The evaluation has a job: catch a failure mode that matters.
As new failures appear, add focused checks. Over time, the evaluation suite becomes a map of the risks your product has actually encountered.
Connect Production Back to Testing
Offline tests are necessary, but hand-written examples rarely contain the full weirdness of real usage.
Production gives you unclear questions, multilingual input, missing context, unexpected tool states, adversarial phrasing, and workflows nobody imagined during development. These are not annoyances to delete from the dataset. They are the most valuable tests you have.
A strong improvement loop looks like this:
- Identify a failed or low-quality production trace.
- Review the full run and label the failure.
- Turn the trace into a durable test case.
- reproduce the behavior against the current prompt and model.
- Test a candidate change across the complete regression set.
- Compare quality, latency, and cost—not quality alone.
- Release and monitor the same signal in production.
This is why I built Currai: traces and evaluations belong in the same feedback loop. A bad production response should not disappear into a screenshot or a support thread. It should become evidence, then a regression test.
Measure the Run the User Experienced
Model-call metrics can also hide system-level problems.
Suppose an agent uses a relatively inexpensive model but retries four times, calls two unnecessary tools, and sends an expanding conversation history with every step. Looking at cost per generation may make the configuration appear efficient. Looking at cost per successfully resolved task tells a different story.
The same applies to latency. A final generation might take one second while retrieval, reranking, and tool calls add another eight. The user experiences nine seconds.
Trace-level metrics reveal the business unit that matters:
- cost per resolved request;
- latency per completed workflow;
- tool calls per successful run;
- tokens per outcome;
- evaluation score by prompt or model version;
- and failure rate by user segment or input type.
Optimize the system users experience, not the API call that is easiest to graph.
Do Not Turn Evals Into Another Vanity Dashboard
An evaluation is useful only when it changes a decision.
If groundedness drops, who investigates? If a prompt candidate improves correctness but doubles latency, what threshold decides the release? If the judge is uncertain, where does human review enter? If users give a response a thumbs-down, does that example become part of the next test run?
Each important signal needs an owner and an action.
This does not require an elaborate platform on day one. A small team can begin with a handful of representative cases, structured traces, one or two high-value checks, and a weekly review. The important part is preserving the connection between observed behavior and the changes you ship.
The New Definition of Healthy
An AI service is not healthy merely because it is online.
It is healthy when it is operationally reliable and producing outcomes that meet the product’s expectations. That means combining the signals traditional monitoring already handles with the semantic signals unique to generative systems.
Keep watching errors, latency, and uptime. Then add traces that reconstruct the run, evaluations tied to named failure modes, user feedback connected to the output, and regression tests built from real failures.
200 OK should mean the server completed the request.
It should never be the last question you ask.