Procedures

Why they exist#

Some requests are not questions. A refund, a cancellation, a plan downgrade — each has a sequence your business expects: check eligibility, explain the consequence, get agreement, then act. A model given the same facts will sometimes do those in the right order and sometimes skip to the end.

A procedure makes the sequence explicit and retrievable. When the gate stage classifies a message as matching one, the steps are loaded alongside the retrieved documentation, and the model works through them rather than improvising.

Writing one#

A procedure is a name, a description of when it applies, and an ordered list of steps. Write the steps the way you would brief a new support hire on their first day.

name         Refund request
when         The customer asks for a refund, money back, or to reverse a
             charge on an order they have already received.

steps
  1  Confirm which order they mean. Ask if it is ambiguous.
  2  Check the order date. Refunds apply within 30 days of delivery.
  3  If outside 30 days, explain the policy and offer store credit
     instead. Do not proceed to step 4.
  4  Tell them the exact amount and that it takes 5–10 business days.
  5  Ask them to confirm before anything is submitted.
  6  Run "Create refund" only after they have agreed.

Procedures and actions together#

A procedure sequences the conversation; an Action performs the call. The guards on the action still apply in full — a procedure cannot grant permission it does not have.

• A procedure that references a WRITE action still goes through propose → confirm → execute. The procedure’s own “ask them to confirm” step and the code-level confirmation guard are independent, and both must be satisfied.
• A procedure referencing an untested or disabled action simply cannot complete. The trace records the block reason.
• Steps that require customer data need a verified visitor, exactly as the underlying lookup does. See Identity & signing.

What to write procedures for#

• Anything involving money moving in either direction
• Anything with a time limit or eligibility window
• Anything where the wrong order of steps creates a support ticket of its own
• Anything a regulator, an auditor or your finance team would want evidenced

Do not write procedures for ordinary questions. “What are your delivery times” is a documentation problem, and wrapping it in steps makes the agent stilted for no benefit.

Checking they are followed#

Open the conversation in the Inbox. The turn trace shows the retrieved context, so you can see which procedure was loaded and at which step the conversation actually is. When a procedure is regularly abandoned halfway, that is usually a step written as a hint rather than an instruction — compare step 3 above with “consider whether the refund window has passed”.