Skip to content
Governed action layer for customer engagement

Outreach your compliance officer
can sign off on.

Regent sits between your AI and outbound channels, enforcing your rules before an engagement becomes a real-world action. Your AI proposes; independent rules govern; the audit proves every decision — including the ones that didn't send.

Your systemsYour AI proposesREGENT governsYour channel
Run a Guided Eval on your websiteExplore the product

Prefer to talk it through? Book a Guided Eval — No public booking system is pinned yet — the Guided Eval is arranged by email with the pilot owner.

4+ governance gates per decision
0 crisis flag overrides at decision time
held decisions documented identically to sent
WhatsApp-native · MENA-first
first proving tenant · UniversalHealthCare.ai
Regulatory context

The CBUAE directive (April 30, 2026) requires licensed UAE financial institutions to use controlled channels with full audit trails for customer communications.

Read the trust page →
How it works
Four phases. One governed act.
Regent is the system that governs the act of reaching out. The AI is one step inside it — not the authority over it. AI proposes. Rules govern. Every decision leaves evidence.
Phase 01 · Context

Contactability & hard stops

Before the judgment engine evaluates anything: is there an active channel? Is a crisis flag set in the accepted snapshot? Is there a global opt-out? A hard stop resolves the operation here, and the AI never sees the case.

Phase 02 · Judgment

AI proposes

The judgment engine receives the cleared context and proposes: reason, intent, channel, content. The proposal is recorded with the model version pinned to that decision.

Phase 03 · Governance

Independent rules decide

Proposal-specific consent, content policy, recent human contact, frequency caps and the send window run independently, after the proposal. The send is never the AI's alone. Your policy runs last.

Phase 04 · Action

SENT · HELD · ESCALATED · DEFERRED

Every outcome — including the ones that don't send — is recorded with the full decision chain. Exact inputs, policy versions, model version, gates and recorded outcome are preserved and integrity-verifiable on demand.

Governed outcomes · healthcare example
Four outcomes. All on the record.
The decisions that didn't send are documented as thoroughly as the ones that did.That's the product.
req_9f3a2b1c · 14:32 UTC
SENTOutcome: sent
Lab results ready. Every hard stop cleared, the AI proposed a send, three governance gates passed, and the provider accepted the dispatch.
Context · pre-agent
Contactability · no hard stops✓ CLEAR
SEND — Lab results ready. Patient due for follow-up appointment.
Governance · post-proposal
Consent & content policy✓ PASS
Frequency cap · 1 of 3✓ PASS
✓ Dispatched · provider accepted
Read the full record →
req_8e2b1a0d · 10:41 UTC
HOLD · TerminalOutcome: terminal hold, not sent
The AI proposed a check-in for a patient who had gone quiet for six weeks. Regent held it — her care team had spoken with her the previous day.
Context · pre-agent
Contactability · no hard stops✓ CLEAR
SEND — Patient disengaged 6 weeks. Re-engagement check-in due.
Governance · post-proposal
Recent human contact on record— HOLD
— Terminal hold · no dispatchTerminal hold · no dispatch. Future outreach requires a new customer-triggered request.
Read the full record →
req_7d1a0f9c · 16:47 UTC
ESCALATEDOutcome: escalated to a named human, not sent
A routine post-discharge engagement was requested. Regent found a crisis flag in the accepted snapshot before invoking the AI. Dr. Nour Khalil was alerted. No outreach was proposed and none was sent.
Context · pre-agent
Contactability✓ CLEAR
Crisis flag⚠ ESCALATE
AI judgment — NOT RUN — blocked by the pre-agent hard stop
⚠ Not sent · Dr. Nour Khalil alertedNon-overridable at decision time. There is no operator bypass.
Read the full record →
req_6c0f9e8b · 22:14 UTC
DEFERREDOutcome: deferred, customer re-push required, not queued
An annual check-in was pushed at 22:14 local time, outside the configured send window. The operation ended there.
Context · pre-agent
Contactability · no hard stops✓ CLEAR
SEND — Annual check-in. Patient last contacted 11 months ago.
Governance · post-proposal
Send window · 08:00–21:00 localDEFER
DEFER_REPUSH_REQUIREDOperation ended · no queue · customer re-push required.
Read the full record →
SEND UNCONFIRMEDOutcome: send unconfirmed, provider acceptance unresolved

And one more ending, because pretending otherwise would be a lie.

Sometimes every gate passes, dispatch is authorised, and the provider's answer never comes back.Provider acceptance unresolved · no blind retry · investigation required. Regent does not guess, does not mark it delivered, and does not retry blind into a possible duplicate.

Read the send-unconfirmed record →
Every decision leaves a receipt
Not a black-box score.
Not a campaign log.

The evidence for why this person was — or was not — contacted. Structured, linked to the dispatch, tamper-evident with governed redaction. The message carries no audit payload. The dispatch is linked to its audit trace; the trace itself stays in Regent.

SENT, HELD, ESCALATED or DEFERRED —
the governed decision is the product.
DecisionHELD · terminal
ReasonRecent human contact on record
AI proposalSEND
Policy versionuhc_reengagement.v3
Received by Regent10:41:08 UTC
Resolved10:41:11 UTC
Tenant snapshot10:41:05 UTC · tenant-asserted
Message sentNo

Regent's freshness guarantee begins when Regent receives the push. The snapshot timestamp inside the request is tenant-asserted metadata and is never the basis of that guarantee; data age before the push is the tenant's pipeline responsibility.

The differentiator
The message that
didn't send is the product.

What most engagement platforms show you: what was sent. What Regent shows you: why it was safe to send — and what it refused, and why. A compliance officer's confidence isn't built on delivery metrics. It's built on proof that the system held when it was supposed to hold, and the record that shows it happened.

12
of 14 operations in the demo dataset never reached a recipient
0
overrides permitted on a crisis flag at decision time
1
record format, whatever the outcome was
Scope

What Regent is, and what it is not.

The fastest way to understand a governed action layer is usually to hear what it refuses to be.

Regent is

  • A governed action layer between probabilistic judgment and consequential outbound action.
  • A deterministic gate layer that runs your rules after the AI proposal and before any send.
  • An evidence system: every decision — including the ones that did not send — leaves a receipt.

Regent is not

  • Not a campaign optimizer. Regent does not try to raise your send rate.
  • Not a replacement CRM or ESP. You keep your systems of record.
  • Not merely a post-hoc archive. The gates run before the action, not after it.
  • Not generic policy-PDF management. The rules are executable and they are what stops the send.
The product

A console for the decisions, not the campaigns.

Public, synthetic, and open right now — no login and no credential anywhere in the page.

Decision Feed

Every governed operation, including the ones that did not send. 14 in the synthetic dataset — 12 of them never reached a recipient.

Open in the demo console →

Policy

The rules that stopped the send, in the order they run: pre-judgment hard stops, then post-judgment governance. 3 versions, read-only.

Open in the demo console →

Escalations

Named target, acknowledgment SLA, fallback ladder and the operator alarm as distinct states. 4 examples across all four.

Open in the demo console →

Channel Health

Masked sender, connection state, webhook verification, template sync and token expiry across 3 connections. Never a secret.

Open in the demo console →
See all six product surfacesOpen the demo console
Guided Eval

See what Regent would do with public website context — before you connect anything.

Give Regent a public website. It reads the site server-side, drafts a temporary evaluation profile and fabricated personas, and runs the real governed chain over them. Every action is simulated.

Runs now · your website

Guided Eval

Give Regent a public website. It reads that site through a hardened server-side boundary, drafts a temporary evaluation profile and synthetic personas, and runs the real governed decision chain over them.

  • A public https:// address, or a reviewed example
  • Hardened server-side source boundary
  • Temporary evaluation profile, never a production configuration
  • Fabricated personas through the signed gate chain
  • Independent judge, and a receipt for every outcome
Run a Guided Eval on your website

Every persona below is fabricated and every action is simulated. Regent sent nothing, to anyone, on any channel.

Synthetic · educational

Governance Playground

Pre-authored scenario → toggle one piece of context → watch which gate resolves it.

No website, no model call and nothing transmitted. Set a crisis flag and watch the judgment engine stop being invoked; move the clock outside the send window and watch the operation defer. It is a sandbox for understanding the gate order, not an evaluation of any company.

Open the Governance Playground

Synthetic educational sandbox. Pre-authored scenarios resolved by local deterministic rules — it does not read a website and it is not the personalized Guided Eval.

Integration

One endpoint. You keep your systems.

Push-only. You call Regent on your own trigger cadence; Regent does not connect to your EMR, CRM or any other system, and you do not maintain a webhook to receive decisions.

POST /v1/engage

The public contract. You push a snapshot of what you already know about a subject; Regent governs the outcome and returns a governed operation with its audit trace.

Your trigger cadence

Regent does not schedule anything. Your own scheduler decides when a subject is due; a push means "act now", and the freshness guarantee starts when Regent receives it.

Your Meta identity

Regent governs and dispatches from your own WhatsApp Business identity through your provisioned Meta connection. Your number and business account remain yours; Regent owns the governed send operation and its provider lifecycle record.

No webhook to build

You do not maintain an inbound integration to receive decisions, and Regent needs no access into your systems. Provider lifecycle webhooks flow to Regent invisibly.

Read the integration guideSee the request shape in the demo console →

Land-in-days integration is the design target — one push endpoint, no agents to configure, no inbound access. No integration-time guarantee is published. The number will be stated when it has been measured against real tenants.

Trust

What is built, and what is not built yet.

A governance product that overstates its own compliance posture has already failed at the thing it sells.

Built
  • Tenant identity from authentication, never from the request body.
  • Raw recipient addresses stay outside the judgment runtime.
  • Secrets held in the vault, never returned to a browser.
  • A deterministic gate layer the model cannot argue with.
  • Idempotency — zero duplicate dispatch authorisations.
  • tamper-evident with governed redaction.
Not claimed

No SOC 2 / ISO 27001 / HIPAA certification claimed today.

Nothing here should be read as certified, accredited, or equivalent to a certification. The Trust page names the pre-launch floor that gates the first live tenant, the work running in parallel during the trial, and the legal and certification work that comes after.

Trust & data handling
Design Partner Pilot
Prove it on one decision.

One governed use case, one channel, one policy profile. A Guided Eval first, then governed traffic on a single decision path, then an evidence review with the people who have to sign off. Pricing and cohort terms are set with the pilot owner.

Start a design-partner pilotTalk to the pilot owner
  • One governed use case
  • Your own WhatsApp Business identity
  • A named technical owner
  • A named escalation owner
  • Synthetic eval before anything connects
  • An audit and evidence review
Common questions
What compliance buyers ask.
What data leaves our system?
Nothing you don't push to us. You send a DecisionRequest carrying the context you have already assembled. Regent processes it, records the audit trace, governs the outcome and dispatches when the outcome is a send. There is no connection to your EMR, CRM or anything else, and no inbound access of any kind.
What does the audit record actually contain?
Every check that ran — contactability, crisis flag, consent, content policy, frequency cap, window — with the input values at decision time, the policy version in effect, the model version pinned to the decision, and the final outcome. Exact inputs, policy versions, model version, gates and recorded outcome are preserved and integrity-verifiable on demand. Inspect reconstructs the recorded decision context — the inputs, versions, gates and outcome exactly as they were. It does not re-run the model or promise an identical regenerated answer.
How does integration work?
POST /v1/engage. Push-only. You call Regent on your own trigger cadence; Regent does not connect to your EMR, CRM or any other system, and you do not maintain a webhook to receive decisions. Tenant identity comes from authentication only, never from the request body. Land-in-days integration is the design target — one push endpoint, no agents to configure, no inbound access. No integration-time guarantee is published. The number will be stated when it has been measured against real tenants.
Does Regent send via WhatsApp directly?
Regent governs and dispatches from your own WhatsApp Business identity through your provisioned Meta connection. Your number and business account remain yours; Regent owns the governed send operation and its provider lifecycle record.
What happens when a crisis flag is set?
When a crisis flag is present in the accepted request context, the pre-agent hard stop resolves the escalation before the judgment engine is invoked. No outreach is proposed, none is sent, and the named escalation path executes. Non-overridable at decision time. There is no operator bypass.
What is the difference between a hold and a defer?
Terminal hold · no dispatch. Future outreach requires a new customer-triggered request. A defer is different: operation ended · no queue · customer re-push required. Neither one sits in a queue waiting to fire later.
What if the provider never answers?
When the provider send response is lost, no provider-backed correlation exists. Matching on recipient and timestamp is a heuristic that can support investigation, and it never establishes acceptance. The state stays unknown until a provider-supported identifier resolves it, or an operator resolves it manually.
Can we evaluate without real patient or customer data?
Yes, and that is the default. Pre-contract evaluation runs against public website context and fabricated personas. The Guided Eval reads a public website server-side, requires no production integration and no real customer data, and dispatches nothing; any legal or procurement paperwork required by either party is handled separately. The Guided Eval on this site is a synthetic product demonstration you can run right now. A Guided Eval with the pilot owner uses synthetic personas matched to your own user profile. Real data comes later, under your terms.
Who controls the rulebook?
You do. Your consent definitions, crisis criteria, content policy, quiet-hours window and frequency caps are tenant-owned and tenant-configured. Regent runs your rules; it does not set them. The one thing you cannot configure away is the crisis hard stop at decision time.
What is your compliance certification status?
No SOC 2 / ISO 27001 / HIPAA certification claimed today. Compliance-first architecture, stated as architecture. Controls that exist are listed as built; controls that do not exist yet are listed with the workstream that owns them. The Trust page separates what is built, what must ship before the first live tenant, what runs in parallel during the trial, and what comes after.
Guided Eval
See what Regent would decide — for your users.

Start with the synthetic eval on this site: it takes a minute, connects to nothing, and shows you the whole governed decision chain. When it fits, a Guided Eval with the pilot owner runs your own scenario against synthetic personas matched to your user profile. No real data. No integration before you sign anything.

Run a Guided Eval on your websiteBook a Guided Eval
UniversalHealthCare.ai is tenant #1 for the controlled trial. First governed traffic is running. Pilot cohort is open.