Cereva

The policy engine for AI agents

Before your agent touches money, it asks Cereva.

Cereva compiles the rules your team actually follows into versioned, executable policy. Agents call it and get a verdict they can defend — the decision, the rule, and the evidence behind it.

SAME REQUEST · FIVE RUNSinput $240 · defect · 12d
A sampled language modelruns 15 of 30
Cereva · compiled policy
awaiting run…

Model answers illustrative. The 2,000 evaluations run live in this tab.

Your agent

Any framework. One tool call over MCP or REST.

Cereva

Rules extracted from Slack, approved by a person, compiled to a pure function. No model call.

Verdict

Decision, rule, policy version, and the thread that set the rule.

Where it runs

Anywhere an agent’s next step is hard to undo.

Customer refunds

Defective order, $1,890, eight days old.

escalate· over the auto-approval cap

Discounts & credits

Churn call. The agent wants to offer 30% off.

decline· 15% ceiling without a lead

Payouts & holds

Seller requests payout with a dispute open.

decline· hold until the dispute closes

Account actions

Third chargeback this quarter. Suspend?

escalate· suspension needs a named human

Cancellations & reships

Damaged in transit, photos attached.

approve· reship within policy

Compliance gates

EU account requests a full data export.

escalate· routed to the DPO queue

Every surface is the same engine pointed at a different set of rules.

How it works

From Slack threads to an API your agents call.

  1. 01Extract

    A model reads Slack and tickets and proposes rules — condition, effect, and the messages behind them.

  2. 02A person approvesThe gate

    A named reviewer accepts or rejects each rule, evidence attached. Nothing compiles without this gate.

  3. 03Agents call it

    One tool over MCP or REST. Same input, same verdict, every time — no model in the decision path.

Request
// MCP tool call — any agent framework
{
  "tool": "cereva.evaluate",
  "context": {
    "order": {
      "amount_usd": 1890,
      "days_since_purchase": 8,
      "reason": "defect"
    },
    "customer": { "tier": "priority" }
  }
}
Response
{
  "decision": "escalate",
  "decided_by": "RULE-031",
  "policy_version": "v14",
  "escalate_to": "Support lead queue",
  "citations": [
    { "id": "EV-SLK-0159", "source": "#support-ops" }
  ]
}

Any agent that can call a tool gets a verdict it can quote to a customer and to an auditor. Swap the agent next year; the policy stays.

Why it holds up

Four properties. Each one falls out of the mechanism.

Deterministic

Same request, same policy version, byte-identical verdict. A pure function has nothing else it can do.

On the record

Every verdict cites its rule, its version, and the thread where a named person set the rule.

Injection-proof

Customer text carries zero policy authority. No predicate can read it, so no wording changes a verdict.

Drift-aware

Executable policy replays against real decisions and counts the ones that contradict a rule.

The offer

Book a policy audit.

Connect Cereva read-only to ninety days of Slack and your helpdesk. We come back with three rules your team follows that are written nowhere, and one contradiction you did not know you had.

  1. 01

    Read-only, 90 days

    Slack and your helpdesk. No write scopes, no agent changes, nothing pointed at production.

  2. 02

    We extract and review

    Proposed rules come back with the threads behind them, to accept or reject.

  3. 03

    You keep the findings

    Whether or not you buy anything. The unwritten rules were always yours.