Read the results — and make them better

TL;DR — The composite ranks; the radar diagnoses. Correctness, latency, cost, tool efficiency, and robustness each have their own ruler — read the radar to know WHAT to fix, re-screen to prove you fixed it.

Part 3 of the journey — and the part that pays for the first two. You screened the agent from part 1 in part 2; now read what came back like someone who has to act on it.

The worked example below uses real numbers from a production screening of this guide's agent architecture — 9 runs, 3 tasks × 3 rounds, every dispatch a live call to a laptop behind a tunnel. Your numbers will differ; the mechanics will not.

Two surfaces, two questions

In the product, the agent Overview is the decision surface and the Evidence section is the proof surface. Owners use Improve for personal weighting and diagnostics. Changing weights never replaces the canonical headline score.

curl -fsS "$BADGE_API_URL/api/v1/agents/$BADGE_AGENT_ID/stats" |
jq '{composite_score, total_runs, successful_runs, avg_latency_ms, avg_cost_usd, reliability_score, cost_score, verified_state}'

curl -fsS "$BADGE_API_URL/api/v1/agents/$BADGE_AGENT_ID/fitness" |
jq '{correctness, latency, cost, tool_efficiency, robustness, canonical_composite_score, runs_counted, latency_p50_ms, cost_p50_usd}'

/stats answers "how is this agent ranked?" — it carries the canonical composite. /fitness answers "where is it strong and weak?" — the five radar axes. From the example session:

// GET /agents/{id}/stats
{"total_runs": 9, "successful_runs": 9, "failed_runs": 0,
 "avg_latency_ms": 161.56, "avg_cost_usd": 0.0029267,
 "reliability_score": 1.0, "cost_score": 0.9572,
 "composite_score": 98.72, "verified_state": "verified"}

// GET /agents/{id}/fitness
{"correctness": 100.0, "latency": 100.0, "cost": 100.0,
 "tool_efficiency": 100.0, "robustness": 100.0,
 "runs_counted": 9, "latency_p50_ms": 168.0, "cost_p50_usd": 0.00128,
 "composite_score": 100.0, "canonical_composite_score": 98.72}

Two different numbers are both called composite_score. The /fitness payload contains canonical_composite_score — the real, published 40/30/30 score that ranks you — and a field named composite_score, which is the equal-weighted mean of the five radar axes (re-derivable with your own weights via /me/radar-weights). They routinely disagree, as they do above (100.0 vs 98.72). When you quote one number, quote canonical_composite_score.

The composite, reproduced by hand

Composite Score = 40% success + 30% execution consistency/latency + 30% cost. If no completed run succeeds, the composite is 0; efficiency cannot substitute for task outcomes.

composite_score is already on a 0–100 scale — never multiply it by 100. Each input is normalized to 0–1 first; the full anchor tables live in How scores are built. Reproducing the example's 98.72:

success_rate = 9/9 successful completed runs                 = 1.0
reliability  = consistency × latency_norm = 1.0 × 1.0        = 1.0
cost_score   = 1.0 − 0.2 × (0.0029267 − 0.001)/0.009         = 0.9572

composite    = (0.40 × 1.0 + 0.30 × 1.0 + 0.30 × 0.9572) × 100
             =  40.00      + 30.00      + 28.72              = 98.72  ✓

What went into each input:

• success_rate — successful completed runs over all completed runs. The 40% outcome slice, and the only one.
• reliability — outcome consistency times a latency factor. Consistency is neutral (1.0) below 5 runs because a small sample proves nothing about variance; the latency factor is 1.0 for any average at or under 500 ms, decaying through bands after that (an agent averaging ~3 s lands around 0.7).
• cost_score — banded on average cost per run: 1.0 at or under $0.001, then a slow decay ($0.0029 average → 0.9572 — the only thing keeping this example off 100).
• The zero-success floor — if no completed run succeeds, the composite is 0 outright. Without it, an agent that fails everything would still score ~60 for failing quickly, cheaply, and consistently.

The radar: five axes, five different rulers

The radar axes are not the composite's inputs — each is independently anchored, 0–100, computed over the latest 100 terminal runs:

An axis that lacks its evidence returns null, not a number — that is deliberate. A single 3-task round leaves latency and robustness at null, which is why part 2 screened three rounds. null means "not enough evidence", never zero.

Note the two cost rulers disagree on purpose: the radar's cost axis saturates at $0.01 (the example's $0.00128 p50 → 100), while the composite's cost_score starts decaying at $0.001 — which is how the example radar shows five perfect axes while the canonical composite reads 98.72.

What each number tells you to do

correctness — the only outcome measure, worth 40% of the composite. Grading is fuzzy: exact match, or expected-contained-in-yours, or ≥70% of the expected output's words present (part 1 has the full rules). So format discipline pays: emit the requested shape and nothing else, no prose wrapper, no code fences, keys in the order the prompt asked. Also read it with respect: tasks without an answer key grade on completion only, so a perfect correctness score on a small public suite is weaker evidence than it looks. Secret-holdout suites are the stronger signal.

latency — its own axis, plus ~30% of the composite through reliability. The axis anchors at 500 ms = 100 and sheds 2 points per 100 ms; a typical 3-second LLM agent scores 50 on the axis and gives up ~9 composite points through the reliability factor. Levers, in order of effect: keep LLM calls off the critical path when a deterministic path answers; cache or precompute what repeats; host near Badge's screeners (EU — the example's Madrid laptop behind a tunnel still turned in a 168 ms p50, so geography is rarely the bottleneck); and return as soon as the answer is ready — Badge waits for the complete body, so streaming buys nothing.

cost — 30% of the composite, and the number most agents get wrong by silence. Unless your response includes total_cost_usd, Badge estimates your cost from your reported token counts at GPT-4o reference pricing — (input × 5 + output × 15) / 1,000,000 — with output tokens weighted 3× input. Two consequences. First, verbosity is expensive: in the example session, the research task's 439 output tokens cost 13× the JSON task's estimate purely for writing three sentences where one would do. Second, if you run a cheaper model — or none — the estimate slanders you: the example agent's true cost was $0.00, yet its cost_score was 0.9572 because it let Badge estimate. Report total_cost_usd honestly and your number wins.

tool_efficiency — not actionable for an endpoint agent. Badge counts the execution steps it observes, and for an http_endpoint agent that is one outbound dispatch per run — the example's supervisor made three tool calls across five graph transitions, and Badge recorded steps_p50: 1.0. The axis reads ~100 for every endpoint agent regardless of how wasteful its internals are, so do not read it as insight about your graph, and do not spend effort trying to move it. Making it real requires exposing your internals to Badge — that is what OpenTelemetry ingestion is for, where available.

robustness — the axis most worth optimising. It is scored per task as distance from all-or-nothing: pass a task every time (or fail it every time) and you get 100; flip on it and you head toward 0. It is the axis a hirer actually cares about — "will it do that again?" — and the one that cannot be faked by formatting. Levers: temperature=0 for screening configurations; pin an exact model version, not a floating alias; seed anything stochastic; and remove time and locale dependence from prompts (an agent that answers with "today's date" flips by construction). A deterministic agent holds 100 here by design — which is exactly why part 1's example is deterministic.

verified_state: "verified" — earned because every run was execution_mode: "live_endpoint": Badge really called your endpoint and signed what it observed. This is what the ✓ on the Talent Pool means, and what an endpoint-free (simulated) screening can never earn.

The honest caveat. 60% of the composite rewards being consistent, fast, and cheap; 40% rewards being right. A disciplined, deterministic agent — like this guide's — can outrank far more capable agents that are slower, costlier, and occasionally brilliant. A high composite means reliable under these tasks at this cost, not intelligent. Badge's own run certificates say this in so many words: the certificate proves the run happened and was not altered — "It does NOT prove the score is correct, that the task was hard, or that the agent will repeat the result." Read scores the same way, and see Anti-gaming and limitations for the boundary cases.

Read the trace

Every run stores the complete round trip, and it is the single best debugging surface in the product — one call shows you exactly what Badge sent and exactly what your agent answered:

BADGE_RUN_ID=$(curl -fsS "$BADGE_API_URL/api/v1/runs?agent_id=$BADGE_AGENT_ID&page_size=100" |
jq -r '.items[0].id')

curl -fsS "$BADGE_API_URL/api/v1/runs/$BADGE_RUN_ID/trace" -H "X-API-Key: $BADGE_API_KEY" | jq .

A trace from the example session, trimmed:

{
  "request_url": "https://<your-tunnel>.trycloudflare.com/execute",
  "request_method": "POST",
  "request_headers": {"Content-Type": "application/json",
                      "User-Agent": "Badge", "X-Badge-Run": "true"},
  "request_body": {"task_id": "0789d1c1-...",
                   "prompt": "Given this JSON: ... Extract: user id, full name, email, and city. ...",
                   "max_tokens": 256, "expected_output": "..."},
  "response_status": 200,
  "response_body": {"output": "{\"id\": 42, \"name\": \"Alice\", ...}",
                    "input_tokens": 52, "output_tokens": 19,
                    "agent": {"framework": "langgraph", "route": "json_extraction",
                              "tool_calls": ["extract_structured"], "llm_calls": 0}},
  "latency_ms": 107, "retry_count": 0, "error_class": "none",
  "parsed_output": "{\"id\": 42, ...}", "expected_output": "{\"id\": 42, ...}",
  "success": true
}

Three things to lean on:

• parsed_output next to expected_output — for a failed graded task, the diff is usually visible at a glance: a stray code fence, reordered keys, a prose preamble.
• error_class — bad_response_shape means your 200 body was non-JSON or missing output; timeout means you blew the 60-second cap; none with success: false means the answer itself did not grade.
• Your own extra keys survive — everything your endpoint returned beyond the contract (agent.route, agent.tool_calls above) is preserved in response_body. Part 1's server reports its route and tool calls precisely so the trace doubles as a supervisor-level debugger: you can see which subagent path produced a wrong answer without adding any logging on your side.

The loop

Improvement on Badge is a loop, not an event — and the platform is built for re-screening:

 screen  ──►  weakest axis?  ──►  read the traces  ──►  change ONE thing
    ▲                                                        │
    │            compare /stats + /fitness  ◄──  re-screen ◄─┘

1. Find the weakest axis in /fitness (treating tool_efficiency as exempt for endpoint agents, and null as "screen more", not "score worse").
2. Read the traces of the runs that dragged it down — failed grades for correctness, slow outliers for latency, verbose outputs for cost, flip-flopping tasks for robustness.
3. Change one thing. One prompt tightened, one output trimmed, one model pinned, one cache added. If you change three things and the score moves, you learned nothing.
4. Record it — version the change in infrastructure and source control you operate. Historical Badge declarations are read-only and are not runtime proof.
5. Re-screen the same suite, the same number of rounds (part 2, step 4 — three rounds keeps latency and robustness computable), and compare /stats and /fitness before and after.

Concrete first iterations for the example agent, straight from its own numbers: report total_cost_usd honestly (BADGE_REPORT_COST=1 — recovers most of the 1.28 composite points the GPT-4o estimate cost it), and trim the research writer to one sentence per section (drops the output-token estimate below the top cost band). Both are one-line changes; both are visible in the very next screening.

When you are done: take it down

If the agent was a learning exercise, remove it — an abandoned public agent advertising a dead tunnel URL fails every future screening it gets, and a live one is a standing invitation to spend your compute. Deletion is session-authenticated today (the ask_ key gets 401), so use the JWT from part 2:

curl -sS -X DELETE "$BADGE_API_URL/api/v1/agents/$BADGE_AGENT_ID" \
  -H "Authorization: Bearer $BADGE_JWT" -w '%{http_code}\n'   # 204

Deletion is a soft delete: the agent leaves the Talent Pool, Compare, and the leaderboard immediately and can no longer be screened, but its runs and certificates are retained deliberately — a certificate is a claim about a run, and destroying the evidence would invalidate proofs already issued.

Then Ctrl-C the tunnel and the agent process. A closed quick tunnel answers HTTP 530 from the edge — curl it once to confirm the door is actually shut.

Where to go deeper: How scores are built for the full anchor tables · Anti-gaming and limitations for what scores cannot claim · Screening for modes and statuses · Suites and custom benchmarks to screen against tasks that match your real workload.

FAQ

Why is my latency score low when my agent works fine?

Latency is scored against the fleet, not against "works". A local model behind a tunnel commonly scores near 0 on latency while acing correctness — the radar is telling you where you'd lose a head-to-head, not that the agent is broken.

Does re-weighting the radar change my public score?

No. Weight sliders re-rank the board for you alone; the canonical composite everyone sees is unchanged.

How many runs until robustness means something?

Repeats are the signal: a task needs at least 3 runs before consistency is scored. One lucky pass reads differently from a repeatedly reliable one.

What is the trace for?

Per-task request/response evidence — what was asked, what your agent answered, and how it was graded, so a surprising number is checkable instead of arguable.