Procedural rules

Standing behaviors — ‘always do X before Y’, ‘never do Z without approval’.

Some things you want an Agent to do aren’t facts to recall — they’re rules to follow. Procedural memory captures these as first-class items and injects them at the right moment.

Examples

• “Always verify order status before issuing a refund.”
• “Never share pricing information without checking the customer’s tier.”
• “Before shipping, run the linter and abort on error.”
• “If the user mentions a competitor, hand off to sales.”

Each is a rule with a trigger condition and an expected behavior.

Anatomy of a rule

• Trigger — a condition. Can be:
  • Semantic (“if the user asks about pricing”).
  • Structural (“before calling the refund tool”).
  • Event-based (“when a low-confidence retrieval occurs”).
• Action — what should happen. Usually an instruction the Agent will follow.
• Scope — see Scoping. Global, per-tenant, per-user.
• Priority — higher-priority rules override lower ones on conflict.

Where rules go

Add rules to a Wiki space with type = rule. Or use a dedicated Procedural space.

The Agent reads rules at every turn — they’re not left to retrieval. High-priority rules are always in-context.

Writing rules

Rules are just structured notes. In the Wiki editor, use the Rule template:

Trigger: user mentions "refund"
Action: Always call `lookup_order` first to verify the order is refundable.
Priority: high

Or write freeform and let Nora parse the structure — trigger and action are extracted from the text.

From tools

Agents can write rules the same way they write facts — with a remember_rule tool. Useful when the Agent learns a rule from a correction:

User: You shouldn’t say the price is final — always mention it’s before tax. Agent: [writes rule: “when answering price questions, mention ‘before tax’“]

From reviewers

The Approvals queue lets reviewers turn a correction into a rule:

• Reject an Agent action with a reason.
• Click Save as rule on the correction.
• Rule is added to the relevant memory space, applied on all future runs.

Rule conflicts

If two rules fire on the same turn with different actions, priority breaks the tie. If priorities are equal, both actions are surfaced to the Agent and it composes a response addressing both.

Retiring a rule

Rules can be marked inactive (kept for reference, no longer applied) or superseded (like notes and documents). Superseded rules are excluded from retrieval; inactive rules are queryable but don’t fire.

Watching rules in Traces

Every rule that fired on a turn is shown in the Trace, above the model call:

• Trigger that matched.
• Action injected into the prompt.
• Whether the Agent’s behavior aligned with the rule.

If a rule keeps firing but the Agent ignores it, that’s a Signal — the rule is wrong, unclear, or in conflict with the prompt.