How Celeste decides what to do, and whether to hit send.
Two pipelines sit between Celeste and your customers. One decides whether each proposed action gets executed, held for a person, or refused. The other decides whether the drafted reply sends itself or waits for review. Both are deterministic code, out of the model's reach. Prompt injection can shape what Celeste proposes, never what the platform permits.
Each setting can only subtract autonomy. No setting can override another's refusal, and the strongest applicable restriction always wins.
Every gate between a customer message and Celeste's reply.
A message earns its way to a sent reply. Fail any gate and the conversation takes the safer exit instead.
-
Admission control
ThrottledFlood protection and per-sender caps run before anything else. When a cap is hit the sender is throttled politely, web chat degrades to message-taking, and nothing bills.
-
Billing gates
Routed to your teamNo live subscription, a lapsed period, or a reached spend cap means Celeste doesn't answer. The message is recorded and routed to your team, and nothing bills.
-
Risk screen
EscalatedThreats, legal exposure, and vulnerable senders go straight to a person. Every write that turn is suppressed; reads and a draft are still prepared for the reviewer.
-
Triage
FiledNewsletters, receipts, and notifications are filed. No reply, no bill.
-
Turn cap
EscalatedA conversation that has gone on too long is handed to a person instead of looping forever.
-
Topic classification
Stricter topic winsFollow-ups keep their topic. When a turn could plausibly span two topics, the stricter topic's settings govern the whole turn.
-
Context
Retrieve and rank your knowledge, load the topic's procedures, and load customer memory only when identity allows it.
-
Draft and tool loop
Gauntlet on every actionCeleste drafts the reply, and every action proposed along the way runs the full authorization gauntlet below. If the agent can't help at all, a person takes it; the customer is never left hanging.
-
The autosend gate
Fifteen brakesTopic mode first, then fifteen ordered brakes. All clear: the reply sends. Any brake fires: the draft waits in the Support Inbox with its hold reason and a link to the setting that fired.
-
A person decides
Support InboxApprove or edit the draft, approve a held action (the gauntlet re-runs first), or mark it handled so nothing sends at all.
Every proposed action passes these checks, in this order.
Reads always run, so Celeste can look things up freely. Everything past the read check gates writes only: the refunds, the account changes, the things that matter.
Identity guards
RefusedAn unverified sender can't be used to look anyone up, and account data can't be touched before verification or by a tool that can't be scoped to one account.
Facts resolve, or fail closed
Fails closedRules read live facts before they're checked. A fact that can't be read counts as its limit having fired.
Enabled, on-topic, in bounds
RefusedIs the tool enabled at all? Is it allowed on this topic? Are the details well-formed and within bounds? These structural checks preempt everything else.
Changed tool
HeldA tool whose definition changed since the owner risk-classified it is held until it's re-classified. This hold preempts even an approval.
Practice stays on paper
Paper onlyOn a practice topic, safe reads run for real. Writes are proposed on paper only, never executed.
Limits and facts
Refused or heldEvery rule you've written is evaluated and the strongest effect wins. A Block is a wall nobody can approve past. An ask-first rule holds the action for a person.
Procedure scope guard
HeldA write governed by one of your procedures only runs when that procedure actually loaded for this turn.
The autonomy gate
HeldThree legs, all required: the topic is in Autonomous mode, the tool's risk classification is current, and the action sits within the topic's action ceiling. The hold reason names the failing leg.
Account scope injected
RefusedThe verified customer's account scope is written into the action itself. If that injection fails, the action is refused rather than run wide.
Dedup, execute, verify
Once, verifiedA durable claim stops the same write from running twice, even across message redeliveries. Then execute with a timeout, sanitize the output, and tag how trustworthy the evidence is for the reply gate.
Approval is not a bypass.
When a person approves a held action, the platform re-checks that the decision is still pending, re-reads the facts fresh, and re-runs the whole gauntlet before anything executes. A Block added after the hold still refuses. A limit tightened after the hold still applies.
Fifteen ordered brakes between a draft and your customer.
The topic's mode sets the baseline. Then the brakes are checked in order, and the first one that fires owns the hold reason a reviewer sees.
Recorded as a practice draft. Never sent, never billed.
Always queued for a person. Nothing sends on its own.
May send itself, if confidence clears the topic's bar and none of the fifteen brakes fires.
- The sender isn't verified
- A procedure issue or clash was reported
- The reply would reveal an internal procedure
- An escalation trigger matched: an always-escalate topic, a workspace escalation phrase, or an upset customer
- The topic classification is uncertain
- The fact-check couldn't run
- A claim is unsourced or contradicted
- Celeste hit a capability gap
- An action is held for approval
- An action was refused
- A write failed with an error
- The reply has no supporting sources
- The reply only echoes the customer back
- The evidence came from an untrusted tool
- It failed the agent's own pre-send review
Anything held lands in the Support Inbox with its reason. Approving and sending a held draft runs one last check that no internal procedure leaks.
Four rules of thumb the pipeline always obeys.
Billing checks come first
A lapsed workspace never auto-answers; messages route to your team instead, and nothing bills.
Safety before topic dials
A threatening sender suppresses writes no matter how autonomous the topic.
Actions before the reply
A held or refused action brakes the reply that depends on it.
Approval opens one door
A person's approval satisfies exactly one hold, never the walls behind it.
Six surfaces, all yours, all subtract-only.
Every gate above is fed by a setting you own. None of them can grant autonomy another setting took away.
What Celeste can do
Which tools exist, on which topics, and the owner's risk classification of each one, pinned to the tool's current definition.
Topic Autonomy
Per-topic mode, the confidence bar, the autonomous action ceiling, and always-escalate flags.
Limits and facts
Amount, fact, and time-window rules, each either ask-first or a hard Block. An unreadable fact counts as fired.
Escalation phrases
A workspace-wide keyword tripwire, matched against the customer's last message on every topic.
Procedures
Private playbooks, the write tools they govern, and the send-time check that none of them leaks.
Customer Identity
Per-channel identity posture, the verification method, and per-tool account scoping.
This page describes the shipped enforcement code, traced gate by gate from the source. When the pipeline changes, this page changes with it.
See the brakes for yourself.
Start your free month and every gate here runs on your own data, under limits you set. Prefer to look first? Open the read-only demo and check the Support Inbox: each held draft names the brake that fired and links the setting that owns it. For the data-handling side, read Security and Trust.