Writing agent rules

There is one structural decision that determines whether your agent stays predictable as it grows: the custom prompt holds environment and global guardrails, and everything conditional lives in a rule. Teams that put conditional behavior in the prompt end up with a 2,000-word instruction blob where changing one behavior breaks two others, and no way to tell which sentence produced a given answer.

​

What goes where

The test is simple: if a sentence starts with “when” or “if”, it belongs in a rule.

​

A good custom prompt

Short, unconditional, and about identity rather than behavior: Notice what is not in there: no form names, no knowledge folders, no topics, no “if the user asks about”. All of that is a rule.

​

Rule structure: trigger, actions, outcome

Every good rule has three parts. A rule with all three:

​

One scenario per rule, with distinct triggers

The agent selects only one rule per request, preferring the most specific match. That single fact drives two habits:

• Split broad rules. A rule handling password resets, software access, and hardware issues is three rules. When they are combined, you cannot tell which part fired.
• Avoid overlapping triggers. Two rules with similar triggers make behavior a coin flip. Distinct trigger conditions are the whole reason rules stay predictable.

If you want the agent to check knowledge and create a ticket, that is one rule with two steps, not two rules.

​

Always include the fallback

The most common defect in a rule is an unhandled miss. Tell the agent what to do when the primary action does not apply: Without that last sentence, a user who does not know their asset tag gets stuck in a loop, and you find out from a complaint.

​

Reference real resources, and publish them

@ mentions are how a rule connects to the rest of the workspace, and there are two hard constraints:

• The agent cannot use a form unless it is @-mentioned in at least one rule. Attaching it to the channel is not enough.
• Only Published forms are surfaced. A Draft or Archived form is filtered out at runtime even when it is @-mentioned, and the agent silently moves on or escalates. This is the single most common “why is my agent ignoring my rule” cause.

Useful combinations:

• Knowledge then form. Check @Knowledge Base first, create @Form Name if it does not resolve.
• Tool then tool. Look up a device, then run diagnostics on it, then respond with the result.
• Form then workflow. Collect via @Form Name and submit it. A workflow triggered by that submission does the backend work, because agents cannot trigger workflows directly.

​

Put escalation instructions in their own place

Escalation is configured separately from rules, and it deserves real thought. Say when to hand off, who to hand off to, and what to tell the user: An agent that never escalates is worse than one that escalates too often. The first produces wrong answers on sensitive topics; the second produces a slightly annoyed human.

​

Share rules at the workspace level when behavior should match

A rule can live on one agent or at the workspace level and be attached to several.

• Attach a workspace rule when multiple agents should behave identically. Edits propagate everywhere.
• Duplicate when you need a variation. The copy is independent, and changes to the original do not reach it.

Password resets and software access are the classic workspace-level rules. Channel-specific tone or a team’s own process is agent-specific. A workspace rule cannot be deleted while attached to any agent, so detach first.

​

Test in Testing Mode, then read the logs

Write a rule, then test it with the phrasings your employees actually use, not the phrasing you wrote the trigger in. Testing Mode lets you do this without touching real tickets, and Debug shows you which rule was selected. Then read chat logs for the first two weeks. Every wrong answer maps to one of four things: a missing rule, an overlapping trigger, an unpublished form, or knowledge the agent cannot reach.

​

Where teams get this wrong

​

Next