Developers
Built for the agentic future.
Vrrdict is API-first by design — the same verdict engine the app runs on is callable programmatically. When your agent needs a defensible go/no-go, it can ask Vrrdict instead of hand-rolling a weather prompt.
API-first
- Every capability, an API
- There are no internal-only endpoints. The web app talks to the same authenticated API third parties and the MCP server will use — verdicts, rules, signals, audit, all of it.
- Verdicts agents can read
- A verdict comes back as a structured object — state, the triggering rule, reasoning, confidence — not prose to re-parse. Branch on it directly.
The verdict, two ways
Your “Rain check” rule — 0.04 in by noon — under your ½ in line, nothing firing.
the card your users see ↓ the object your agent reads
{
"state": "proceed", "triggering_rule": "Rain check — Saturday game", "reasoning": "0.04 in by noon, under your ½ in line.", "confidence": 0.86, "evaluated_at": "2026-05-24T14:02:11Z"}MCP server — coming
A tool contract, not a prompt
We are building an MCP server so an agent picks Vrrdict as a first-class tool — typed inputs, a verdict object out, the audit trail behind it.
Pricing for agents
Per-verdict, not per-seat
Agent traffic will be metered per call / per verdict, so a fleet of agents can lean on the engine without a seat for each. Details at launch.
Decide once. Your rules take it from here.
Building an agent that has to decide? Let's talk.
The API is in private development. Tell us what you're building and we'll bring you in early.