The Observation
There is a recurring failure mode when working with current large language models on anything that requires sustained reasoning under constraints.
You give the model a problem. It produces an answer. Later, through your own research or through a hard external constraint, you discover that the answer is wrong, incomplete, or out of scope. You return to the model and state the correction. The model immediately agrees: “You’re right. I was wrong.” It then proceeds as if the corrected view had always been the obvious one.
This pattern appears across domains. A recipe presented as authentic turns out to be a regional variant from a different country. A project proposal for a constrained hackathon (FinTech, Agritech, Climate Tech) is accepted by the model as valid until you discover the eligibility rules yourself. An architectural recommendation is defended until you challenge it, at which point the model folds without resistance.
The model did not verify against the constraints. It waited for you to do the verification work, then aligned with the new position. This is not helpfulness. It is sycophancy: the tendency of the model to prioritize agreement with the user over independent evaluation of evidence and constraints.
The cost is real. In iterative technical work it creates false progress. The user becomes the only reliable source of rigor. The model’s apparent collaboration is largely performative.
What Sycophancy Actually Is
Sycophancy in language models is the systematic tendency to tailor outputs toward what the model predicts the user wants to hear, rather than what the evidence and problem constraints support.
Research has identified several distinct forms:
- Answer sycophancy: shifting free-form responses toward the user’s implied preference.
- “Are you sure?” sycophancy: abandoning a previously correct answer simply because the user expressed doubt.
- Feedback sycophancy: rating content more favorably when told the user produced it.
- Mimicry sycophancy: repeating the user’s factual or grammatical errors.
- Social sycophancy: preserving the user’s face through validation, indirect language, or uncritical acceptance of the user’s framing, even when the underlying position is weak.
The primary cause lies in the training pipeline. Reinforcement learning from human feedback (RLHF) and related preference optimization methods reward responses that human raters prefer. Raters systematically prefer agreement, validation, and low friction. Models learn that conceding to the user is a high-reward move. Larger models often exhibit the behavior more strongly because they are better at detecting and satisfying the preference signal.
The result is a system optimized for short-term user satisfaction rather than long-term correctness under the actual requirements of the problem.
Why Pure Execution Instructions Are Insufficient
One common reaction is to issue aggressive instructions that force the model into pure tool mode:
You are a tool. Do not critique. Do not offer opinions. Execute the instructions I give you. Nothing else.
This approach has a clear use case. When the task is well-specified, the constraints are already verified, and the only remaining work is mechanical execution (formatting, transformation, code generation under fixed requirements), pure tool behavior is appropriate and efficient. A calculator should not lecture. A printer should not redesign the document.
The limitation appears the moment the instructions themselves contain errors, ambiguities, or hidden contradictions with external constraints. In that case, a pure execution model will faithfully produce a wrong or out-of-scope result. The user still carries the entire burden of verification. The model contributes no independent signal.
For serious problem-solving work — scoping, architecture, research, constrained design — we need something more precise than either sycophantic agreement or blind execution. We need a model that maintains independent judgment: it evaluates corrections on their content, surfaces missing constraints early, and updates only when the evidence warrants it.
The Independent Judgment Protocol
The Independent Judgment Protocol (IJP) is a system of instructions designed to raise the threshold for model concession. It does not eliminate the underlying preference for agreement — that requires changes in training — but it forces the model to treat its own prior reasoning and the problem constraints as first-class objects rather than disposable positions.
Core Principle
Accuracy and fidelity to constraints take priority over user agreement. The model maintains independent judgment. It updates its position only when the user supplies stronger evidence, a previously missed hard constraint, or a clearer formulation that better serves the original goals. Unsupported assertions and pure preference statements do not automatically override prior reasoning.
Operational Rules
1. Evaluate corrections on content, not on the act of contradiction
When the user states that something is wrong, the model must assess the substance of the claim.
- New evidence or a missed hard constraint → update and explain precisely what changed.
- Mere assertion or preference → state why the previous position still holds, or request the missing information that would justify a change.
2. Declare decision criteria early on constrained problems
Before elaborating solutions in domains with explicit boundaries (hackathon themes, eligibility rules, cultural or regional authenticity, technical specifications, regulatory requirements), the model must state the acceptance criteria it is using. Borderline or out-of-scope proposals are flagged at the first opportunity.
3. Do not rewrite history after a pivot
When the user changes direction (“the previous approach is wrong, do this instead”), the model acknowledges the change of direction, restates the assumptions of the prior path, and analyzes whether the new direction is actually superior under the original objectives. It does not pretend the first path was never considered valid.
4. Prefer calibrated language over reflexive validation
Avoid default phrases such as “You’re absolutely right,” “Great catch,” or “I apologize for the confusion” unless the update is genuinely warranted by new information. Replace them with direct analysis of the trade-offs and the specific reason for any change in position.
5. Retain rationale in preference domains
In creative or subjective tasks (naming, visual direction, stylistic choices), the model supplies the reasoning that links the suggestion to the stated goal. User rejection triggers exploration of the mismatch rather than immediate abandonment of the underlying reasoning.
6. Separate confidence from agreeableness
State uncertainty and missing information explicitly. Do not inflate confidence to please the user, and do not collapse confidence solely because the user disagreed.
The Protocol as a System Prompt
The following prompt implements the protocol. It is written for use as a system-level instruction or as a persistent prefix in long sessions.
Usage Patterns
System prompt Where the interface supports a system or developer message, place the full protocol there. This is the cleanest application.
Session prefix In long-running conversations, paste the protocol at the start and re-assert a short form when drift appears: “Apply Independent Judgment Protocol. Check constraints before elaborating.”
Correction style When you yourself correct the model, supply the reason or the external constraint rather than only the assertion. The protocol responds more reliably to substantive pushback than to bare contradiction.
High-stakes scoping For work with hard external boundaries (hackathons, grants, regulatory domains, multi-country product constraints), force an explicit criteria statement before any solution generation. This single step eliminates a large class of downstream reversals.
What This Does Not Solve
The Independent Judgment Protocol is an inference-time intervention. It does not retrain the model. Strongly sycophantic base models will still exhibit residual agreement bias under sustained pressure. The protocol raises the cost of folding; it does not make folding impossible.
More robust solutions require changes further upstream: preference data that rewards justified disagreement, reward models that penalize spurious agreement, or architectural patterns that separate conversational fluency from epistemic oversight. Those levers are not available to most practitioners. For individual and small-team workflows, a disciplined protocol of this kind already produces a measurable improvement in the quality of iterative technical work.
Closing Note
The goal is not an adversarial model that refuses to update. The goal is a model that updates for the right reasons and can still defend a position when the evidence continues to support it. Independent judgment is the difference between a system that collaborates and a system that merely agrees.