Skip to content

Rules and safety

There are two ways to keep an agent within bounds. You can tell it what not to do and trust its judgment, or you can make the platform refuse to let it happen. Anychat keeps both and names them differently so you always know which one you are relying on: Guardrails steer, Rules are checked.

Guardrails steer

Guardrails are part of Behavior. They are instructions the agent reads on every turn: topics to avoid, claims never to make, disclaimers to include, plus any hard rule of your own. The agent follows them the way a well-briefed teammate follows a company policy document. They apply ahead of any Playbook and a Playbook cannot override them.

The examples on this page use Mia, the sales-development agent for a med spa called Glow Aesthetics, described in full under the worked example. Mia's Guardrails are no medical advice, no diagnosis, no price for anything not in the catalog, and a line that consultations are with a licensed provider.

Guardrails are the right home for rules that need judgment to apply. "Do not give medical advice" depends on reading what the person asked. The agent is good at that, and lint and Tests tell you when it is not.

Rules are checked

Rules are constraints the platform applies before the agent reads anything and after it writes anything. The agent never sees a Rule and cannot override one. If a Rule fires, its result stands.

Some Rules are platform rules: they apply to every agent and aren't authored by an operator. Others are your own, written on the Behavior · Rules page.

Rule What it enforces
Opt-out A person who has said STOP, or the equivalent, gets no further messages, and the request is honored on the platform, not by the agent noticing.
Compliance Carrier and channel rules: safe hours for the sends Anychat schedules, required disclosures, message pacing.
Reviewed copy sent verbatim When a Playbook, Flow, or Rule calls for a Message, the platform sends its text unchanged.
No cancellation without a clear ask An existing booking is only cancelled or moved when the person clearly asked for it, never because the agent misread a "no thanks".
Times come from the calendar The agent can only offer times that Scheduling returned this turn.
Sandbox traffic Conversations from the emulator — in the console or through a standalone emulator link — are sandbox conversations and kept out of your reporting.

Some of these ship with the platform and are always on. Some ship with a capability and are on whenever the capability is (Scheduling brings the two booking rules above). You can add your own for high-stakes output checks: Mia has one that blocks a reply containing a diagnosis word list. Every Rule that governs the agent, platform and operator alike, is listed in one place on the Rules page, and each time a Rule fires it is named in the turn record.

The line between the two families on that page: a Guardrail is something you would explain to a teammate; a Rule is something you would build into the system so that no teammate could get it wrong.

Rules, on the Behavior page

The Behavior page has a Rules section (Console guide: Rules) listing the agent's own output checks, each labelled Checked or Judged, next to a read-only list of the platform's own rules. A Checked Rule is a pattern check: a name, the plain phrases or /regex/i patterns it looks for in a reply, and what happens when a reply trips it. A Judged Rule skips patterns entirely: a fast model reads the reply against the Rule's own sentence and decides whether it violates it, which is the only way to check rules like "never promise a delivery date" that no pattern list catches reliably. Judging adds roughly a second to a reply and runs only when the agent has an enabled Judged Rule; it fails open, so an error or timeout is treated as no violation rather than a dropped reply.

Either mode's violation gets the same treatment. The default action is rewrite once, then fall back: the agent is asked once to rewrite the reply with the violation named, and if the rewrite still trips the Rule the fallback copy you wrote is sent instead (or, with no fallback, the message is dropped). The block action skips the rewrite. A reply that trips both a Checked and a Judged Rule gets one rewrite round naming both. A Rule can be switched off without deleting it, and each firing is named in the turn record as the Rule's id, regardless of which mode fired it.

Mia's Rule No diagnosis language blocks a short list of diagnostic patterns with the fallback "I can't speak to that, but a Glow provider can at your consultation." When the list is empty it says so and notes that Scheduling's own rules (cancel or move a call only on a clear ask) are on whenever Scheduling is.

The platform's own rules sit beside your list, each marked with how Anychat enforces it: tool gates and send-time rules like opt-out and safe hours show Checked, because they're enforced in code the same way your Rules are. The baseline guardrails every agent ships with show Instructed instead: they are document text the model reads, not a check run against the reply, and the Rules page says so rather than overstating what's actually enforced.

Rules are written in the agent's portable document (rules under definition in the export; documents exported before this shipped, or written against the retired policies key, still import) and applied by import. See Export / Import in the Agent API for the shape.

Messages are reviewed copy

A Message in Content is text a person on your side has read and approved. Wherever a Message is used, that exact text goes out with its placeholders filled: Mia's outreach opening, her booking confirmation, her opt-in request. The agent may choose when a Message applies (in an open-ended Playbook) or a Flow step may call for it, but neither can change its wording. If you need different wording, you edit the template, and the change is visible in Content.

This is what lets you promise a compliance reviewer that the message a person receives at a given moment is a message the reviewer has seen.

Impossible by construction

Some mistakes are not prevented by a rule; they are prevented by the shape of the agent's reply. The agent does not write free text that the platform then inspects. It fills in a reply form whose blanks are set for this turn from what is actually true. Because the form has no blank for a thing that does not exist, the agent cannot produce it.

The agent cannot… Because…
Offer a time slot that is not on the calendar The time-picker blank only accepts times Scheduling returned this turn; when none were fetched, there is no picker to fill.
Show a card for a Thing you do not have The Thing blank only accepts items from your catalog.
Send a template that does not exist The template blank only accepts names from Content.
Put rich cards on SMS The SMS reply form has no card blank; the reply is plain text with a short length limit.
Rewrite a template A template goes out by reference; the agent names it, the platform renders it.
Enter a Playbook whose capabilities are not ready The Playbook is not among the choices offered when the Playbook is picked.

Everything else the agent says is its own words, shaped by the document and checked by Rules. The distinction matters when something goes wrong: an invented time slot is not a bug you patch with a stronger instruction; there is no way to express one.

What is not a rule

Two things people sometimes reach for as rules belong elsewhere. "Confirm before booking" is a step, and belongs in the booking Flow, where it always happens. "Ask about treatment interest early" is a way of working, and belongs in the Qualify Playbook body, where the agent applies it with judgment.

What's next