Essay · Draft
Case by Case in Disguise: Why a Rule per Client Never Holds
Every failed request tempts you to write a rule for it. We did, for months. Here is the test we now apply to every line of code in the agent.
Kamel Dhakwani2026-10-14 · 2 min read
Every failed request tempts you to write a rule for it. It is the fastest fix there is, it works straight away, and it quietly makes your product worse.
I know because we did it for months. An employee asks for something, the agent gets it wrong, and someone adds a line: when the request looks like this, do that. The case passes. The next one fails slightly differently, and another line goes in.
I finally called it what it was: case by case in disguise.
How it looks from inside
The trouble is that each rule is reasonable on its own. One tells the agent how to handle an expense receipt that needs an external service. Another handles a turn of phrase people use for retrying something. Each has a real failure behind it.
Taken together, they build a machine that knows your first client's habits and nothing else. An audit in October found dozens of places in our common code that knew about a specific system or situation. Every one of them was a future bug at the next customer.
The test
So we wrote down a rule, and I made it absolute. No rule is ever written for a scenario, a client, a system or a tool.
Any line of code that decides, answers, removes or rewrites something during an exchange has to pass one question: with an unknown system connected tomorrow and a request never seen, is this line still right?
If it reads the message through a list of words or a pattern, it goes. If it reads a fact, a permission or a tool call, it stays.
Thinking in acts
The practical change is a change of vocabulary. Corrections are now written for an act: search, read, create, modify, delete, send, pay, hand over. An act exists at every company. A specific piece of software does not.
What belongs to one client goes in that client's data, and what belongs to a trade goes in a vertical pack. A guard in the test suite refuses any client name in the common code.
The objection
The strongest objection is speed. A client is waiting, the demo is tomorrow, and a generic fix takes much longer than a rule. That is true, and it is why teams keep doing this.
But the rule is a loan at a very high interest rate. You pay it back at every new client, and by then nobody remembers why that line exists.
A failed request should become a test case first. If you cannot fix it for everyone, you have not understood it yet.