Control what Cevanos can access, disclose and do. Set policies and approval limits, verify identity for sensitive requests and review the evidence behind each decision.
Define what the agent can access, when it can act and how your team reviews the outcome.
What can it know?
Sources are scoped per agent. Retrieval is inspectable: every answer lists the passages it used, and you can quarantine a source without deleting it.
What can it do?
Actions are classified as reads, writes and money movers. An action is only a capability; a policy decides when it fires.
Under what conditions?
Order value, customer tenure, prior claim count, time since delivery, channel, verified identity. Written in English, compiled to deterministic logic.
When does it need sign-off?
Above the ceiling, the decision becomes a queued approval with the full case attached, not a dead end for the customer.
When must it escalate?
Low confidence, conflicting policies, unverified identity, abuse signals, legal or safety language, or an explicit request for a human.
How was this decided?
Every decision writes a receipt: the policy that applied, the facts it matched, the action taken and the money spent against the cap.
Was the outcome right?
Outcomes are checked after the fact: reopened tickets, reversed refunds, repeat claimants, all fed back as policy suggestions.
Can we roll it back?
Restore earlier policy versions and review available corrective actions. Reversing a completed action depends on the connected system and whether the action can still be undone.
Policies define when an action is allowed. Guardrails restrict actions and data access beyond those permissions. Cevanos checks proposed actions against these controls before execution.
The model proposes an action. The control layer checks whether it is permitted. Outcome reviews help identify mistakes even when a decision passed its policy checks.
Require verification appropriate to the information or action involved. Apply access controls to lookups as well as changes.
No identity has been established. Public information only.
An identifier matches a record. This does not establish ownership.
The customer has stated that the account is theirs. This alone does not authorize access to private information.
A configured verification check has passed. Action-specific permissions still apply.
The customer is authenticated through your identity system. Role permissions and transaction checks still apply.
Write the rule, review the conditions and limits, then test the policy before activation.
Waive a late fee of up to $50 when the customer has paid on time for the last six months and has received no waiver in the last 12 months. Require the configured identity check. Send requests above $50 to our team for approval.
When all of this is true
How much it may spend
Above $50 the agent stops and queues it for a person. A workspace cap of $2,000 a day sits over every policy, and the lower of the two always wins.
It does this
Otherwise it hands over
Hover any condition to see the words it came from. One decision is bounded by one policy. No stacking, no silent composition. When two policies could apply, the lowest ceiling wins and the conflict surfaces in the simulator, not in front of a customer.
Policies can use information from your connected business systems. Explore supported integrations
Review the policy version, supporting information, action or handoff, and resulting status in one decision record.
Hover any line to see what it means
Refusals write receipts for the same reason approvals do: the customers you turned away are the ones most likely to appear in a chargeback, a review, or a regulator’s question. A tool that only logs its wins can’t answer any of them.
A decision can satisfy every control and still be the wrong call, and no amount of permission checking will notice. Cevanos watches what happened after the decision, not only whether it was allowed.
A resolution the customer reopens within a week was not a resolution. Cevanos traces every reopen to the policy and version that produced it, so a rule that looks efficient in a dashboard and annoying in real life has nowhere to hide.
Every time someone on your team reverses the agent, that is a vote that the rule is wrong. One reversal is noise. Three against the same policy in a month is a signal, and it arrives as a proposed change rather than as a complaint in a retro.
Refusals get audited too. When your team keeps overriding the same declines by hand, the rule is too tight and it is quietly costing you customers who never complained. That pattern is invisible in a resolution rate and obvious in a decision log.
Your agents approved 39 of 47 anyway. Median order $138. Raising the ceiling to $150 would have covered all of them.
ceiling change · simulatedYour returns page says 30 days. Your team honoured 24 of 31 past it. One of those two is wrong, and the page is what customers read.
policy vs published termsMedian settlement 25% of order value. Policy #33 is drafted and simulated, not live until you say so.
awaiting approvalEvery signal becomes a proposed change. None of them goes live on its own.
Reopens, reversals and overridden refusals are traced back to the policy version that caused them. Everything the agent escalates is clustered against what your team actually did about it. Recommendations stay drafts until your team reviews and approves them.
Review the controls available today and the capabilities still in development.
We are early, and we would rather say so than let you find out later. Nothing on this page is a certification, and a statement here is not a contractual commitment — ask for the current written position on anything your review depends on.
