Back to browse
VR.dev – Open-source verifiers for what AI agents did

VR.dev – Open-source verifiers for what AI agents did

by SkiFreeWin3·Mar 10, 2026·3 points·2 comments

AI Analysis

●●SolidBig BrainSolve My Problem

38 verifiers across 19 domains catch false successes before users do.

Strengths
  • HARD verifiers query actual databases and APIs, not agent self-reports.
  • Composition engine gates soft LLM judges behind hard state checks.
  • Ed25519 signing and Merkle-chained integrity for audit trail evidence.
Weaknesses
  • Overlaps significantly with Gate's agent governance problem space.
  • 38 verifiers sounds impressive but covers narrow enterprise scenarios.
Target Audience

Teams building and training AI agents

Similar To

Gate · LangSmith · Arize

Post Description

Hey HN,

Quick origin story: vr.dev started as a virtual reality project. The domain fit perfectly. The developer adoption did not. Rather than let a good domain go to waste, I pivoted to the other kind of VR: verification and rewards for AI agents.

The problem I kept running into: agents report success but system state tells a different story. The database row is still active. The IMAP sent folder is empty. The tests pass because the agent modified the tests. Real benchmarks put agent success at 12-30%, and even among reported successes a large fraction are procedurally wrong in ways that are hard to catch without actually checking state.

So I built a library of verifiers that check real system state rather than trusting agent self-reports. There are 38 of them across 19 domains right now, organized into three tiers: HARD (deterministic probes against databases, files, APIs, git), SOFT (LLM rubric scoring for things like tone or coherence that don't have a deterministic test), and AGENTIC (verifiers that actively probe the environment via headless browser, IMAP, or shell).

The design decision I'd most like feedback on is the composition model. SOFT scores are gated behind HARD checks, so if the deterministic check fails, the composed score is 0.0 regardless of what the LLM judge says. The idea is to make reward hacking structurally harder rather than just hoping the judge catches it.

MIT licensed, runs locally via pip install vrdev, no dependency on the hosted API which matters if you're using it in a training loop. Full verifier list at https://vr.dev/registry.

Curious whether the HARD/SOFT/AGENTIC taxonomy makes sense to people, whether fail_closed is the right default, and whether anyone has built something similar and run into problems I haven't hit yet.

https://vr.dev https://github.com/vrDotDev/vr-dev https://pypi.org/project/vrdev/

Similar Projects