AI that does a named job and shows its working.
It proposes the audience, drafts the message, checks every send and explains the result, from your own data. Every proposal shows why, the figures are computed rather than guessed, and you accept or reject each item.
Server
Facts by rule. Judgment only where it is needed.
Deterministic where a rule can prove it. The model only where judgment is genuinely required. Not the last step, and not the one doing the arithmetic.
Code establishes the facts and the constraints. The model contributes the part that needs language or ranking. Code validates what comes back before it reaches you. Each capability lives in the screen where the work happens, every run is recorded, and you accept or reject items individually.
Each does a named job and shows its working.
Proposes the audience
Candidate audiences are generated from your real data first. The model ranks and names them and writes the reason. It cannot invent a condition. Rejected candidates are shown with the reason they were refused.
- From your real data first
- Ranked, named, with a reason
- Refused candidates shown, with why
Writes the message
Drafts channel-aware variants grounded in a brand voice profile you maintain, in the way your recent templates actually read, and in the audience targeted. Every draft passes a deterministic check before you see it.
- A variant per channel
- Your brand voice, your templates
- Checked before you see it
Checks the template, per channel
Four layers in front of a send, from most certain to least: hard-coded personal data and missing opt-out, WhatsApp structural rules, your own keyword blocklist, and only then the model, for tone and restricted claims. A deterministic failure blocks.
- Personal data and opt-out
- Channel rules and your blocklist
- Tone last, and only as judgment
Explains the result
Every ratio is computed by code. The model writes the narrative and three next moves, each naming the capability that would carry it out.
- Every ratio computed
- A written narrative
- Three next moves, each actionable
A complete Story from a single topic, and two gates before anyone sees it.
Give it a topic. A Creative Director turns it into a brief: what the story is for, what it should say, how it should be shaped. A reviewer checks that brief against fixed rules first and a creative read second, and sends it back if it falls short. Only then does a Story Generator build the pages. A final reviewer checks the result the same way, hard rules first, judgment second. Both gates run before anything reaches your team.
Bring your own agents.
Connect a compatible agent through xNotify's MCP Server and it can work the platform through the tools you scope to it: read-only analysis, preparing a draft, or, where you grant it, actions that send a message or change a record. Your agents can publish Stories too, under the same scope.
An authorised agent can launch a send, and a sent message cannot be unsent; an agent with write scope can also spend and can change records in the systems a journey calls. That is why scopes, dry-run and idempotency exist, why every call is logged with the agent and subject behind it, and why deletion stays a human action in the portal with a named person against it. Grant the narrowest scope the job needs and rehearse writes as a dry run first.
- Tools an authorised agent can use to build a segment, launch a campaign, run a journey, submit a template, send a message and publish a Story, each one scoped separately
- Filtered to the scope you grant
- No tool deletes data; deletion stays a human action in the portal
- Repeated calls replay rather than repeat
- Any write can be dry-run first
- Access can be revoked for one agent, one subject or the whole tenant
What the model sees, and where it runs.
- 01
Personal data is filtered before a model is called
Three independent filters sit between your data and any model, all before the call: aggregation over event variables rather than rows, pattern rejection of identifiers such as emails, phone numbers and tokens, and a scan of the payload before it leaves. Filters reduce the risk; they do not make it zero, which is why the model that produced each result is recorded and every run can be reviewed.
- 02
Where inference runs
AI capabilities use external model providers. Hosting the platform on your premises or in your country does not by itself change where an enabled AI capability processes information. If you require in-country or self-hosted inference, raise it during evaluation; the provider layer is designed to be extended, and that is scoped work.
- 03
Every run is recorded
Each capability lives in the screen where the work happens. You accept or reject items individually, and the record shows what was proposed, what was refused, and why.