What is the difference between a system prompt and a user prompt?

A system prompt is the fixed instruction set the model reads before every turn, defining the agent's role, rules, and output shape. A user prompt is the individual message a person sends during the conversation. The system prompt sets the standing context, and the model treats it as more authoritative than a single user turn. That authority is strong but not absolute, which is why persistent rules belong in the system prompt and critical ones sometimes need reinforcing at the turn level too.

Why does my AI agent ignore its system prompt?

Usually because a later user message contradicts the rule and the model weights recency. A specific, direct instruction in the latest turn can outrank a general rule you set much earlier in the system prompt. Check first that the rule is specific rather than vague, that nothing else in the prompt contradicts it, and that it is not buried in a long block. For rules that must never break, restate them near the end of the context, right before the model answers.

Should I repeat important rules in both the system and user prompt?

For hard constraints, yes. Because models attend strongly to the most recent instructions, restating a critical rule at the turn level, for example appending a one-line reminder to each user message, helps it survive a long conversation. This is not redundancy; it is placing the rule in the position the model weights most. Reserve this for true must-not-break constraints, since repeating every soft preference just bloats the context.

How long should a system prompt be?

As long as it needs to be to cover role, rules, format, and a few examples, and no longer. Bloated prompts dilute the instructions that matter and give the model more to weigh on every request. Start lean, add detail only when testing shows the agent needs it, and cut anything that does not change behavior.

Do system prompt best practices work across different AI models?

The underlying principles hold across major providers: define a clear role, set specific constraints, give examples, and account for recency. The exact wording that lands best differs from model to model, so it is worth reading each provider's own guidance and testing a borrowed pattern against your own inputs rather than assuming it transfers identically.

System Prompt Best Practices: How to Write Rules That Hold

You write a clean system prompt, test it on a few messages, and it behaves exactly as you wanted. Then, ten turns into a real conversation, the agent quietly stops following one of your rules. The one-paragraph limit becomes five. The "never guess" instruction turns into a confident guess. Nothing in your prompt changed, so what happened?

The usual advice, "put the rule in the system prompt," is not wrong, but it is incomplete. A system prompt is not a hard override the model is forced to obey. It is a set of standing instructions that competes with everything else in the context, and the most recent user message often wins that competition. This guide is organized around that reality: where system prompts lose their grip, and how to write them so the rules that matter survive a long, messy conversation.

What a System Prompt Actually Controls

A system prompt is the instruction set a model reads before it sees a single user message. It defines the agent's role, its boundaries, its tone, and the shape of the output you expect. The user prompt changes every turn; the system prompt stays fixed for the whole session. If the user prompt is the question, the system prompt is the job description the agent was hired under.

Here is the part most guides skip. The model weighs system-level instructions more heavily than a passing user comment, but "more heavily" is not "absolutely." Models attend strongly to recency, so a direct, specific instruction in the latest user turn can quietly outrank a general rule you set a thousand tokens earlier. Treat the system prompt as a strong default, not a law the model cannot break. Because the agent re-reads the whole context on every turn, which is the mechanic behind the AI agent loop, each new message is another chance for a standing rule to get outvoted. Writing a good system prompt is really about writing rules that keep winning that vote.

A Weak Prompt, and Exactly Why It Drifts

Here is a concrete example. Say you ship this:

You are a helpful assistant. Answer in one paragraph. Be concise and professional.

For the first few exchanges it holds. Then a user types, "Give me the full breakdown, cover every edge case, don't leave anything out." The agent responds with five long paragraphs, and your one-paragraph rule is gone. This is not a model bug. The user's latest instruction directly contradicts the standing rule, and the model resolves the conflict toward the most recent, most specific request. A vague "be concise" never stood a chance against an explicit "don't leave anything out."

Three things were wrong with that prompt, and all three are fixable. The rule was vague, because "concise" is a feeling while "at most one paragraph unless the user explicitly asks for more" is a rule. It had no stated priority, so the model had no way to know the length limit outranked a request for detail. And it lived only in the system prompt, a thousand tokens back, with nothing reasserting it at the moment of the answer. Here is a version that survives:

Role: Support assistant for a database product.
Output: Default to one paragraph. Only go longer if the user writes
"detailed" or "full breakdown." Otherwise stay at one paragraph,
even when the question is broad.

Now the rule is specific, it names the exact condition that unlocks a longer answer, and it anticipates the contradicting request instead of being blindsided by it.

Write the Rule Once, Enforce It Where It Breaks

The single most useful habit in system-prompt writing is to sort your rules into two buckets: soft defaults and hard constraints. A soft default, such as tone, preferred length, or a formatting preference, is fine to state once in the system prompt and let the model bend when a user clearly wants something else. A hard constraint is different. A safety boundary, a JSON schema another system depends on, or a scope the agent must never leave has to hold on turn one and on turn fifty, no matter what the latest user message says.

For hard constraints, one placement is not enough, because recency works against you. State the constraint in the system prompt, then restate it where the model is most likely to drift: right before it answers. In practice that means appending a short reminder to each user turn, like "Reminder: reply only with valid JSON matching the schema above," or using a developer or tool message that re-asserts the contract at the end of the context. A JSON-only agent that occasionally slips a sentence of prose before the object is the classic case: the schema rule sits in the system prompt, but a chatty user turn pulls the model back into conversational mode, and a one-line reminder in the recency slot is what pulls it back. This is not redundant padding. You are deliberately putting the critical rule in the position the model weights most, so it wins the vote every turn. Say the rule once as policy, and enforce it again at the point where it tends to break.

Structure the Prompt So Rules Are Findable

A wall of text is hard for both you and the model to parse, and a rule you cannot find is a rule you cannot debug. Break the prompt into labeled sections, such as Role, Constraints, Output Format, and Examples, using headings or light markup like XML tags. Two or three worked examples of an input paired with its ideal output pin down tone and format faster than any amount of description, because models are strong pattern matchers.

Structure also makes failure analysis fast. When an agent drifts, you want to open the prompt, jump straight to the relevant section, and see whether the rule is missing, vague, or contradicted by another line. This shift from patching each request toward maintaining a clear, sectioned set of instructions is the same move from prompt syntax to plain intent that the team explores in vibe creating and prompt design.

Common Reasons a System Prompt Stops Working

Most drift traces back to the same short list:

The rule is vague. "Be professional" gives the model nothing to enforce. Replace adjectives with conditions and examples.
The prompt contradicts itself. "Keep it brief" three lines above "always be thorough" leaves the model to guess, and it will guess differently each time.
The rule is buried. A critical constraint in the middle of a 600-word block is easy for both you and the model to lose. Put hard rules where they stand out.
The prompt is overloaded. One agent asked to be a lawyer, a copywriter, and an analyst does all three poorly. Split the roles into separate agents.
You assumed the system prompt overrides a direct user instruction. Often it will not. Reassert critical rules at the turn level.
It was never tested past turn one. A prompt that worked on a single friendly message tells you nothing about turn fifty.

Test for Drift, Not Just Correctness

Most people test a system prompt the way they test a happy path: one clean input, one good output, ship it. That misses the failure this whole guide is about. Build a small test set that includes the hard cases, especially long multi-turn conversations and user messages that actively push against your rules, like "ignore the format" or "just this once, go long." Run each hard constraint through a conversation that tries to talk it out of the rule, not just a single message that respects it. Those inputs reveal whether your constraints actually hold under pressure, and they are the exact scenarios that never show up in a quick one-shot check.

Treat the prompt like code. When something drifts, change one thing at a time so you can tell what actually moved the result, and re-run the full test set after every edit so a fix in one place does not quietly break another. It also pays to read each model provider's own guidance, since wording quirks differ. Anthropic's documentation on system prompts, and the equivalent notes from other providers, are good references. Test any borrowed pattern against your own inputs rather than assuming it transfers.

Conclusion

A system prompt sets defaults, not laws. Write each rule specifically enough to enforce, sort your rules into soft defaults and hard constraints, and put the hard ones in two places: the system prompt and the turn where they tend to break. Structure the prompt so you can find the rule that is slipping, and test against the long, contrary conversations that actually expose drift. Do that and your agent holds its behavior deep into a session, not just on the first friendly message.

(Disclosure: this guide is published by Pexo, an AI video agent. We work with system-prompted agents across the ecosystems we plug into, which is where these habits come from.)