One set of rules runs everything.Write it once. Change it safely. See every step.
Most support AI hides your policies inside a prompt nobody can read. We keep them in one place you can see and edit. The Agent follows them, Scorecards grade against them, and Analytics tells you which ones to fix.
Your business, written down.A living operating model, not a prompt.
Everything your best support person knows, in six parts, so they can finally take a real holiday. When one part changes, every product that depends on it changes with it.
model
signal → examples → hypothesis → owner → change → measured result → back into the model
Every request type is a flow.You can read it. So can your auditor.
Steps, checks, conditions, actions, tags and escalation rules on a drag-and-drop canvas, or in a structured editor if you prefer lists. Click any node below to see what it holds.
Simplified mock of the editor with illustrative values. Your flows use your own policies, limits and systems.
Type the change.See exactly what it touches before it goes live.
Describe a change in plain words. Pronomy asks what it needs to know, shows the diff, flags conflicts, writes test cases and runs them on safe examples. You approve. It ships as a new version you can roll back.
- —Waiting for a change request.
Nothing changes until you approve the scope.
Illustrative data. This is a scripted preview of change-by-chat, which is in development. Today, flows are edited in the flow editor (Live), with our team's help during onboarding.
Every rule has a version.Every mistake has an undo.
Each change gets a number, an author and a reason. If a new version behaves badly, you roll back in one click and the old rules are in force again.
We think of versioning as a kindness to tired ops leads. Everyone has shipped a rule change at 6 p.m. on a Friday. Nobody should have to fix it by hand at 11.
The same versioned rules will drive both the Agent and the scorecards. A conversation is graded against the rules that were in force when it happened, not against rules you wrote last week.
Refund if within 14 days and under $100
does it
check it
Ctrl+Z for policies: undoes the newest rule version. A preview: click it, or press the shortcut while the button is focused.
- v307Escalate disputes before any refundIn force
- v306Reply in the customer's language by defaultIn force
- v305Refund window 30 → 14 days
- v304Tag partial refunds separately
Illustrative data. Versioning and one-click rollback for shared rules (Agent and Scorecards) are in development. Nothing on this page changes a real flow.
It works next to your team first.Your customers see nothing until you say so.
In shadow mode the agent reads each ticket, runs the flow and writes an internal note: the reply it would send and the actions it would take. Your team compares it with what they did. Think of it as a new hire who writes everything down and isn't allowed near the till yet.
- No reply is sent and no action runs
- You see where it's right, where it's wrong, and why
- You go live on one flow once the notes earn it
- ✓Found 2 charges of $12.99 on Oct 3
- →Would refund the duplicate (policy: refund_window v307)
- →Would tag: duplicate-charge
Proposed reply (ES): Tienes razón, se cobró dos veces. He devuelto el cargo duplicado de $12.99…
Agent replied: same refund, same tag. Match.
You decide how much it does alone.Per action, per amount, per case type, per risk.
Analyze & recommend
It reads the case and suggests. Nothing else.
Draft & propose
It drafts the reply and the actions. A person sends.
Act after approval
It does the work once a person clicks approve.
Autonomous in a flow
It acts alone, only inside the flow you allowed.
Mandatory handoff
Under set conditions, a human always takes over.
Example: refunds under $50 at level 4, refunds above at level 3, any chargeback threat at level 5. How the Agent uses the ladder →
Worried it only ever turns up? It turns down too, per action, whenever you like. And level 5 exists because some customers simply deserve a person.
Every step, written down.Promised, attempted and done are three different things.
The log records each check, each rule version and each API call with its real response. The agent only tells a customer "refunded" after the billing system confirms it, because optimism is not a status code. Scorecards read the same log.
2026-10-21 09:14:02.118 ticket.received channel=email lang=en 2026-10-21 09:14:02.402 flow.matched refund_request v307 confidence=high 2026-10-21 09:14:02.950 check.customer ok match=email+last_payment 2026-10-21 09:14:03.311 check.charge ok amount=29.00 USD age=1d 2026-10-21 09:14:03.420 policy.eval ok refund_window v307 → autonomy=4 2026-10-21 09:14:04.870 action.refund attempted target=billing 2026-10-21 09:14:05.902 action.refund confirmed status=succeeded 2026-10-21 09:14:06.010 action.cancel confirmed renewal=off 2026-10-21 09:14:06.190 reply.sent claims=[refund,cancel] all_confirmed=true 2026-10-21 09:14:06.240 crm.update ok tags=refund,cancel-not-applied 2026-10-21 09:14:09.000 scorecard.queued rules=v307
Sample log with illustrative data. Field names are simplified for reading.
If your refund policy currently lives in a shared doc, a Slack thread and one person’s memory, you’re normal. Bring all three to the call and I’ll turn them into one flow while you watch.