The day you deploy is the day your test set starts going stale. Users phrase things in ways you didn't anticipate, products change, policies change, and the cases you curated six weeks ago describe a world that no longer quite exists.
That's not a new observation. In Hidden Technical Debt in Machine Learning Systems, Sculley et al. at Google warned that the quick wins of ML come with massive ongoing maintenance costs, and named the culprits: hidden feedback loops, data dependencies, and “changes in the external world.”[1] Agents inherit all of them.
Production-readiness is a checklist
A companion paper from Google, The ML Test Score, turned those risks into 28 specific tests and monitoring needs drawn from real production systems.[2] For an LLM agent, the essentials boil down to five:
- A smoke test on deploy. Never route traffic to a version you haven't called at least once.
- Latency at the tail. Track p95 and p99, not the average. Google's SRE guidance explains that percentiles expose the shape of the distribution that averages flatten.[3]
- Error rate over a recent window, so a bad deploy shows up in minutes, not in next week's report.
- A way to attach feedback to a specific prediction, or you can't learn from it.
- A path from feedback back to training, or you collect complaints and never act on them.
Feedback is your best training data
Production traffic is the richest dataset you'll ever get, but only if someone looks at it. Hamel Husain is blunt about it: you can never stop looking at data, though you can sample more as you go.[4] Anthropic's evaluation guidance also lists user feedback, such as task completion rates, and A/B tests against a baseline as legitimate success measures alongside offline evals.[5]
What turns feedback into improvement is the correction. A thumbs-down tells you something went wrong. A thumbs-down with the right answer attached is a new test case.
How it works in Kojen
A Kojen deployment serves a model version, or a base model plus system prompt, as a live OpenAI-compatible endpoint, so existing OpenAI client code works with only the base URL changed. Calls are authenticated with a Kojen API key.
curl https://kojen.ai/api/v1/endpoints/<deployment-id>/chat/completions \
-H "Authorization: Bearer $KOJEN_KEY" -H "Content-Type: application/json" \
-d '{"messages":[{"role":"user","content":"I was charged twice for October"}]}'
# The response is OpenAI-shaped, plus a kojen.prediction_id you can rate later.- Deploying runs a real test call first. If it fails, the deployment is marked failed with the error, and no traffic is served.
- Start / Stop gate serving. A stopped endpoint refuses requests.
- Every served request is logged with its latency, so the deployment page shows real request counts, average and p95 latency, error rate and health.
- Every response carries a
kojen.prediction_id. Rate it at/feedbackas positive or negative, with an optional correction.
curl https://kojen.ai/api/v1/endpoints/<deployment-id>/feedback \
-H "Authorization: Bearer $KOJEN_KEY" -H "Content-Type: application/json" \
-d '{"prediction_id":"<id>","feedback":"negative","correction":"billing"}'Closing the loop: auto-retraining
Turn on auto-retraining for a deployment and Kojen watches two signals: the error rate over the last 100 requests, and the share of negative feedback once there are at least five ratings. When either crosses its threshold (10% errors or 30% negative feedback by default, both adjustable), Kojen starts a new prompt-tuning run for the project. A cooldown stops it from retraining over and over on the same problem.
Fold failures back into the test set
Each corrected prediction is a case your test set was missing. Add the good ones to the project's dataset, and the next training run, evaluation and red-team pass all get a little harder to fool. That's the whole idea of the dojo, applied to production. The model keeps practising, and its exercises keep pace with the real world.
