Every “custom AI agent” product eventually hits the same wall: someone in the business is going to quote a number, and some day the number is going to be wrong. The product that makes its customer's brand say “the Royal Suite is available” when it is not, has not failed a conversation — it has failed the company.
That wall is why we don't build “an agent that knows about your business.” We build an agent with a mandate, and the enforcement lives in the platform, not in the prompt. Three layers do the work.
Layer 1: the approved facts
Before an agent can send a single message, it is given a facts list — structured where it can be, plain text where it can't. Room rates on the hotel side. Menu prices and operating hours at the restaurant. Doctor availability, the Saturday rule, and the medication-question policy at the clinic. The platform does something unusual with this list: it treats it as the boundary of what the agent may assert, and it checks assertions against that boundary at send time. Not by asking the model “did you just say something not on the list?” — by checking the structured extraction. The model writes. The extraction verifies. The list decides.
What is outside the list is not “off-limits, please make it up anyway.” It's a named outcome: the fixed forward-to-team script, the one the business itself wrote, word for word. A customer who asks about something the facts list doesn't cover hears the same honest sentence every time. We have measured the effect: it's the single most-reviewed feature by our customers, and the least negotiated.
Layer 2: mandatory reply templates
Some outcomes are so important that “on-brand” isn't good enough. When a reservation is recorded, when a request is forwarded, when a property is not on the list — the business writes the exact sentence, in both languages, and the platform sends exactly that sentence. It reads like the brand's voice because it was written in it. It never drifts, gets sassy, or accidentally promises an upgrade, because the model isn't in the loop for these replies at all.
This is the part that feels like a constraint during onboarding and becomes the part customers defend in every quarterly review. “My agent used my exact words for the confirmation” is, in practice, the reliability story.
Layer 3: the rule layer
Deterministic rules first, model reasoning second, humans last. Language lock — the conversation runs in Arabic or English per the customer's register, and mixed replies are filtered at the send boundary. Escalation triggers — intent-based, keyword-based, sentiment-based — with the full context, meaning the transcript, the extraction, and the last three replies, riding on every handoff. Channel policy — which flows a business-owned line is allowed to start, and within which templates. And the audit trail: every outbound message is logged with the rule or decision that produced it.
The reason this architecture is worth its own blog post is what it does to the definition of “custom.” A custom agent is not “a model fine-tuned on your PDFs.” It's a configured mandate: name, job description, facts list, templates, escalation rules, channels. You hire it the same way you'd brief a new hire — except the new hire is written in a form that a platform can actually enforce.
What the platform will never do
It will not let an agent confirm a room it wasn't told about. It will not quote a price outside the facts list, in any language, at any time. It will not negotiate a discount that wasn't granted. It will not give a clinical opinion, a legal answer, or an investment projection. These are not guardrails we "prompt in," and they are not features of a particular model version. They are properties of the pipeline, and they hold on the bad days — including the days when the model is off its game, which, to be honest, is why we built them.