Three places a rule can live
Writing the policy down is not one decision. It is a choice about when the rule gets applied. There are only three answers.
Writing the policy down is not one decision. It is a choice about when the rule gets applied. There are only three answers.
In the form. Where it always was. The rule is the shape of the screen. Pressing submit is where it gets checked. It is the least flexible of the three. You only get what a screen allows, so a new case means a new form. It takes real work to set up, because every rule needs a screen built and then kept, though it is work everybody already knows how to do. It costs nothing at all to run, because nothing is being decided while somebody waits. And when it is wrong you edit the form.
Once, when the thing is set up. The rule becomes data before anybody asks: a declared list of what there is to decide and what each one is allowed to be. Nothing is judged at the moment of the request. It is looked up. That covers anything inside the universe you declared, including combinations nobody ever drew a screen for, though a genuinely new one still means a rebuild. Setting it up is the most work of the three: declare it, generate the options, prune them, tag them, cross-check, review. More than the form takes, because almost none of it is work you have done a hundred times before. Running it costs almost nothing and it gives the same answer every time. When it is wrong it is one line to change. It stays changed.
At the moment of the call. The rule is a judgement made on the request in front of it, usually by a model. It is the most flexible by a distance, the only one of the three that can weigh a sequence or a context. It is also the cheapest to set up: write the rule and go. What it costs you lands on every single request, in money and in the wait. The same question can come back with a different answer. And when it is wrong you cannot fix it, only reword it and hope.
Each is better at something and worse at something else.
Setting it up once is the one that gets skipped, for the wrong reason. It is the most work of the three to build, so it loses every argument that only counts the build. It is also the cheapest of the three to live with, which is the half nobody is holding in their head in week one.
So there is no free option. The form is familiar work and it stays rigid. Setting it up once is the most work up front and the least afterwards. Deciding at the call is barely any work up front and then charges you on every request, forever.
Latency is the one that scales badly
Latency here means the wait. Not how long the whole job takes, but how long a request sits there while the rule is being decided.
A model call is somewhere between a moment and a few seconds. Often that is fine. It disappears against everything else that had to happen anyway.
There are two places it stops being fine.
The first is anywhere a reply has to feel live. A conversation, a lookup filling in while somebody types, anything answering a person who is sitting there waiting. That has a budget of a few hundred milliseconds before it stops feeling immediate. A single policy judgement can spend the lot. The decision comes back correct and the thing feels broken.
The second is anywhere there is more than one decision. An agent working through a task makes call after call. If a rule is judged at every one of them the waits do not average out. They add up. Twenty steps at a second each is a task that takes twenty seconds longer than it needed to, with nobody watching able to say why.
An automation is the same problem with nobody watching. Run the same rule across thousands of records and a decision that felt instant turns into hours of wall clock, quietly, on a schedule.
That is what makes the wait different from the money. A cost per decision is a number you can look at and decide whether you can afford. A wait per decision either has to fit inside somebody’s patience or gets multiplied by how many decisions the thing makes. An agent is a machine for making a great many of them.
There is a fourth thing that is not on the chart at all. It is the easiest of the lot to miss. A wrong lookup is a bug: you change it and it stays changed. A wrong judgement from a model is a behaviour. You can reword the prompt, run it again and hope. You will not know whether you fixed it, because it never broke in a way that fails.
That is the real argument for paying the setup cost. Not that it is cheaper to run, although it is. That when it is wrong you can actually fix it.
None of which means deciding at the call goes away. Some questions can only be answered there, which is what permissions were never built for.