Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Priorities & entailments

Relationship declarations between routines and policies: priorities resolve conflicts, entailments chain policy activations. Without them, everything is equal-priority and independent.

Context — When several policies match and a routine 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.5. Manifest and content shapes are schema-versioned and differ across runtime versions — see Versioning & compatibility.

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:

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.

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

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

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. 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

PreviousAutonomous routinesNextGlossaries & macros

Last updated

Was this helpful?