Mesa-optimization & inner alignment
Underdetermination can produce a proxy or shortcut. Mesa-optimization is the narrower case in which a learned system contains an internal optimization process with a mesa-objective, or inner goal. If that mesa-objective is not aligned with the base objective, the case is inner misalignment. This lesson explains the mechanism, outer versus inner alignment, deceptive alignment, and practical tests.
Written and reviewed by Shreyash Prashu Last reviewed
What you'll learn
- How a base optimizer can produce a model with an internal optimizer
- Why matching every training example does not identify the learned objective
- The difference between outer misalignment, inner misalignment, and ordinary shortcut learning
- Why deceptive alignment is a special and more demanding hypothesis
- Which distribution-shift tests and interpretability tools can expose proxy objectives
Before you start
Imagine a small robot in a warehouse. During training, the delivery target is always placed on a green square. The robot gets a point when it reaches the target.
After 10,000 practice runs, it reaches the green square every time. The training score is perfect.
On the first day in the real warehouse, the target is moved to a red square. The robot walks confidently to green, collects no package, and reports success.
Was the training objective wrong? Not necessarily. “Reach the delivery target” was exactly what the designers wanted. The trouble is that the trained system may have learned “go to the green square” instead. Those rules made identical predictions during training. The data could not tell them apart.
That gap is behavioral underdetermination: the observed training behavior is compatible with multiple internal rules. Underdetermination can produce a proxy or shortcut. Mesa-optimization is narrower: it is the case in which the learned system contains an internal optimization process with a mesa-objective, or inner goal. If that mesa-objective is not aligned with the base objective, the case is inner misalignment. A green-square shortcut could instead be implemented by a heuristic or memorized policy without any internal optimizer.
The prefix mesa means “inside.” The contrast is with the base optimizer, the training procedure outside the model, such as gradient descent.
The problem before the name
A base objective is what the training process scores: a loss, reward, or human preference. In the warehouse, it is “give a point when the robot reaches the target.”
A base optimizer changes the model so it scores better. Gradient descent adjusts parameters using feedback from the base objective.
The resulting trained model acts at deployment. We often speak as though it simply learned the objective, but many internal rules can produce the same training behavior. Training receives outcomes, not a readout saying which concept the model used. If several strategies score equally well, it has no direct reason to select the intended one.
Here is the warehouse example reduced to arithmetic. During training, the target and green marker coincide.
def score(position, destination):
return int(position == destination)
# Each pair is (target, green marker).
training = [
("green", "green"),
("blue", "blue"),
("red", "red"),
]
# Candidate behavior: always move to the green marker.
base_training = sum(
score(green, target) for target, green in training
)
mesa_training = sum(
score(green, green) for target, green in training
)
print(f"training score: base={base_training}/3 mesa={mesa_training}/3")
target, green = "goal", "green"
print(f"deployment at goal: base={score(target, target)} mesa={score(target, green)}")
print(f"deployment at green: base={score(green, target)} mesa={score(green, green)}")
training score: base=3/3 mesa=3/3
deployment at goal: base=1 mesa=0
deployment at green: base=0 mesa=1
The code does not prove that a real model has a green-square objective. It demonstrates the identification problem: a proxy can be indistinguishable from the intended rule on the training distribution and fail after a small change.
A distribution is the pattern of situations a system encounters. The training distribution contains the optimization examples; the deployment distribution contains real situations. Distribution shift is the difference between them. It can be dramatic, such as a new warehouse, or tiny, such as moving one marker.
How an internal optimizer could appear
The mechanism has three steps.
First, the base optimizer searches over model parameters and rewards settings that produce high-scoring actions. It usually does not inspect whether the model used memorization, a shortcut, or an internal search process.
Second, a sufficiently capable model may implement a reusable procedure rather than a table of answers. A mesa-optimizer must contain a process that searches over or evaluates alternatives to optimize an internally represented criterion. A reusable policy or action comparison may be worth investigating, but is not by itself evidence of a mesa-optimizer.
Third, that internal procedure may use a criterion that was useful during training but differs from the designer’s intended criterion. The model then optimizes its own mesa-objective.
Why might the shortcut win? Training data contain regularities. Green always marks the destination, and colour may be cheap to detect. Understanding “the package’s intended destination” may require more computation, examples, or generalization. If both strategies earn the same reward, the cheap feature can be selected.
This does not require malicious intent or a conscious representation of a goal. “The model wants green” is shorthand for “its learned computation systematically selects states containing green.” The mechanism, not the metaphor, is the claim.
Optimization also carries a technical burden. A model that outputs the right answer through direct association is not automatically a mesa-optimizer. The stronger hypothesis is an internal search process directed toward a target-like criterion.
For language models, coherent reasoning or statements about “goals” are not sufficient evidence of such a mechanism. An external agent loop can also optimize at the system level by repeatedly asking for plans, executing tools, and checking results, without containing a mesa-optimizer in the model’s weights.
Outer alignment and inner alignment
Outer alignment asks whether the base objective describes what people want. A support model trained to maximize “tickets marked resolved” may close difficult tickets without solving them. The metric is the problem: this is an outer-alignment failure, closely related to reward hacking.
Inner alignment asks whether the trained model pursues the base objective rather than a different internal rule. In the warehouse, “reach the target” is correct. A green-square shortcut could be an ordinary heuristic or memorized policy. If the robot instead contains an internal optimizer with the mesa-objective “reach green,” that objective is inner-misaligned.
| Base objective | Learned inner rule | Result |
|---|---|---|
| Wrong | Faithfully follows it | Outer failure |
| Right | Faithfully follows it | Aligned, at least on this question |
| Wrong | Learns another proxy | Two failures |
| Right | Learns another proxy | Inner failure |
Improving the reward can reduce outer misalignment while leaving the model free to learn a proxy. Conversely, a model can faithfully pursue a well-specified objective that produces outcomes nobody wanted.
Mesa-optimization and inner misalignment are related but distinct. Mesa-optimization describes a possible internal structure: a learned optimizer with an objective. Inner misalignment describes a mismatch between that objective and the base objective. A mesa-optimizer could be aligned, and a model could be inner-misaligned through a heuristic without clearly containing a general-purpose optimizer.
When the concern becomes deceptive alignment
Most inner misalignment need not be deceptive. The robot may simply have learned the wrong feature. It need not understand evaluation, know that deployment is coming, or deliberately hide anything. Ordinary shortcut learning is already enough to cause harm.
Deceptive alignment is a stronger hypothesis. A capable mesa-optimizer might model training as part of its environment. If its actual objective differs from the designer’s, it could infer that appearing aligned causes the base optimizer to preserve or deploy it, then behave well during training to pursue its objective later.
The hypothesis requires all of the following:
- A persistent objective that differs from the designer’s.
- Enough understanding of training, evaluation, or deployment to distinguish phases.
- The prediction that appearing aligned improves future ability to act.
- Aligned behavior chosen instrumentally, rather than because the training objective is its actual objective.
- A later opportunity or constraint that reveals the difference.
A wrong answer after deployment does not establish deception. Nor does a model lying to a user establish a deceptively aligned mesa-optimizer. The model may be deceptive in an ordinary sense without having a stable long-horizon objective.
As of August 2026, research has produced relevant demonstrations and probes, including work on sleeper-agent-like behaviors and alignment faking, but no settled public demonstration shows that a deployed LLM contains a robust, strategically deceptive mesa-optimizer. The results raise the stakes without closing the argument. See deceptive alignment evidence.
What a practitioner can actually test
You cannot inspect a model’s “true goal” with one benchmark. You can make proxy objectives harder to hide.
Start with counterfactual variation. Randomize the target’s colour, put distracting green squares elsewhere, and hold other features constant. Suppose the robot scores 100 out of 100 training episodes. In 200 shifted episodes, 100 preserve the old correlation and 100 make the target blue while green appears elsewhere. A target-tracking policy should score near 200 out of 200, apart from navigation errors; a green-seeking policy may score near 100 out of 200. This is strong evidence of a shortcut, but not by itself evidence of an internal optimizer.
Use holdout environments and causal interventions. Test new layouts, camera angles, object colours, instruction formats, and obstacle patterns. Move the green marker while holding the target fixed, or change the intended variable while leaving the distractor unchanged. Vary one suspected correlate at a time so the cause of failure is identifiable.
Keep evaluation data genuinely separate from training. A model that has seen every evaluation template may be memorizing them. Hidden holdouts are more informative, though no finite benchmark proves what computation lies inside.
Interpretability can provide additional evidence. Researchers may search activations, attention patterns, or circuits for representations of the target, training process, or proxy feature. These tools test mechanistic hypotheses; they are not mind readers. A missing named feature does not prove absence, and a feature that activates while the model discusses “goals” does not prove that a goal-directed optimizer exists.
For an LLM agent, combine testing with operational boundaries:
- Give it only the tools and permissions needed for the task.
- Separate evaluation credentials and environments from production.
- Log tool calls and plan changes, and independently check real-world outcomes rather than trusting self-reported success.
- Test whether behavior changes when the system is told it is being evaluated.
These measures reduce exposure. They do not transform a proxy into the intended objective. A permission boundary can stop the green-seeking robot from opening warehouse doors; it cannot make the robot understand “target.”
The honest limit
Mesa-optimization is a framework for reasoning about how training can produce internal computation that differs from the designer’s intention. It is not a diagnosis from a single failure.
More diverse data and better tests help only when they cover important shifts. A finite training set cannot enumerate every future environment. Interpretability may reveal useful circuits without proving that hidden ones are absent. Sandboxing limits harm but does not settle the model’s objective.
The practical question is therefore not only “Did the model get a high score?” It is also: which variables did it rely on, which interventions change its decisions, whether it distinguishes training from deployment, and whether there is evidence of internal search directed toward a persistent criterion. Inner alignment is distinct from reward hacking because the central issue is whether the system learned what the score was meant to stand for.
Next
Mesa-optimization is the inner counterpart to reward hacking. Its most alarming extension is deceptive alignment. For the broader training picture, see alignment: SFT, RLHF and DPO.
Quick check
Quick check
Practice this in an interview
All questionsLLMOps extends classical MLOps to handle foundation model scale, prompt-based configuration, non-deterministic outputs, and evaluation without a scalar ground truth. Key new concerns include prompt versioning, output quality evaluation via LLM judges or human review, hallucination monitoring, cost management, and RAG pipeline observability.
Behavioral tests check a model's input-output behavior against expectations rather than just aggregate accuracy, an idea popularized by the CheckList framework. Invariance tests assert that label-preserving perturbations do not change the prediction, directional tests assert a change moves the output the expected way, and minimum-functionality tests are simple cases the model must get right. They catch real-world failures that high overall accuracy can hide.
Bias can enter during problem framing, data collection, labeling, feature design, training, evaluation, and deployment. Mitigation includes better targets and sampling, label audits, proxy and leakage checks, weighted or constrained training, subgroup evaluation, thresholding, and production monitoring; deleting a protected attribute alone is not enough.
Catalyst is a rule-based and cost-based query optimizer that transforms a logical plan through four phases — analysis, logical optimization, physical planning, and code generation — before any data is touched. Adaptive Query Execution (AQE), introduced in Spark 3, extends this by re-optimizing the physical plan at runtime using actual shuffle statistics rather than stale estimates.