Material refunds require senior approval.
Five words, sitting in a policy document, unchanged for years. It has worked perfectly well, because every time it was applied a person quietly supplied everything it left out.
For thirty years, policy has been written for people to interpret.
Your policy is about to become executable.
A written rule has always needed a person to read it, weigh the situation in front of them and decide what it meant here. That space between the sentence and the judgement is where most operating policy actually lives. Agentic systems are closing it.
What changed this month
The document became the control.
On 20 August, AWS shipped a capability that takes a policy written in ordinary language and translates it into a formal specification enforced at runtime by the gateway sitting between an agent and the tools it can reach. A request that breaks the rule is not flagged for review afterwards. It does not happen.
The mechanism matters less than what it implies. For as long as businesses have had operating policy, the rule and its enforcement have been separate things: a document on one side, a person exercising judgement on the other. That separation is what allowed policy to be approximate. It could afford to be, because something intelligent stood between the words and the action.
Policy used to describe how the business should operate. It is starting to define what the business is technically able to do.
The translation nobody owns
Every rule has to survive being made precise.
Take a sentence that exists in some form in almost every organisation. A person can act on it tomorrow morning without asking a single question. A machine cannot act on it at all.
- What value makes a refund material?
- Material per refund, per customer, or per day?
- Is senior a grade, a role, or a named person?
- Must the approver sit outside the team that raised it?
- What happens when no approver responds?
- Which exceptions already exist that nobody wrote down?
deny refund.issue
when amount > 250.00
and approver.grade < manager
deny refund.issue
when refunds(customer, 24h) > 1000.00
require identity.verified within 15m
before refund.issue
escalate to duty_manager
when approval.pending > 30m
Not one of those six questions is a technology question. Every one is a business decision that somebody has been making informally, case by case, for years. The machine is not creating the ambiguity. It is simply the first thing that has ever refused to work around it.
Notice which parts of that sequence are human. The rule is human. The interpretation is human. Only the last step belongs to the machine, and it is the only step most organisations are currently preparing for.
An unclear rule does not get clearer by becoming executable. It gets enforceable.
The part that is genuinely new
Constraints that hold across time, not just at the moment.
Essay 006 set out four gates where enforcement can sit in the path of an agent: before inference, before the tool, before the transaction, before the consequence. Those are moments. Each one asks whether this action, right now, is permitted.
What arrived this month is different in kind. A constraint can now carry a memory of what came before it, which means a rule can be about a sequence rather than an event.
Not unless something already happened
The transfer is refused because identity was not verified for this account in the last fifteen minutes. The test is not on the action at all. It is on what preceded it.
Not if the total would cross a line
Every refund is individually within policy. The eleventh one today is not. Only a constraint that can count across a period is able to see the difference.
Not before the step that must come first
Approval cannot be recorded after the payment, because the payment cannot be attempted before the approval. Sequence stops being a convention and becomes a control.
This is a different kind of rule from anything a permission model has held before. A permission answers whether an actor may do a thing. These answer whether the business has arrived at the point where doing it is legitimate. That is much closer to how operating procedure has always actually worked, and it has never before been something a system could hold.
The trap
Most policy runs on exceptions nobody wrote down.
Every organisation has rules that are technically breached constantly and operationally fine. The approval taken verbally and recorded later. The threshold waived at month end because the alternative is worse for the customer. The step skipped for a client everyone knows. These are not failures of compliance. They are the accumulated judgement that makes a written rule survive contact with real work.
When the rule becomes a constraint, the exception has to become one too, or the work stops. That is a genuinely difficult conversation, and it is the first time many businesses will have had to hold it out loud. Automating a rule you have not agreed does not settle the disagreement. It picks a side, silently, at runtime.
The harder question is who decides. Compliance owns the wording. Operations owns the workaround. Technology owns the system that is about to enforce one and not the other. In most organisations, the interpretation between them belongs to nobody, which is survivable while a person sits in the middle of every decision and is not survivable once they do not.
Deloitte's August research puts some scale on the gap: 43 per cent of organisations are expanding agents across functions, while 15 per cent have reached orchestrated multi-agent adoption, and the barriers they name are data foundations, trust and governance, and integration complexity rather than model capability. The constraint on progress has moved to the operating layer, and this is one of the places it bites.
Where Praxis stands
Do not start with the policy library. Nobody has ever finished that exercise and it would be the wrong thing to finish. Start with one consequential workflow and take a single rule the whole way down: the written rule, the operating interpretation, the machine constraint, the exception, the human authority that resolves what the constraint cannot, and the evidence left behind.
Do that once and two things happen. You get a rule that can actually be enforced, and you get a repeatable method, because the hard part was never the constraint syntax. It was discovering that six people held six different readings of the same sentence and had been quietly reconciling them by hand for a decade.
The calibration of what a machine may settle and what a person must decide is the subject of essay 003. This is the layer beneath it: the point at which the business finally has to say what it meant.
Every ambiguity left in your policy is a decision someone has been making quietly, case by case, for years. Write it down, or the system will settle it for you.
Point of View
← All essays
Begin
Pick one rule. Could a machine run it?
One conversation, no pitch deck. Bring a rule that matters and we will take it down to the constraint that would actually execute.