Bot Rules
Bot rules are short, always-on instructions baked into the bot's system prompt. Powerful, but scarce by design — this page explains what they're for, why they're limited, and when to reach for a workflow or knowledge base article instead.
A bot rule is a short instruction the bot always keeps in mind. It's written straight into the system prompt and is present on every turn of every conversation — the bot never has to go looking for it.
That "always-on" quality is exactly what makes rules powerful, and exactly what makes them costly. Most of this page is about using that power sparingly. If you take away one thing: a bot rule should be the last tool you reach for, not the first.
This page builds on the Bot Operating Model — it helps to understand that the system prompt is the bot's always-present memory before reading on.
Rules live in the bot's permanent memory
There are three places behavior and knowledge can live, and they differ in when the bot sees them:
- Knowledge base entries are looked up on demand — the bot searches for them only when they're relevant.
- Workflows are loaded when a matching situation arises — their instructions appear only when needed.
- Bot rules are never loaded on demand. They sit in the system prompt for every single message, relevant or not.
So every rule you add is rent the bot pays on every turn, forever. Think of bot rules as the few things you'd pin to a new agent's monitor on their first day — not their entire training manual.
The core question: "does the bot need to always know this?"
Before adding a rule, ask that one question. It's the whole discipline in a sentence:
If the bot doesn't need it always in mind, don't put it in a rule. Context is valuable, finite real estate.
Most things you're tempted to add belong somewhere else. Use this guide:
| If what you're adding is… | Put it in… | Because… |
|---|---|---|
| A fact the bot only needs sometimes (a policy detail, product nuance, edge-case answer) | The knowledge base — add or update an article | The bot searches for it exactly when it's relevant, and not before |
| Behavior tied to a specific scenario ("when a customer wants a refund, do X") | A workflow | The bot loads those instructions only when that situation comes up |
| A genuinely global behavior the bot must obey everywhere (safety, hard prohibitions, brand-critical tone) | A bot rule | This really does need to be always-on |
A few worked examples to make the boundary concrete:
- "Our return window is 30 days." → Knowledge base. It's a fact, looked up when a customer asks.
- "When a customer reports a damaged item, collect photos before offering a refund." → Workflow. It's a scenario-specific procedure.
- "Never promise specific delivery dates." / "Don't reveal you are an AI unless directly asked." → Bot rule. These are always-on guardrails that apply no matter what the conversation is about.
The best test for a candidate rule: would I want the bot thinking about this during a conversation that has nothing to do with it? If the answer is no, it's not a rule.
Why rules are limited
Bot rules have hard limits:
| Limit | Value |
|---|---|
| Max bot rules per business | 30 |
| Max length per rule | 1,200 characters |
| Max length per title | 200 characters |
These limits aren't arbitrary — they exist because of how the bot actually works:
- LLMs follow fewer instructions better. Overload the bot with always-on rules and it follows all of them less precisely. This is a well-understood limitation of large language models. And when every rule is declared important, the bot has no way to tell which one matters most.
- Rules compete with the bot's real work. They share the same context the bot uses to reason, read retrieved knowledge, and run workflows. A wall of rules crowds out the actual job.
There is no priority or ordering among rules — the bot treats them as one flat set, all equally and always in force. That's also why contradictions between rules are so damaging: there's no tie-breaker to fall back on.
The anti-pattern: don't dump everything into rules
The most common mistake is turning every new idea, complaint, or piece of feedback into a fresh bot rule. It feels productive. It quietly degrades the bot.
Here's what goes wrong as rules pile up: they start to contradict each other, and the sheer volume makes the bot follow each one less faithfully. You end up with more rules and worse adherence — the opposite of what you wanted.
Most strong bots run on roughly 15–20 sharp rules, each clearly earning its always-on slot. The 30 cap is a ceiling, not a goal — if you're racing toward it, that's a smell, not an achievement.
And to be clear, this isn't a "you can only build simple bots" constraint. We've set up some of the most complex bots in the world — large enterprise ecommerce and retail brands, insurers, telecoms — and every one of them achieves everything it needs within about 20 rules. The complexity doesn't disappear; it moves to where it belongs. Scenario-specific behavior goes into workflows, which are far more powerful and load on demand, and factual depth goes into the knowledge base. Rules stay reserved for the handful of things that must always hold.
It's the same as it is for people. Hand someone a hundred-page rulebook and they'll follow it poorly; give them a handful of clear, important principles and they'll genuinely live by them. A small, sharp set of rules is easier to follow than a long one — for an LLM exactly as for a person. That's not a limitation of the bot; it's how reliable behavior works.
A bot rule should be your last resort. Before adding one, ask whether a workflow or a knowledge base article does the job better. If it can, prefer that. Reach for a rule only when the behavior is genuinely global and genuinely must always hold.
Common gotchas
Most failed bot rules aren't badly written — they're asking for something a rule fundamentally can't deliver. These are the five we see most often. The first three come straight from how the core LLM loop works.
1. A rule can't give the bot a new capability
People write rules like "call the order-lookup tool when a customer asks about an order" expecting the rule to enable that tool. It won't.
Tool availability is governed only by workflows (see where tools come from). If the workflow that owns a tool isn't in play, no rule can summon it. A rule can shape how the bot uses a capability it already has — never whether it has one.
2. A rule can't make the bot act outside the core loop
A classic: "if you don't have the answer now, follow up in a few hours." Scheduling, waiting, and acting between messages are not governable by a bot rule, because they live outside the per-message loop entirely.
These capabilities exist in Octocom — but through dedicated features, not rules. See the Bot Operating Model for what the loop can and can't do on its own.
3. A rule can't forbid intrinsic LLM behavior
"Never make mistakes," "never hallucinate," "always be 100% accurate" — these don't work. They aren't behaviors the model can switch off; they're properties of how large language models work.
A rule telling the bot not to do something it's intrinsically capable of doing mostly just burns a slot. Accuracy comes from giving the bot better knowledge and workflows (and from the safeguards described in the operating model) — not from forbidding errors in prose.
4. Vague rules get vaguely followed
The bot fills any gap with its own judgment. "If the customer is aggressive, do X" works — but "aggressive" is left for the bot to define, and that's often culturally loaded.
If precision matters, define your terms. Is all-caps aggressive? Are explicit threats? Spell it out. The same goes for fuzzy style instructions: "write shorter" is much weaker than "keep paragraphs under about three sentences." The more measurable the instruction, the more reliably the bot follows it.
5. You can't micro-control phrasing
You can steer the bot away from specific forbidden words, and you can set a general tone. You can't dictate the exact structure of every sentence.
Writing a rule to fix one sentence you didn't like ("don't phrase it like this, phrase it like that") spends a slot on a single example — and usually won't generalize. Give abstract principles about how you want the bot to write, not one-off corrections.
A useful filter: if a rule is trying to grant a capability (1, 2), cancel an LLM trait (3), or pin down something you haven't actually defined (4, 5), it probably won't do what you hope.
Writing good bot rules
Once you're sure something genuinely belongs in a rule, keep it sharp:
- One rule, one purpose. If a rule leans on an "and" to do two jobs, it's probably two rules — or it belongs in a workflow.
- Give it a clear, specific title. It's how both you and the bot tell rules apart.
- Avoid overlap and contradiction — with other rules, and with your workflows.
- Scope by channel instead of writing per-channel prose. A rule with no channels set applies everywhere; otherwise it applies only on the channels you choose (e.g. a "keep replies short" rule scoped to web chat). Don't cram "on email do X, on chat do Y" into one rule.
- Stay well inside the length budget. If a rule is brushing the 1,200-character limit, it's likely knowledge-base material in disguise.
- Be explicit, not impressionistic — see gotchas 4 and 5 above.
Managing bot rules
- In the dashboard: Settings → Knowledge → Bot Rules. Create, edit, scope to channels, and archive rules there.
- Programmatically: via Octocom MCP (
list_bot_rules,create_bot_rule,update_bot_rule,delete_bot_rule) and the REST API. - Rules are versioned — edits and deletions are recoverable, so pruning aggressively is safe. When in doubt, cut the rule and move the behavior to a workflow or article.