Writing agent policy engineers can enforce

Test every clause against a function signature

Take each clause of your AI policy and ask what a function would need to evaluate it. 'Agents must act responsibly with customer data' has no machine-checkable subject. 'No agent may perform a destructive action on a production system without human approval' has three: action type, resource sensitivity, and an approval state.

The first is culture. The second is a control. Both belong in your programme, but only one survives contact with a scheduler.

Type the action first

Rules need a vocabulary to bind to. A workable minimum is three axes: what kind of action this is, how sensitive the resource is, and what purpose it serves. Once calls carry those types, rules become short and reviewable, and a non-engineer can read them.

This is also where tool profiles earn their keep: for tools you know well, declare the types directly and take the classifier out of the loop for good.

Prefer constraints and review over blanket bans

Blanket prohibitions create workarounds; teams route around the block and you lose visibility. Constrained outcomes keep work flowing while narrowing risk: proceed but with a limited field scope, proceed but below a threshold, hold for approval above it.

A review queue with a named owner and an SLA is far better governance than a rule that silently resolves ambiguity in whichever direction the code happened to be written.

Version it like code, because it is code

Publish policy as a signed revision with an identifier, keep old revisions addressable, and reference the revision in every decision. Then 'we tightened the rules in Q2' becomes a reconstructable timeline instead of a memory, and separation of duties on approval stops one person from being the entire control.