> 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 6.1.1**. 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:<id>` or `policy:<id>`.                                                                                                 |
| `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.
* `over_all_routines: true` is the standard pattern for safety policies: whatever flow is mid-flight, the safety action takes precedence this turn. The routine is not cancelled — it resumes when the safety condition no longer matches.
* Priorities shape **which instruction wins when they conflict**; they do not deactivate the loser. A lower-priority policy that doesn't conflict with the winner still applies.

## 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:<id>`)      | Source policy whose match pulls in the targets. |
| `also_apply` | list of `policy:<id>` (≥ 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. All referenced ids must be top-level manifest policies — routine-scoped policies can't participate.

## 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:

```
GET https://docs.interactive.ai/agents/concepts/priorities.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.