The refusal you wrote into your own system prompt

A product engineer at an insurance startup opened a support thread with one sentence: the assistant keeps refusing things it should obviously answer. Customers were asking plain questions about their own policies and getting a polite decline in return.

Her first theory was the one everyone reaches for. The model had gotten more cautious. Some update had tightened the guardrails, and now the base model was refusing things it used to handle. She was ready to file a complaint with the provider and start looking for a different model.

The instinct is to blame the model

That instinct is understandable. Refusals feel like they come from deep inside the model, from the safety training you cannot see or change. When a feature declines a request, it reads like the model made a judgment call you disagree with. So you argue with the model. You try a different one. You add pressure to the prompt to talk it into cooperating.

Before any of that, we read her system prompt. It was long. It had been added to over months, and one of the additions was a safety instruction meant to keep the assistant from giving formal legal or medical advice. Reasonable goal. The wording was the problem. It told the model to decline anything that touched on legal, financial, or health matters and to redirect the user to a human.

For an insurance product, that line covers almost every real question. A customer asking whether a claim is covered is asking a financial question. A customer asking about a health rider is asking a health question. The prompt had drawn a boundary so wide that the legitimate job of the feature fell inside the forbidden zone. The model was not being cautious on its own. It was obeying, precisely, an instruction the team wrote.

Your prompt can manufacture over-caution

This is worth sitting with. A system prompt is not just a set of hints. It is a standing instruction the model follows on every call. A broad “decline anything related to X” line does exactly what it says, including the cases you did not picture when you wrote it. The model has no way to know you meant “decline requests for formal legal advice” when what you typed was “decline anything legal.”

The over-broad line is easy to add and hard to notice later, because it looks responsible. Nobody reviewing the prompt flags a safety instruction. It reads as the careful thing to do. Meanwhile it is quietly rejecting the customers the feature exists to serve.

We narrowed the line. The refusal rate dropped, and it dropped without touching the model at all. Here is the checklist we used, and reuse:

Read the prompt before blaming the model. When a feature refuses too much, your own instructions are the first suspect, not the last.
Look for broad category bans. Any line that says “decline anything related to X” will catch more than you meant. Scope it to the specific thing you want refused.
Test the refusal on real requests. Run the questions your users actually ask through the prompt and see which get declined. The over-broad line shows itself fast.
Separate policy from phrasing. Decide what you truly want refused, then write the narrowest instruction that covers only that.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement that scopes real production work before you build, we treat the system prompt as code, because it behaves like code. It has bugs. A refusal on a valid request is one of the most common, and it almost never comes from the base model. It comes from a well-meant line that drew its boundary too wide. We audit those lines against the requests the feature is meant to handle, and we fix the prompt before anyone goes shopping for a new model.

When your feature says no too often, read what you told it. The refusal may be yours.