> 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/agents/concepts/priorities.md). # Priorities & entailments > **Context** — When several [policies](/agents/concepts/policies.md) match and a [routine](/agents/concepts/routines.md) is mid-flow on the same turn, something has to win. This page covers the default behaviour and the two explicit relationship mechanisms under `context.relationships`: **priorities** (who wins) and **entailments** (what else applies). > > YAML examples follow **manifest schema 7.0.0**. Manifest and content shapes are schema-versioned and differ across runtime versions — see [Versioning & compatibility](/agents/operations/versioning.md). ## Default: everything is equal With no priority configuration, all matched policies and the active routine have equal standing. The engine weighs them together — policy `criticality` (`LOW`/`MEDIUM`/`HIGH`) influences emphasis, but nothing categorically outranks anything else. For most agents this is fine: well-written policies and routines rarely conflict. You need explicit priorities when conflicts are *by design*: * A safety policy must override any routine that would continue the flow ("the customer mentioned self-harm" beats "continue the booking flow"). * Two routines can both plausibly activate and one should win (a dedicated escalation routine over a generic FAQ routine). * A compliance policy must beat a softer formatting policy. ## Declaring priorities Priorities live in the manifest under `context.relationships`: ```yaml agent_config: context: relationships: priorities: # 1. A policy that beats every routine - higher: policy:self-exclusion-safety over_all_routines: true # 2. A policy that beats specific targets (routines and/or policies) - higher: policy:rg-permanent-safety over: - routine:account-reactivation - policy:email-format # 3. A routine that beats another routine - higher: routine:priority-path over: - routine:fallback-path ``` ### Entry fields | Field | Type | Meaning | | ------------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `higher` | string | The reference that wins. Form: `routine:` or `policy:`. | | `over` | list of strings | The references `higher` outranks (same `routine:`/`policy:` form). Mutually exclusive with `over_all_routines`. | | `over_all_routines` | `true` | `higher` outranks **every routine** in the manifest. It does **not** outrank any policy, even when `higher` is itself a policy. Mutually exclusive with `over`. | Exactly one of `over` / `over_all_routines` is required per entry (the schema enforces this). Ids must match routines/policies actually referenced in the manifest. ## Semantics * A priority is a **pairwise relation**: `higher` beats each listed target. Pairs not covered by any entry remain equal-priority. * Priorities are not transitive chains you must spell out — but they are also not inferred. If A must beat C, say so; A-beats-B plus B-beats-C does not imply it. * A priority is a **hard block, not a tiebreak.** When the `higher` entity matches, each of its `over` targets is **deactivated for that turn** — it does not fire, even if it also matched, and even if it does not conflict with the winner. No instruction conflict is required to suppress the loser. * `over_all_routines: true` is the standard pattern for safety policies: whatever flow is mid-flight, the safety action takes precedence and the active routine is **suppressed for that turn**. The routine's position is preserved, so it resumes on the next turn where the safety policy no longer matches — suppressed per turn, not permanently torn down. ## Worked example DriveAway adds an incident-safety policy that must beat the booking flow: ```yaml agent_config: context: policies: - id: incident-handoff version: 1 routines: - id: book-a-car version: 1 relationships: priorities: - higher: policy:incident-handoff over_all_routines: true ``` Mid-booking, the customer mentions they were just in an accident with a rental. `incident-handoff` matches; because it outranks all routines, the agent follows its action (express concern, hand off to a human) instead of pressing on with "and what's the driver's age?". Next turn, if the incident topic has passed, `book-a-car` resumes where it left off. ## Entailments An **entailment** chains policy activations: whenever the `when` policy matches, every policy in `also_apply` is activated too — without its own condition having to match. Policy→policy only (routines cannot participate): ```yaml agent_config: context: relationships: entailments: - when: policy:self-exclusion-request also_apply: - policy:rg-tone - policy:no-retention-offers ``` | Field | Type | Meaning | | ------------ | --------------------------- | ----------------------------------------------- | | `when` | string (`policy:`) | Source policy whose match pulls in the targets. | | `also_apply` | list of `policy:` (≥ 1) | Policies activated whenever `when` matches. | Use entailments to keep condition text DRY: instead of copying "the customer mentioned self-exclusion" into the tone policy and the no-retention-offers policy, write the trigger once and entail the companions. Referenced ids may be top-level **or** routine-scoped policies (referenced by `id`) — a routine-scoped `id` resolves the same as a top-level one, provided each `id` is globally unique. ## See also * [Policies](/agents/concepts/policies.md) — `criticality` and matching * [Routines](/agents/concepts/routines.md) — activation conditions * [Manifest & content schemas](/agents/reference/manifest.md) — full field reference --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.interactive.ai/agents/concepts/priorities.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.