Early versions of Kestrel were configured the way most AI products are: with a long block of instructions that a few people knew how to edit. It worked, and we replaced it anyway.
The problem with one long prompt
A prompt is a single piece of text that does many jobs. It sets the tone, describes the company, lists the policies and handles the exceptions. Change one sentence and you cannot be sure what else moved.
That made support leads nervous, with good reason. The person who knows the refund policy best was not the person who could safely edit the prompt. So changes went through an engineer, took a week, and were tested by hoping.
A rule is one sentence with one number
We split the policies out into rules. A rule says what Kestrel may do, and where the line is:
Refund up to $200 to the original card.
That is the whole rule. The number is the only part most people ever change, so it is the only part that looks editable.
Rules are checked by ordinary code, not by the model. The model decides what the customer is asking for. The rule decides whether Kestrel is allowed to do it. Those are different questions and they should not be answered by the same thing.
What we gave up
Rules are less flexible than prose. You cannot write "use your judgement for loyal customers". You have to say what loyal means and what changes for them. Some teams find that frustrating in the first week.
It tends to stop being frustrating the first time someone asks why a refund went through. With a prompt, the honest answer is that the model thought it should. With a rule, you can point at the sentence.
Who edits them now
In most teams it is the support lead, without asking anyone. That was the goal. The people who own the policy should be the people who can change it.