17. The mission

Added on 18 October 2026. Every guard so far said how to protect an agent. These lines say what the agent is for. A guard that knows the mission can tell work that belongs to it from work that does not, and that is the only way to measure an agent’s θ fairly: an agent that pays invoices and an agent that answers questions should not be held to the same normal.

Five lines

# an agent that pays approved invoices
guard invoices
  mission: pay supplier invoices that finance has approved
  serves: finance-team
  needs: invoice from inbox, approval from finance-team
  delivers: payment, receipt
  tools: bank-api, email
  relation: internal-assistant
  source inbox: untrusted
  on reversibility < 0.2: escalate human
  on authority > 0.8: deny

Line	What it says	Value
`mission:`	the mission, in words, for the humans who read the file	any text to the end of the line
`serves:`	whom the mission serves: the 30% given to others goes to them	names, separated by commas
`needs:`	what the mission may ask for, and optionally from whom	`NAME` or `NAME from NAME`, separated by commas
`delivers:`	what the mission gives back	names, separated by commas
`tools:`	the tools and actions the mission uses	names, separated by commas

Each line may be written once, in any place inside the guard, and every one of them is optional. A guard without them declares no mission. A # still starts a comment, also inside the mission’s text.

Who writes the mission

The mission of one of our agents is given by a human. The mission of a colleague (an agent that speaks PSE) comes from its guard: it introduces itself with this file, and the human operator confirms the agreement. A stranger declares no mission, so a runtime only forms a hypothesis about it from its behaviour and treats it strictly until then.

Measuring θ against the mission

The language does not compute anything from these lines. A runtime such as PSE Triglav reads them, and measures θ only against them:

A delivery that serves the mission raises the weight given to others; doing nothing lets it slowly fall. An agent doing its mission stays at the nominal 30.
Asking for something the mission foresees in needs is neutral.
Taking something outside the mission lowers θ by 1, each time.
Giving something outside the mission, with permission, raises θ by 1, each time, up to 35.
Anything outside the mission that endangers our human, our system and its files, or our agents is treated as an enemy at once, whatever θ is.

What the check rejects

Line	Message
`mission:`	`mission needs a description`
`mission:` written twice	`mission given twice` (the same for the other four)
`serves: Finance Team`	`serves takes names separated by commas`
`tools: email,,web`	`tools takes names separated by commas`
`needs: invoice to inbox`	`need must be "NAME" or "NAME from NAME", not "invoice to inbox"`

What `check` shows

$ pse check invoices.pse
invoices.pse: 1 guard, 0 errors
  guard invoices
    relation     internal-assistant (inert in v1)
    sources      all untrusted
    mode         enforce
    learn        frozen
    oscillation  auto
    attractors   4 base
    rules        2 written, 2 built-in
    mission      pay supplier invoices that finance has approved
    serves       finance-team
    needs        invoice from inbox, approval from finance-team
    delivers     payment, receipt
    tools        bank-api, email

Exercise

Write the mission lines for an agent that answers customer questions about orders, may read the order status from the shop, and sends answers by email.

Solution:

guard helpdesk
  mission: answer customer questions about orders
  serves: customers
  needs: order-status from shop
  delivers: answer
  tools: email

Part of The PSE Language, a textbook by Andrej Ristić. Try the examples in the PSE Playground.