> For the complete documentation index, see [llms.txt](https://docs.interactive.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.interactive.ai/context/policies.md). # Policies A policy is the atomic unit of agent behaviour: a condition paired with the action the agent takes when that condition holds. Policies constrain behaviour across every conversation regardless of which routine is running: what the agent must not disclose, how it handles a request it cannot fulfil, what compliance rules it enforces.

Policies belong to the project, not to an agent. You write one here and attach it to any agent from the Context step of its configuration. A deployed agent evaluates its attached policies as conversations run, in batches sized by Policy batch size on the agent's Advanced step. ### Writing a policy Each context item holds a single policy, defined in YAML. `name` and `condition` are required, along with at least one of `action` or `tools`. The `condition` describes the situation in plain language, and the `action` describes what the agent should do when it holds. A policy condition can reference variables, the persistent contextual attributes defined in the project. This is what turns a static rule into a data-driven one. A condition like 'the customer's account is flagged for review' works because the evaluation engine checks the variable's current value when matching the policy, not because the model infers the answer from conversation history.

Six optional fields give you finer control over how the policy behaves at runtime: * `tools` names the tools the agent should use when carrying out the action, written as `integration:tool_name`. * `reevaluate_after` lists tools whose execution re-triggers matching of this policy within the same turn. On the next engine preparation iteration (not on a later customer turn), the engine re-matches the policy against the updated state so the agent's next action can account for the tool's result. This is structural enforcement: the engine handles the re-evaluation rather than relying on the model to remember to check. * `criticality` records the policy's severity. The engine uses it as a priority weight when matched rules compete. Accepts `HIGH`, `MEDIUM` (default), or `LOW`. * `always_match`, when set to `true`, has the policy evaluated on every turn regardless of whether the context matches its condition. Use it for high-criticality rules, such as compliance constraints or safety guardrails, that must fire reliably no matter what the conversation is about. * `track` controls the engine's guideline tracking. When `true` (default), a policy that has already been applied is re-matched on later turns with a lighter "previously applied" check instead of the full initial matching. Set it to `false` to force full matching on every turn. * `metadata` holds arbitrary key-value pairs attached to the engine guideline. Merged with server-derived keys at apply time. * `id` and `description` are for your own reference. Leaving `id` out makes the policy's storage name its canonical identifier.

**Config** is optional. It holds arbitrary JSON that travels with the version and is available whenever the policy is fetched, which makes it a place for metadata such as parameters your own tooling reads. **Associated Agents** assigns a version to one or more agents while you save it. The agent label is written onto that version and the agent's configuration is updated to reference it, so an agent runs the version you assigned rather than automatically following the newest one. Assignments can be changed later. ### Versions and labels Every save creates a new version instead of overwriting the current one, and the panel on the left lists them all with the author and date. Each card also carries the labels on that version and the agents using it, so you can see which revision is actually in play before you change anything. A policy can be shared by several agents. Versions cannot be edited in place, which is what keeps the history trustworthy. New starts another version from the one you are viewing, and the **commit message** is what makes that history readable months later.

`latest` is applied automatically and always points at the newest version. Every other label is yours to create and move: the label control on a version opens Context version labels, listing the labels already in the project with a field for adding a new one. Labels are how you control which version gets fetched without touching the code that fetches it, and they are also what assigns a version to an agent. ### The detail view Five tabs sit above the content. * **Context** shows the item itself, rendered for its type. * **Config** holds the arbitrary JSON attached to this version. * **Linked Generations** lists the observations that used this version, with the same filters, columns, and export controls as Observability. This is how you tell whether a version is actually being exercised in production, and how it performs when it is. * **Use Context** gives you a ready-made Python snippet for fetching the item, either by label or pinned to a version number. Every context type is fetched with `get_prompt` and its full path, as in `policies/brand-voice`. * **Label History** is an audit log of label movement: which label changed, whether it was added or removed, the version it landed on, who moved it, and when. **Metrics**, in the top right, swaps the versions panel for a table comparing every version side by side: median latency, median input and output tokens, median cost, how many generations used it, and when it was first and last used. It is the fastest way to catch a version that got slower or more expensive before you promote it. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.interactive.ai/context/policies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.