Mastering Policies: Steps, Scenarios & Logic

Policies are Engaige's most powerful training tool. Where Documents give your agent general knowledge to draw on, a Policy defines the exact behaviour your agent must follow in a specific situation — step by step, with conditional branching and access to live data through Actions.

This guide covers everything you need to write effective policies: the structure of a policy, how to write good scenarios and instructions, how to build the decision tree, and how to troubleshoot when your agent isn't following the policy as expected.

Documents vs. Policies — what's the difference?

Both Documents and Policies provide the agent with knowledge, but they work differently:

• Documents are a passive knowledge base. The agent searches them freely and constructs a response based on what it finds. They're good for general FAQs, product information, and policies that don't require a structured workflow.

• Policies are active, structured scripts. Once triggered, the agent follows the defined steps in order, calling Actions and branching based on outcomes. They're ideal for complex, multi-step processes like returns, cancellations, or delivery complaints.

Example: A Document might describe your return policy in plain text. A Policy would guide the agent through actually processing a return: ask for the order number → look up the order → check eligibility → initiate the return via your returns portal → confirm with the customer.

When a Policy matches a conversation, it always takes priority over Documents.

Anatomy of a Policy

A policy is a tree of steps. Each step covers one specific situation and tells the agent exactly what to do in that situation. Steps are connected through conditional branches, forming a decision tree the agent walks through.

What's inside a step

Every step has three components:

1. Scenario — Describes the context or situation this step covers. The agent uses this to recognise when the step applies. For the root step, this is also the trigger that activates the entire policy.

2. Instruction — Tells the agent exactly what to do: ask the customer for information, call an Action, send a response, or hand over to a human. Instructions can include conditionals.

3. Actions — Lists which Actions the agent is allowed to call during this step. Actions are locked by default; they must be explicitly unlocked per step.

Creating a Policy

1. Go to Training → Policies.

2. Click + New policy in the top-right corner.

3. Give the policy a Title and Description. These are for your own organisation — the agent doesn't use them.

4. The policy opens in Draft status. You can edit it freely without it affecting any deployed agents.

The Root Step

Every policy starts with a root step. This is the entry point: the agent checks the root step's scenario first to decide whether this policy applies at all. If the scenario doesn't match, the agent ignores the entire policy.

The root step scenario must describe the customer's problem or type of inquiry as clearly and unambiguously as possible. Think of it as your matching rule — the more precise it is, the more reliably the agent will trigger this policy at the right moment.

How to write a good root step scenario

• Frame it around the customer's intent: "The customer is complaining that their order has not been delivered yet", "The customer is asking to cancel their order", "The customer is inquiring about their subscription."

• Be specific enough to distinguish this policy from others. If you have both a "delivery complaint" and an "order status" policy, make sure their scenarios are clearly different.

• Add example customer messages to help the agent in ambiguous cases: "Examples: 'Where is my order?', 'My package hasn't arrived', 'It should have been delivered 3 days ago'."

What to avoid

• Don't reference other policies in the scenario. Each policy should be self-contained.

• Don't include instructions in the scenario — that's what the Instruction field is for.

• Avoid vague scenarios like "The customer needs help." The AI needs clear signal.

Writing Instructions

The Instruction field defines what the agent must do at this step before moving on. Instructions are the core of your policy — write them as clear, ordered directives.

Common instruction patterns:

• Ask for information: "Ask the customer for their order number if they haven't already provided it."

• Call an Action: "Use the get_order_details action with the customer's order number to retrieve the order status."

• Respond based on a condition: "If the order shows as 'Delivered', inform the customer and ask if they checked with neighbours or the front desk. If the order is still in transit, share the tracking status."

• Hand over: "If the customer is not satisfied, hand the conversation over to a human agent."

Instructions can be as long as needed. Use numbered lists for sequential steps. Conditionals are fully supported — the agent is good at following "if X then do Y, otherwise do Z" logic.

Building the Decision Tree

After the root step, you can add following steps that cover what happens next — branching based on different outcomes.

For example, after looking up an order:

• Branch 1: The order is marked as delivered → hand over to human

• Branch 2: The order is still in transit → retrieve tracking details from the carrier

• Branch 3: The order was returned to sender → explain why and offer to reship

Each branch is its own step with its own Scenario, Instruction, and optional Actions. The agent moves through the tree based on what it observes in the conversation and the data it retrieves.

Tips for a well-structured tree

• Give each step a short, descriptive title (e.g. check_order_status, retrieve_tracking).

• Aim for one clear situation per step. If a step is doing too many things, split it.

• Don't nest policies into each other. One complete policy graph is better than chaining policies.

Activating a Policy

A policy has two statuses:

• Draft — The policy is being edited and is not available to any agent, even if assigned.

• Live — The policy is active and can be used by agents it's assigned to.

To make a policy available to an agent:

1. Set the policy status to Live.

2. Go to AI Agents, open the agent, and navigate to the Behavior tab.

3. Assign the policy to the agent and save.

Both conditions must be true — a Live policy that isn't assigned, or an assigned policy that's still in Draft, will not be used.

FAQ

Why is the agent not following the policy?

Run through this checklist:

• Is the policy assigned to the agent? Check in the agent's Behavior tab.

• Is the policy set to Live? Draft policies are never used, even if assigned.

• Is the root scenario specific enough? If it's too vague, the agent may not recognise the match. Try adding example customer messages to the scenario.

• Is another policy triggering first? If two policies have overlapping scenarios, the agent may be following a different one. Consider merging them or making their scenarios more distinct.

• Is a router or topic filter preventing the agent from handling this topic? If a handover rule routes certain topics to a human before the agent responds, the agent will never reach the policy. Check the agent's Triggers and Handover settings.

If the issue persists after checking all of the above, contact Engaige support.

Can I write policies in another language?

Yes. The agent understands and matches scenarios regardless of the language the customer uses. You can write your policy content in any language you prefer.

How many steps should a policy have?

There's no hard limit, but simpler is usually better. Start with the minimum number of steps to cover the key decision points, then add branches as you discover edge cases through testing.