Configure a policy

Use a policy to express an authority boundary in terms your team can test. For example: allow low-value refunds, require approval for larger refunds, and block refunds for flagged customers.

Create a draft

1. Open Policies and create a policy, or start from a relevant request in Decisions.
2. Give it a name that describes the control.
3. Set Scope to the conditions a request must meet before this policy evaluates it.
4. Add rules using When, Then, and Reason. Conditions can be grouped. For Require approval, select an approval group.
5. Add Counters if a rule needs a count or sum of earlier actions, such as refunds per customer over 24 hours.
6. Save the draft.

Use facts your integration actually supplies. For money, choose one currency and numeric scale, such as integer minor units, and keep the policy and application consistent.

Reasons are visible in decision evidence and can be returned to the integration. Write them for operators and reviewers; do not include secrets or copy them directly into customer messages.

Test the intended boundaries

In Tests, add requests and their expected results: Allow, Require approval, Block, or No match. Cover values below, at, and above each threshold, as well as requests outside the policy’s scope.

Tests evaluate this policy on its own. No match means none of its rules decided the request; it does not apply an agent’s fallback. Set the counter values each test assumes.

Review and publish

Open Review and publish and select Run checks. Checks save and validate the draft and run its saved tests, comparing against the published version when one exists.

Publish only after the current saved revision passes. Further edits require fresh checks. Review each changed outcome and any warning that a counter will restart.

Assign it to agents

Open Agents, choose the agent, add the published policy, review When no policy matches, and save.

Publishing a later version updates the policy used for new requests by its assigned agents automatically. Existing decisions and retries of resolved requests retain their original result.

Verify the behavior through the integration in its intended mode, then inspect the resulting decision. See Tests and simulations for further checks.