Developer
What is a pay policy for an agent that buys?
Three verdicts, not a boolean: allow, deny, and the escalation that a boolean throws away.
The answer
A pay policy is a document and a pure evaluator that answers whether a proposed agent payment may go, must stop, or must wait for a person — over whole minor units, on any rail. It is what turns an agent that can technically pay into one that can pay safely, because a human gate on money is mandatory and a child policy handed to a sub-agent may only ever narrow.
What the evaluator refuses
A float anywhere in a policy, a payment or a ledger state is refused — the checker rejects a value like 2500.0 in the file text before a JSON parser can quietly round it. Any policy whose per-transaction cap is above zero must carry a human-approval threshold strictly below that cap, because a gate no permitted payment can reach is a missing gate wearing a number.
When a policy caps a period but no ledger state is supplied, the answer is deny, not allow — because unknown is not zero, and a cap that silently permits everything when it cannot see the running total is worse than no cap.
Pure, so it is safe to preview
The evaluator reads no clock, opens no connection and mutates nothing; the period’s spending-so-far is injected rather than fetched. That keeps the same grading call safe to run speculatively — to preview a verdict in an interface — with no side effect to undo if the person says no. Reserving spend against the cap happens only after an allow, and is the caller’s job.
The underlying concept is defined canonically at Agent payment policy — FlashyOS. This page answers the build question; that page answers the “what is it” question.
Talk to the practice
Tell us what you are trying to build and what has to be true for it to work.
Contact