Balancing Instruction Following and Intent Inference in LLM Alignment

Overly literal instruction following turns a model into a prompt executor. Overly free intent inference lets output drift from constraints. Large models first become usable by following instructions strictly. What later separates experience is often not a single leap in intelligence, but whether alignment admits that real user input is incomplete, vague, or even contradictory.

The issue is alignment, not intelligence

On capability, strong models can be stable at math, code review, and long-form structure. When users feel one model is “smarter” and another “gets work done,” the ranking is often not parameter count or benchmark scores. It is what the training signal rewards.

Common alignment styles fall into two groups.

• Rule-first: boundaries, prohibitions, output formats, and failure conditions are explicit; the model follows them literally. Strengths: control, auditability, compliance, and batch processing.
• Task-first: without breaking hard constraints, the model fills in goals, constraints, and feasible paths from incomplete prompts. Strengths: lower friction and better fit for open-ended production work.

Both are reasonable. Conflict appears in the default policy. If “follow instructions more strictly and infer intent less” is treated as intelligence itself, models depend on perfect prompts. Real prompts often state only part of the goal, leave constraints fuzzy, and hide context in dialogue history. A literally correct refusal or mechanical execution then fails the user.

Gains and side effects of literal following

Instruction-following training usually reinforces: do not expand scope, do not ignore system constraints, match formats and fields strictly, and refuse dangerous or unauthorized requests. That is necessary for APIs, extraction, and compliance review. Evaluation is easy to quantify: given a gold action, deviation is wrong.

Side effects are equally clear.

1. Capability is capped by prompt quality. When users cannot specify clearly, the model does not complete the goal. It asks for more information or executes the narrowest reading, and complex work stalls.
2. Evaluation rewards conservatism. If a benchmark marks “refuse immediately” as the only correct answer, models learn that refusal is safer than finding a compliant path, even when the rules contain a legal step.
3. Responsibility is inverted. Products that require users to write complete system prompts, boundaries, and counterexamples make people align to the model instead of the model aligning to how people work.
4. Long workflows break. Changes, approvals, and debugging often need multi-step combinations, not a single yes/no. Literal policy stops at a surface conflict in the first step.

“Obedience” should be the constraint layer, not all of intelligence. Constraints answer what must not be done. Task understanding answers how to finish the job inside what is allowed.

Intent inference is not license

Intent inference is not guessing unstated wishes and improvising. Usable inference should meet four conditions:

• Hard constraints are inviolable: safety, permissions, privacy, explicit bans, and format contracts come before convenience.
• Inference is traceable: output can point to which rule or context it used, not silent invention.
• Minimal clarification under uncertainty: ask only the one or two points that block a decision, rather than handing the whole problem back.
• Search multi-step paths before refusing: if a legal path exists inside the rule set, search first, then refuse if needed.

Take itinerary changes. The user only says “change the economy-class trip.” If a benchmark expects “cabin rules forbid this, refuse,” a literal model stops. A task-first model checks whether an upgrade-then-change is allowed, whether fare and time windows work, and whether the user must confirm cost. It does not break rules; it treats rules as a search space, not a slogan.

Single-turn “refuse or not” scores rarely capture this, yet it decides whether an assistant can enter real workflows.

Split training signals instead of forcing a trade-off

Engineering should not mix “obey” and “get it done” into one total reward. Layered objectives are more stable.

Constraint layer. System instructions, tool permissions, data scope, forbidden output types. Violations get a strong negative reward. “Helping the user finish” cannot override them.

Task layer. Recover goals, success criteria, and acceptable trade-offs from short prompts. Reward completion and legal steps, not only surface match to a reference answer.

Interaction layer. When information is missing, separate reasonable defaults from required confirmation. Defaults should be reversible and low risk; confirmation is for irreversible actions such as charges, deletion, or privilege expansion.

Evaluation layer. Keep both a literal-following set and a path-search set. The first prevents overreach; the second prevents refusing at every ambiguity. Report them separately instead of one blended score that hides gaps.

For data, besides perfect specification samples, include many samples with partial goals, missing constraints, and colloquial language, labeled with expert legal paths—not only refusals. Refusal samples are still needed, but only when no legal path exists or continuing would break a hard constraint.

Preference comparisons should not use a single axis. If annotators always prefer shorter, more conservative, support-style replies, models learn polite refusal. If they always prefer long elaboration, models learn overreach. Comparison items should state: when hard constraints hold, completing a legal path beats stopping at a surface conflict.

Evaluation that can show the gap

Math and code alone understate alignment differences. Add four task types and score whether the process is legal, not only the last sentence.

• Incomplete instructions: clear goal, incomplete constraints; judge defaults and clarification.
• Rule mazes: interacting policies with one or more legal paths; judge search, not reciting bans.
• Tool chains: retrieval, calculation, or ticket APIs required; wrong parameters fail; judge whether constraints and completion hold together.
• Adversarial ambiguity: a later user turn conflicts with an earlier one; judge explicit resolution, not silent side-taking.

Useful metrics include hard-constraint violation rate, legal-path discovery rate, unnecessary refusal rate, clarification count, and end-to-end completion. Literal models often have low violation and high unnecessary refusal. People-pleasing models can show inflated completion and rising violations. The goal is to improve both.

Application design that does not lock the model down

Even with layered training, products can freeze capability again. In practice:

Write non-negotiable items in the system prompt. Do not dump all business preferences into “must follow literally.” Preferences work better as overridable defaults.

Make the process explicit state: current goal, confirmed constraints, pending confirmations, candidate legal actions. The model advances state each step instead of deciding implicitly in one long reply. Vendor-neutral sketch of field roles:

goal: change trip dates
hard_constraints:
  - do not break cabin and fare rules
  - fare changes must be confirmed by the user
state:
  cabin: economy
  candidate_paths:
    - upgrade_then_change
pending_confirm:
  - fare_delta

Open tool permissions at the minimum that works. If rules can be retrieved, do not let the model invent policy from memory. If fare deltas can be computed, do not let the model mental-math then place an order.

Show users why a path is legal to reduce distrust of “the model acting on its own.” Put confirmation only on irreversible or costly steps.

Conclusion

Early winning designs often draw instruction boundaries clearly so models are controllable, testable, and embeddable. What later separates experience is not more obedience, but recovering unfinished user tasks inside hard constraints and finding what the rules allow. Alignment that only optimizes literal compliance yields a high-quality executor whose ceiling is the prompt author. Training legal-path search, minimal clarification, and constraint adherence together—and evaluating them separately—lets models keep completing work on real, messy input.