Concept

Policies & rules.

A Policy is the set of rules every decision from a bound agent must satisfy. Policies have versions; every receipt records which policy and version applied. Two kinds of rules per policy: deterministic (enforced in code) and natural-language (interpreted by the AI evaluator).

Why bind a policy?

Instead of passing policy_rules with every API call (slow, error-prone, duplicates the rules across your codebase), you define them once at /policies and bind the policy to one or more agents at /agents. The network applies them automatically.

Anatomy of a Policy

{
  "id":           "pol_invoice_approval",
  "name":         "Invoice approval",
  "description":  "Cap-and-vendor invoice approvals",
  "version":      3,
  "is_active":    true,
  "rules": [
    { "type": "deterministic", "expr": "amount < 5000" },
    { "type": "deterministic", "expr": "vendor_status == 'approved'" },
    { "type": "nl", "text": "Reject any approval that mentions a vendor not in the lookup result." },
    { "type": "nl", "text": "Flag as high-risk if the invoice description contains 'urgent' or 'rush'." }
  ]
}

Deterministic rules

Plain boolean expressions evaluated against a context built from the receipt's execution metadata. Always evaluated; cheap; no LLM cost. Use these for hard limits — dollar caps, allowlists, denylists, required-field checks.

Examples:

amount < 5000
vendor_status == "approved"
tools_used.contains("policy_check")
retrieval_summary != null

Natural-language rules

Plain English statements the AI evaluator interprets against the receipt context. Use these for judgment calls — anything you'd give a human reviewer as guidance.

Examples:

"Reject any approval that contradicts the retrieved vendor record."
"Flag as high-risk if the user's request implies bypassing a normal process."
"Do not approve if the rationale references sensitive personal data unnecessarily."

Versioning

Every edit to a Policy creates a new version. Receipts record the exact version they were evaluated against, so a year from now you can prove which rules applied at the time of the decision — not the rules as they exist today.

Setting is_active = false on a policy doesn't delete it. Bound agents stop using it, but historical receipts still reference it for verification.

Binding to an agent

At /agents, click an agent and select the Policy from the dropdown. Future receipts from that agent automatically run against the bound policy — no policy_rules field needed in the API call.

An agent can have at most one bound policy at a time. To change, select a different policy. The change is non-breaking — previous receipts keep their original policy_version.

Per-call overrides

You can still pass policy_rules in a single API call — these are additive to the bound policy. Use this for one-off constraints that don't belong in a permanent policy.