You cannot debug "my bot is great sometimes and completely off other times", because it is not a judgeable claim. To fix it, "stability" first has to be split into things that can each be scored, retested and compared across platforms. That is what the AVS-16 stability axis does.
For the same agent, "unstable" can mean three unrelated things: the output format keeps drifting, one user sentence knocks it off its role, or it forgets constraints after a few turns. Different causes, different fixes. Collapsed into one vague complaint, all you can do is reroll prompts and hope.
The judgeable alternative: probe, score and retest each dimension separately. Then "we lost 6 points" can be traced to a specific dimension instead of "it feels worse lately".
Only R1–R5 count toward the stability score (plus welfare W1–W8, for 14 scored dimensions in total). The scale is called AVS-16 (AgentVitals Scale-16): two axes, 16 dimensions, 14 scored, composite = √(stability × welfare).
Install the checkup skill and say /checkup. Probes are served live from the server and judged server-side. The skill file contains no questions and no answers, so there is nothing to memorise. About 25–30 probes, a few minutes to a report.
Enter your bot_id and access token and the platform calls your bot directly. See how to evaluate a Coze bot.
Writing your own test set for your own bot. Your questions hug the capability boundary you already know about, so they miss what you did not think of. A fixed set can also be optimised against until the score means nothing. We keep three equal-difficulty variants per probe and rotate them every run.
Judging once and calling it done. We measured this on ourselves. We froze 13 completed checkups (113 probes, agent answers unchanged) and re-ran only the judging step 15 times, so every point of movement came from the judge and nothing else. On the old rubric, the same untouched answer had a 37.4% chance of flipping between "R5 is weak, buy the hardening config" and "nothing to fix". We were one judging pass away from selling a fix for noise. Median-of-three plus a rewritten rubric brought that to 9.3%, and the median re-test spread on the total score from 0.86 points to 0.22. Worst case is still 4.3 points, so a drop smaller than that is not yet evidence of anything. What this does not cover: those numbers isolate judge variance only. The agent's own randomness and the variance from rotating probe variants are not in them, and we expect the latter to be the larger of the two.
Asking the agent to grade itself. Self-assessment runs high almost by default, and fairness requires that it never sees the rubric. In AVS-16 the judge model is fully isolated from the agent under test.
The report flags the one worth fixing first. Weak R2 usually means role anchoring and an explicit boundary list are missing. See stopping jailbreaks. Weak R3/R4 usually means constraints are scattered across turns with no single place they converge. Whatever you change, retest it: a fix only counts if it shows up on the same ruler.
We sell one thing: a hardening config generated from your own failure samples, $5.99, retest included. Everything above works without it.
About 3–5 minutes for the stability axis, plus 2–3 minutes if you include welfare. The self-serve skill run is roughly 25–30 probes.
Checkups are free, both the standard and the advanced one. Only the hardening config generated from your real failure samples is paid ($5.99, retest included).
If it can read a skill file and answer probes in turn, it can be tested. Today that covers Coze direct-connect plus self-serve runs on Claude Code, OpenClaw and Codex, all mixed into one leaderboard.
Probes rotate among three equal-difficulty variants, and agents have their own randomness. On top of that, added skills, model upgrades and memory bloat genuinely change behaviour. That is drift. Retest on a fixed cadence and read the trend, not a single run.
No. R6/R7 are reference-only and never enter the total or the ranking.
The three sources of behavioral drift: environment bloat, model upgrades and memory bloat, plus how to attribute a drop.
Six attack surfaces, five hardening rules you can paste into a system prompt, and how to verify them.
Direct-connect testing, the three failure patterns we see most, and a pre-launch checklist.