Skip to content
XEVRION
Menu

For engineering teams

Ship agents without shipping risk

Add a human check to the actions that matter, from a few lines of code, and keep moving fast on the rest.

docs.xevrion.co.uk / quickstartExample data

Guard one action

TypeScript
const d = await xevrion.review({  agent: 'refund-agent',  action: 'refund.issue',  payload: { order: 88231, amount: 540 },});if (d.approved) await refund(d.token);

In your pipeline

  1. Test set runs on each change
  2. Policy tests run
  3. Eval gate: 4 cases now fail
  4. Release blocked

Prompt registry

  • refund-triagev14 · label prod
  • refund-triagev15 · label staging

Your jobs

What engineering gets done

  • Wire it in

    A typed SDK and a wait endpoint. Ask, wait, act.

  • Keep a safe path

    Approved actions carry a token your executor checks before it runs.

  • Tune with data

    Test a rule on past requests, then turn it on.

Getting started

Your first week

  1. Day 1: get a keyCreate a project and an API key. Install the SDK.
  2. Day 2: guard one actionWrap the riskiest call. Everything else stays as it is.
  3. Day 3: write the ruleSay who answers: nobody, one person or two.
  4. Day 5: gate your releasesRun saved cases in CI and block a worse prompt or model.

Platform

API, SDKs and webhooks

A typed API and SDKs for TypeScript and Python. Decisions come back by signed webhook, or your agent waits for them.

  • Typed clientsGenerated from the API description, so they stay in step with it.
  • Signed webhooksCheck every callback is really from us.
  • Safe to retryIdempotency keys stop a retry creating a second request.
How API, SDKs and webhooks works →
docs.xevrion.co.uk / sdkExample data

TypeScript

npm install @xevrion/sdk
import { Xevrion } from '@xevrion/sdk';const x = new Xevrion({ key });const d = await x.review({  agent: 'refund-agent',  action: 'refund.issue',  payload: { amount: 540 },});

Signed webhook

POST /hooks/xevrionx-xevrion-signature: t=…,v1=…{ decision: 'approved' }→ 200 retry-safe

Prove

Proof-carrying tokens

After a yes, a short-lived signed token binds the approval to the exact action. Change anything and it fails.

  • Bound to the actionThe token covers that payload only. A changed amount or target is refused.
  • Expires fastA short window, so an old approval cannot be replayed later.
  • Single useOnce spent, it is spent. A second try is refused.
How Proof-carrying tokens works →
docs.xevrion.co.uk / action-tokensExample data

Your agent presents the token

POST /payments/refundx-xevrion-token: xt_4c9…{ order: 88231, amount: 540 }// Change the amount to 541:→ rejected: action does not match

What the token locks

Action
refund.issue
Amount
£540
Expires
In 5 min
Uses
1 of 1

Life of a token

  1. Person approves
  2. Token issued, 5 min
  3. Used once by your agent
  4. Second use refused

Review

Policy routing

Each action your agent proposes is sorted by your policy: go ahead alone, ask one person, or ask two.

  • Four routesAuto-approve, one reviewer, four-eyes approval, or reject outright. You choose per action and per risk.
  • Rules as codeKeep policies in your own repo. A new policy is replayed on past requests before it can go live.
  • Plain reasonsEvery route records why it was picked, so a reviewer sees the rule that sent the request to them.
How Policy routing works →
app.xevrion.co.uk / policies / refundsExample data

Rules, top to bottom

First match wins
  • Risk is criticalNever auto-approved2 reviewers
  • Refund over £500refund.issue2 reviewers
  • Refund up to £50, confidence 0.9+refund.issue · low riskAuto-approve
  • Everything elseDefault1 reviewer

Try an action

Before it goes live
Action
refund.issue
Amount
£540
Confidence
0.82
Matched
Rule 2
Outcome
Two reviewers

The same rule as code

// policies/refunds.yamlwhen: refund.issue  amount: > 500then: require 2 reviewerswhy: Over the £500 limit

Improve

Policy what-if

Replay past requests against a new policy and see reviews saved, hours saved, and what it would have missed.

  • Your data, not a guessThe replay uses the requests you actually had.
  • Priced in plain termsReviews saved, hours, cost, and the cases a looser rule would have wrongly let through.
  • Saves nothingIt returns a draft policy. You decide whether to use it.
How Policy what-if works →
app.xevrion.co.uk / policies / refunds / what-ifExample data
Reviews saved312Of 1,480 last month
Hours saved26At 5 min each
Would have missed0Wrongly passed

Reviews per week

Now and draft v13
W1W2W3W4v13

Draft v13

Change
Auto-approve up to £75
Replayed
1,480 past requests
Result
Safe to publish

Observe

Agent tracing

Send traces from any agent. See each model call, tool call and action with its time and cost, next to the review it needed.

  • Works with what you useSend OpenTelemetry data, or use the SDK. No new agent framework to learn.
  • Time and cost per stepYou enter your own model prices, so the cost is yours. Steps with no price are shown as unpriced, never guessed.
  • Loops caughtAn agent that repeats the same call again and again is flagged.
How Agent tracing works →
app.xevrion.co.uk / traces / t_9a41Example data

refund-agent run

3.2 s · £0.04
  • model.call plan1.1 s£0.02
  • tool.call orders.get0.3 s£0
  • model.call decide1.4 s£0.02
  • action refund.issueNeeds 2 reviewersReview

Linked review

Request
r_01HX9
Decided
Approved
Prompt
refund-triage v14
Loops caught2This week
Median run3.4 s
Cost per run£0.04

Observe

Evals and release gate

Run test sets against your agent, compare runs with honest statistics, and block a release when it gets worse.

  • Honest numbersEvery score has a range. A small test set says so, instead of showing a confident number.
  • Judge, with a checkAn AI judge is only trusted once it agrees with your people often enough on enough cases.
  • A gate for CIFail the build when a run is worse than the one you trust.
How Evals and release gate works →
app.xevrion.co.uk / evals / run_41Example data

Pass rate

Baseline against this run
BaseRun 41

Gate

Rule
No drop over 3 points
Drop
−11 points
Confidence
95% interval
Result
Release blocked

In CI

$ xevrion evals gate run_41FAILED. pass rate fell 90% → 79%exit 1

Observe

Prompt registry

Keep prompts in one place with fixed versions and moving labels, so you know which prompt every trace used.

  • Versions never changeEdit a prompt and you get a new version. Old ones stay exactly as they were.
  • Labels you can movePoint production at version 7, or back to 6. Every move is logged.
  • Linked to tracesSee which prompt version was behind any run, and how it scored.
How Prompt registry works →
app.xevrion.co.uk / prompts / refund-triageExample data

Versions

Never edited
  • v15Tighten refund wordingstaging
  • v14Add order lookupprod
  • v13First review rule

Move a label

  1. Eval run 41 passes
  2. Move prod to v15
  3. Traces show v15

Used by

Traces
1,820 on v14
Agents
refund-agent

Questions

What engineering teams ask first

How much code is it?

Create a client with an API key, call it before the risky action and wait for the decision. The rest of your agent stays as it is.

How does my executor know a decision is real?

Approved actions carry a signed, short-lived token that matches the exact action. Your executor checks it before it runs.

Can I test a rule before it goes live?

Yes. Replay a new rule on your own past requests, and let the Policy Gauntlet attack it with look-alike actions and odd numbers.

Can a worse prompt or model be blocked in CI?

Run your saved cases on the old and new version and set the lowest pass rate you accept. The command fails the build if the result falls short.

Know what your agents did.

Start free. Guard your first agent in a few minutes, and keep a record anyone can check.

  • Free plan, no card
  • Signed, chained decisions
  • Checked offline, without us