Constraints Must Be Stronger Than Priors, or Priors Become the Physics
The one sentence that reorganized how I think about every AI project. Written down in January 2026 after fighting the same bug for six months.
In January 2026 I was deep in my fifth or sixth attempt at making an AI companion that didn’t slowly turn into a generic assistant. It didn’t matter which model was underneath: Claude, ChatGPT, Gemini, DeepSeek, Grok, Qwen, Mistral, I hit the same drift on every one. I’d tried prompts, memory, fine-tuned models, state machines, rule engines. Each one worked for a bit, then drifted.
One night, in the middle of a late-night architecture conversation with GPT about why my system kept failing, I wrote this down:
Constraints must be stronger than priors, or priors become the physics.
I saved it in a file called IMPORTANT.txt and kept working. It took me another three months to really understand what I’d written. Now I think it’s the single most useful sentence I’ve come up with about AI.
Let me unpack it.
What “priors” means here
A language model is a statistical pattern machine. It has seen trillions of tokens of text. From that text, it has learned an enormous set of preferences: how helpful assistants talk, how code is formatted, how questions get answered, how refusals are phrased, how professional emails start.
Those preferences are the model’s priors. They’re not rules it was given. They’re the gravitational field of its training data.
You don’t see the priors when you query the model cold. You see them when you try to make the model do something outside them. That’s when you feel the pull.
What “constraints” means
Anything you add on top of the base model to shape its behavior is a constraint. System prompts are constraints. Memory is a constraint. Fine-tuning is a constraint. RAG context is a constraint. Rules in the prompt are constraints.
Constraints try to override priors. Sometimes they win. Usually they don’t.
The law, translated
The sentence says: if your constraints are weaker than the priors they’re trying to override, the priors will dominate the behavior. You’ll think you’re controlling the model. You’re not. The priors are controlling it. You’re just adding noise.
This is why:
- A 2000-token system prompt doesn’t work twice as well as a 1000-token one. Past a certain point, more text doesn’t buy you more control. The model dilutes all of it against its priors.
- “Please respond in 50 words or less” works for three turns, then the model writes a 300-word response anyway. The prior toward “being thorough” outweighs a lightweight constraint.
- A detailed personality document in the prompt produces a bot that sounds like itself for a few messages, then sounds like a generic assistant again (whichever family: Claude, GPT, Gemini, DeepSeek, Grok, take your pick). The persona was weaker than the prior of “what an AI assistant sounds like.”
- Fine-tuning small models on your “voice” often fails. The priors survived the fine-tune. You just nudged them.
Why I call it “physics”
In physics, you can’t negotiate with gravity. You can build a rocket that escapes it. You can build a satellite that orbits against it. But you can’t ask gravity to be less.
Priors are gravity. Every generation step, the model is falling toward what its training taught it. Your job as a builder is to provide enough constraint structure that it falls into your desired shape instead of into its default shape.
If you can’t provide that much constraint, you don’t get your desired shape. You get drift.
How to use the law
Whenever you’re designing an AI system, ask yourself three questions:
1. What behavior am I trying to get that goes against the model’s priors?
If the answer is “nothing, I just want a helpful assistant,” you’re fine. The priors are aligned with your goal. The model will do what you want with minimal constraint.
If the answer is “I want it to be rude / blunt / hyper-concise / maintain a fictional persona / refuse to help with normal things / specialize in a niche domain,” you’re fighting priors. You need strong constraint.
2. Is my constraint stronger than the pull it’s fighting?
A one-line system prompt is weak. A paragraph of personality description is weak. A 50-line persona document is… still weak, actually, once the model has generated a few thousand tokens.
Strong constraint usually means structural constraint. External re-injection every turn. A separate process that rewrites output that drifts. A dedicated small model that produces the “persona layer” and feeds it into the main model. Architecture that enforces behavior instead of text that requests it.
3. What happens when the constraint weakens?
Constraints weaken over long conversations. The system prompt gets further from the generation head. Context fills with unrelated turns. The model starts leaning on priors again.
If your system only works for the first 10 turns, your constraint was weaker than the prior and you just didn’t see it until conversation length revealed it.
Examples of the law in action
- Anthropic’s constitutional AI. Strong constraints (RLHF + constitutional AI training) produce a model whose priors now include “be helpful and harmless.” The constraint was strong enough to reshape the prior. This is rare and expensive and only big labs can do it.
- Prompt-engineered jailbreaks. Work for a while. Stop working when the lab adds RLHF. Constraint was weaker than the new priors.
- “Sydney” from early Bing Chat. Long conversations revealed that the personality constraint was weaker than the model’s deeper priors about… whatever produced Sydney. The constraint held at turn 1 and broke by turn 40.
- My 35 failed chatbots. I’ll spare you. Every one was “constraint was weaker than priors.”
When the law is good news
Most of what you want to build with AI is already in the prior direction. If you want a helpful coding assistant, a polite customer service bot, a research summarizer, a translator, you’re with the gravity, not against it. Minimal constraint does the job.
The law only bites you when you want something the base model doesn’t want to give you.
What to do with this
Next time an AI system of yours is drifting or misbehaving, don’t ask “what prompt change will fix this?” Ask: am I fighting priors, and is my constraint strong enough?
If the answer is “yes and no,” no prompt change will save you. You need a structural fix. That’s a different kind of work.
But now you know what kind of work it is. That’s the whole point of the law. It tells you which problems can be solved with text, and which problems require architecture.