EvalForge

💡 Inspiration

We started with a simple, uncomfortable observation: every team building AI agents says "our evals pass" — and almost none of them can tell you whether their evals are any good.

Reading through the practice of loop engineering — systems that plan, act, observe, and self-correct — we noticed that every agent loop depends on one thing to know if it's improving: an evaluation signal. But that signal is almost never questioned. A team ships an agent because a dashboard is green, and then an angry customer shows up the same week. The evals didn't lie about the agent — the evals were just too easy to be worth trusting.

So instead of building yet another loop that improves an agent's output, we asked: what if the thing that loops and self-heals is the eval suite itself? That inversion became EvalForge.

🔍 What it does

EvalForge is a self-directing loop that hardens the test suite for an AI agent. Using a customer-support triage agent as the demo target, it:

Runs the agent against the current eval suite and grades it with an LLM judge.
Diagnoses the suite's blind spots and scores its Detection Power — how good the tests are at exposing failure, not just how well the agent scored.
Forges brand-new adversarial test cases aimed precisely at the diagnosed blind spots.
Repeats, until the suite is genuinely hard to fool.

The counter-intuitive success signal: as the loop runs, the agent's pass rate stays flat while Detection Power climbs. We're not making the bot look better — we're making the test worth trusting.

🛠️ How we built it

The whole system is a zero-dependency Node server (built-in http + fetch, no npm install) that orchestrates four roles, each a Claude call:

Target agent — a deliberately naive triage prompt, so the suite has real flaws to find.
Judge — a rigorous grader aware of adversarial tricks (injection, multi-intent, mis-scaled urgency).
Eval Doctor — audits the suite and emits Detection Power + named blind spots.
Forge — an adversarial author that writes new cases for the missing dimensions.

Detection Power is a coverage-and-discrimination score over a taxonomy of failure dimensions $D$ (prompt injection, multi-intent, multilingual, emotional-but-low-stakes, policy conflict, …):

$$ \text{DetectionPower} \;=\; 100 \cdot \frac{1}{|D|} \sum_{d \in D} w_d \,\cdot\, \mathbb{1}\big[\text{suite exercises } d \;\wedge\; d \text{ exposes real failure}\big] $$

On top of the loop, we added a ship-gate that refuses to approve an agent on an untrustworthy suite:

$$ \text{Verdict} = \begin{cases} \textbf{HOLD} & P < 80 \[4pt] \textbf{NOT READY} & P \ge 80 \;\wedge\; \text{pass} < 85 \[4pt] \textbf{APPROVED} & P \ge 80 \;\wedge\; \text{pass} \ge 85 \end{cases} $$

where $P$ is Detection Power. A high pass rate can never earn approval on its own — the suite has to have earned the right to grade first.

Finally, to prove it isn't rigged, we wired a real-data seed loader that pulls live customer-support tickets from the public HuggingFace *Bi