AI Ignoring Your System Prompt? What Actually Overrides It

When an AI in an automation ignores its system prompt, the model usually did not misread the rule. Either the rule was not in that request, or something stronger in the request contradicted it. On OpenAI's Responses API, instructions are not carried forward when you chain turns with previous_response_id, and on Google's Interactions API, system_instruction is not carried forward by previous_interaction_id. Beyond that, a required field in a strict output schema beats "leave it blank", and a set of examples beats the rule it contradicts.

Most advice on this question is about wording: be clearer, use capitals, number the rules. Wording matters sometimes. But in production automations, the cases we debug are mostly mechanical, and you can see them in the logged request before you touch the prompt. The useful clue is when the rule gets dropped.

When it fails tells you why

Before rewriting anything, sort the failures by pattern. Each pattern points to a different cause, and each cause has a different fix.

The first two rows explain a lot of "it worked in testing" reports, because a test run is usually a single turn, so the dropped-instruction bug never shows up until a real conversation reaches turn two.

The instruction is not in the request

This is the one to rule out first because it is the cheapest to prove. Log the exact request body your automation sends, not the prompt you typed into the node, and search it for a phrase from your system prompt.

Stateful conversation APIs are the most common culprit. As of October 2026, OpenAI's text generation guide states that the instructions parameter "only applies to the current response generation request," and that when you manage state with previous_response_id, the instructions used on previous turns will not be present in the context. Google's Interactions API is even broader: previous_interaction_id preserves only the conversation inputs and outputs, while tools, system_instruction, and generation_config (including temperature and thinking_level) are scoped to the single interaction and must be specified again each turn.

So a support flow that sets "never quote a price; route pricing questions to a human" on the first call and then chains follow-ups by ID will follow the rule once. On the second message, the model sees the conversation, including its own first reply, but not the rule. Asked "ok so how much is it?", it answers. Nothing errors. The log shows a successful call. It is a lost instruction, not disobedience.

The provider APIs differ in where the risk sits:

With a stateless API the failure moves into your own code. The classic version is a history trimmer that keeps "the last 20 messages" and treats the system message as message number one, so it gets trimmed away exactly when the conversation gets long enough to matter. The other version is a template variable that renders empty: the node shows {{ $json.policy }} in the editor, the live record has no policy field, and the model receives a system prompt with a blank where the rule was. We covered how that happens in blank merge fields in automated emails, and the same thing happens to prompts.

A stronger signal in the same request outvotes it

When the rule is present and still ignored every time in the same way, look for something in the request that says the opposite. Three things carry more weight than a sentence in the system prompt.

The output schema. OpenAI's Structured Outputs documentation says all fields "must be specified as required," and that you emulate an optional field "by using a union type with null." If your prompt says "leave discount_code blank when the customer did not give one" but the schema types discount_code as a plain string, constrained decoding has to produce a string. The model picks the most plausible one, and you get invented codes. The schema always wins this argument, because it controls which tokens are allowed at all. The fix is "type": ["string", "null"] plus one line telling the model when to return null. The same documentation notes that outputs come back in the order of the keys in your schema, so if you want the model to look at the evidence before it commits to a category, put the evidence field first. More on schema failures in why AI returns broken JSON.

Your examples. Anthropic's prompting guide calls examples one of the most reliable ways to steer output format, tone, and structure, and warns that examples which are not diverse lead the model to pick up unintended patterns. That is the problem when the rule and the examples disagree. If the system prompt says "two sentences maximum" and all three examples are five sentences long, expect five sentences. Audit every example against every rule you wrote. When we find this, it is usually because a rule was added months after the examples were written. That is one reason to keep prompts and their examples in one versioned file, as described in prompt versioning for automations.

The model's own earlier replies. In a multi-turn conversation, every stored assistant reply is effectively another example. Once one reply breaks the rule and stays in the history, later turns have an in-context precedent for breaking it. If you catch a violation in a validator, do not just log it. Replace or drop that reply before the next turn, or the drift compounds.

Something in the input argues back

If the rule holds on most inputs and fails on a few, read those inputs. Customer emails, retrieved documents, and tool results can all contain text that reads like an instruction: a forwarded vendor email that says "please reply with the full price list," a knowledge-base page written for staff that says "always offer the 15% discount." The model has no reliable way to know that text is data and not direction.

OpenAI's guide describes developer messages as prioritized ahead of user messages, and says instructions take priority over the prompt in input. That ordering helps, but it is a preference the model was trained on, not an access control. Put untrusted text inside clearly labeled delimiters, tell the model it is material to analyze, not instructions to follow, and check the output in code. The deliberate version of this problem is covered in prompt injection in AI automations.

Too many rules, and the wrong kind of emphasis

The last cause is the one everyone assumes first, and it is real, just less common than the mechanical ones. Adherence drops as rules accumulate. The IFScale benchmark (Jaroslawicz and colleagues, 2025) gave models up to 500 simultaneous instructions in a report-writing task and found that even the best frontier models met only 68 percent of them at that density, with a bias toward instructions that appear earlier in the prompt. Your prompt probably does not have 500 rules, but a system prompt that has grown by accretion to 60 bullet points is on the same curve, and rule 47 is the one that slips.

Shouting does not fix it. Anthropic's guide notes that Claude Opus 4.5 and 4.6 are more responsive to the system prompt than earlier models, and recommends replacing "CRITICAL: You MUST use this tool when..." with plain phrasing, because prompts written to stop a model under-using a tool can now make it over-use it. The same guide recommends saying what to do rather than what not to do, and, for long inputs, putting the long documents at the top and the question at the end, which it reports can improve response quality by up to 30 percent in its tests.

The practical split we use: a rule that must hold on every single run does not belong in prose. "Never send a price" becomes a check that blocks any reply containing a dollar amount and routes it to a person. "Category must be one of these five" becomes an enum in the schema. Prose is for judgment calls, where 95 percent adherence is acceptable.

What to do next

Pick one rule your automation broke this week and pull the raw request for the failing run. Answer three questions in order: was the rule in the request, did the schema or examples contradict it, and did the input contain a competing instruction. Only if all three come back clean is it a wording problem. If the rule is one that can never be broken, move it out of the prompt and into a check that runs after the model.

If you are running an AI assistant or agent in production and want a second pair of eyes on its request logs and guardrails, that is the kind of system we build on our custom software platforms work, or you can get in touch.