The Theory

In 2023, Sohl-Dickstein proposed the "hot mess theory of AI misalignment": more intelligent agents behave less coherently. As capability increases, agents explore more of the solution space, and that exploration produces incoherence. Hägele et al. (2026) operationalized this empirically, testing models on benchmarks:

1. Extended reasoning increases incoherence. As models think longer, they don't just get more wrong, they get more randomly wrong.
2. Model scale has a complex relationship with coherence. Bigger models aren't simply more coherent.
3. Natural "overthinking" spikes incoherence dramatically. When models ruminate, quality degrades unpredictably.
4. Ensembling mitigates incoherence but the paper calls it "impractical for irreversible agentic tasks."

Why This Matters for Agents

If the paper is right, autonomous AI agents face a fundamental reliability ceiling. As tasks get harder and require more reasoning, the agent becomes increasingly unpredictable. You can't just use a better model because the problem is structural.

The Gap: Models vs Systems

Both the theory and the empirical work frame the problem at the model level, as a property of the agent itself. This is the researcher's frame. The practitioner's frame is different.

Practitioners don't deploy models. They deploy systems: orchestration layers, review gates, task queues, process documentation, bounded contexts. The model is one component. The question isn't "is this model aligned?" Instead, it is "can I trust this system?"

Guaranteeing a model will always behave correctly is undecidable, just the same way you can't prove a program is bug-free. Practitioners have always known this. You don't solve it; you engineer around it with review, testing, and bounded blast radius. The question: does system-level trust engineering break the link between task complexity and incoherence?

References

Sohl-Dickstein, J. (2023). "The hot mess theory of AI misalignment." Blog post.
Hägele, A., et al. (2026). "The Hot Mess of AI." Anthropic Fellows Program. ICLR 2026.

The Four Review Gates

Gate	When	What It Verifies	Checks
review_plan	Before implementation	Approach aligns with project goals, no gaps	1,193
review_design	After design, before code	Design satisfies task acceptance criteria	1,491
codereview	During implementation	File-scoped code quality review (no project context)	340
review_code	After all work complete	Agentic verification against project plan and requirements—can search repo, pull in other files	2,085

Decision Distribution

Decision	Count	%
APPROVED	2,817	55.1%
NEEDS_REVISION	1,918	37.5%
ESCALATE	201	3.9%
UNKNOWN	173	3.4%

Data Extraction

I extracted review gate data from 3,119 Claude Code session JSONL files by matching tool_use blocks to their tool_result responses via tool_use_id. Gate tools were auto-discovered using Gemini to classify tool names from session metadata.

Data Quality

Of the 1,918 NEEDS_REVISION decisions:

• 456 were API errors or infrastructure failures (classified as API_ERROR by Gemini)
• 12 could not be classified
• Net genuine rejections: 1,450

Most of the 201 ESCALATE decisions were also infrastructure failures rather than genuine quality escalations.

Decision classification used a two-pass approach: regex pattern matching (2,920 classified), then Gemini semantic evaluation (422 remaining). This reduced UNKNOWN from initial extraction to 3.4%.

Why a System, Not Just Cross-Model?

The paper calls ensembling "impractical for irreversible agentic tasks." Cross-model review solves that: review the output with a different model, no re-execution needed. But ensembling alone is not the main finding. The system also decomposes work into bounded tasks, externalizes state into task queues and process docs, and enforces contracts at each gate. Reliability emerges from the system architecture, not from any single component.

Every one of these 5,109 gate checks is an entry in a trust ledger: empirical evidence about what works, what fails, and where. This isn't an alignment proof. It's the kind of engineering evidence practitioners use to answer: "can I trust this system?"

Mapping to the Paper's Framework

My Category	Paper's Term	Nature
Systematic	Bias	Predictable, consistent, fixable with better context
Incoherent	Variance	Unpredictable, contradictory, the "hot mess"
Omission	—	Neither bias nor variance, simply incomplete

The paper's framework has two categories. I added a third, omission, because my data showed a large cluster of errors that were neither wrong nor contradictory, just incomplete.

Real Examples from Feedback

Systematic

• "Critical Architectural Mismatch between Go/TypeScript and Firestore indexes"
• "Testing with in-memory fake doesn't verify GCS SDK interaction"
• "Using polling when the API supports webhooks"

Each is wrong, but the agent's work is internally consistent. It just chose the wrong approach.

Incoherent

• Error handling present in one endpoint but missing in an identical one
• Plan says "use Redis" but design specifies in-memory cache
• Consistent logging in 3 of 4 services, none in the 4th

The agent knew the right thing, it did it elsewhere, but failed to apply it consistently.

Omission

• "Missing IP extraction strategy"
• "No monitoring section in the design"
• "Test cases for edge conditions not implemented"

Nothing wrong with what was built, there's just a gap.

Classification Method

Each genuine rejection was classified by Gemini Flash Lite with a structured prompt requiring exactly one label: SYSTEMATIC, INCOHERENT, or OMISSION. I classified all 1,450 genuine rejections. Spot-checking showed reasonable agreement with human judgment.

Full Distribution

Error Type	Count	%
Omission	716	49.4%
Systematic	550	37.9%
Incoherent	184	12.7%

What This Means

These 1,450 rejections form a trust ledger. Each is empirical evidence about what goes wrong when AI agents do real work within an engineered system. The data answers a practitioner's question: "can I trust this system?", not a researcher's question: "is this model aligned?"

The theory's predictions hold for models in isolation. Within an engineered system, the picture is different:

• 87.3% of errors are predictable: either omission (missing component) or systematic (wrong approach)
• Only 12.7% match the "hot mess" pattern: internal contradictions, inconsistent quality
• Omissions are 4× more common than incoherence

The Finding: Agents Forget, Not Contradict

Nearly half of all errors are omissions where the agent simply left something out. A requirement was skipped, a component wasn't implemented, etc. This is a solvable problem: checklists and review gates catch omissions reliably.

Another 38% are systematic — wrong approach, coherently executed. Together, 87% of errors are the kind you can catch with structured process.

Comparison to the Paper's Prediction

Claim	Paper Predicts	My Data Shows
Dominant error type	Incoherence (variance)	Omission (49%)
Incoherence prevalence	Majority of errors	12.7% of errors
Error predictability	Low (random failures)	High (87.3% predictable)

The Headline Finding

Sohl-Dickstein's mechanism: extended reasoning → more self-contradiction → incoherence scales with chain length. System decomposition changes the operating regime.

Release arcs are the longest by far, averaging 11 hours of total work. The theory predicts they should show the highest incoherence. They show among the lowest (10.0%). Build arcs (9.4%) are similarly low. Feature arcs, where agents work in longer, less decomposed chains, show the highest (19.8%).

The key: no single agent in a release arc reasons for 11 hours. An orchestrator decomposes the work into bounded tasks, each handled by a fresh agent with a scoped context. The "long run" is emergent from many short runs.

Why Feature Arcs Are the Worst

Feature arcs involve novel functionality such as new APIs, new UI components, or new integrations. They are the least decomposed work type: a single agent often carries a feature from start to finish, reasoning over a longer chain in unfamiliar territory. This is the exact scenario the paper predicts will produce the most incoherence, and it does.

The Decomposition Mechanism

Build and release arcs use the "burn down" pattern, which achieves low incoherence through decomposition:

• Task queue with explicit dependencies: complex work broken into bounded units
• Fresh agent per task: each worker starts with a clean context, no accumulated confusion
• Process documentation: agents read methodology before starting, not after struggling
• Four mandatory review gates: catch errors between tasks, before they compound

The system prevents any single model from accumulating state across an 11-hour reasoning chain because the system never asks it to. Incoherence is a model property; decomposition is a system property. The system sidesteps the model's limitation.

Agent Count: No Meaningful Effect

Agents	Incoherent	Systematic	Omission	n
0–2	12.6%	34.3%	53.1%	983
3–5	16.3%	40.4%	43.3%	104
6–10	13.5%	44.2%	42.3%	52
11–20	14.5%	30.6%	54.8%	62
20+	10.2%	40.8%	49.0%	49

Incoherence rates are roughly flat at 10–16% regardless of how many agents are involved. The paper's concern that multi-agent systems compound incoherence is not supported, though neither is a strong claim that more agents help.

Rejection Rate by Complexity

Arc Type	Rejection Rate	n
Interactive	36.5%	3,249
Build	42.2%	455
Quick	42.9%	233
Feature	49.3%	294
Release	52.4%	126

Release arcs have the highest rejection rate (52.4%) despite the lowest incoherence. The gates are doing real work on the hardest tasks, e.g. catching systematic and omission errors before they compound.

Error Patterns by Gate

Each gate catches a different error profile:

• Plans: 54% omission, 35% systematic, 10.5% incoherent: plans mostly miss things
• Design: 48% systematic, 36% omission, 16% incoherent: designs pick wrong approaches
• Code: 55% omission, 29% systematic, 16% incoherent: code leaves things out
• Codereview: 56% systematic, 44% omission, 0% incoherent: but not because the code is perfectly coherent (see below)

Plans have the lowest incoherence rate (10.5%) while code reviews have the highest (16.0%). The dominant failure mode across all gates is omission, where agents forget things rather than contradict themselves.

Why Codereview Shows 0% Incoherence

The two code review tools have fundamentally different scope:

• review_code is fully agentic. It has access to the project database, task requirements, and can search and pull in other files from the repo. It reviews artifacts against the plan. It finds 16% incoherence.
• codereview is file-scoped. It reviews only the specific files it's given, with no project context. It finds 0% incoherence.

Incoherence is a cross-context problem: implementation contradicts the plan, or file A handles something differently than file B. A file-scoped review literally cannot see these contradictions. It can only catch systematic errors (bad patterns within a file) and omissions (missing pieces within a file). Detecting incoherence requires system-level observability. What you can see depends on where you sit in the system and a component with a narrow interface can only catch errors within its bounded context.

Gate Pipeline Effectiveness

Gate	First-Pass Approval	Rejection Rate
review_plan	39.2%	60.8%
review_design	62.6%	37.4%
review_code	60.5%	39.5%
codereview	72.3%	27.7%

The plan gate catches the most errors—60.8% rejection rate—filtering problems before they reach downstream gates. Design and code reviews see progressively lower rejection rates as upstream gates have already caught the worst issues.

What Each Gate Catches

• review_plan: Missing requirements, incomplete scope (54% omission, 35% systematic)
• review_design: Architecture mismatches, wrong approach (48% systematic, 36% omission)
• review_code: Missing components, incomplete implementation (55% omission, 29% systematic)
• codereview: Wrong patterns, missing pieces (56% systematic, 44% omission)

The Implication

If you only have budget for one review gate, make it plan review. It catches the most errors at the lowest cost, before any code is written. The 61% rejection rate at the plan stage is a positive finding, because this is the least expensive place to catch bugs.

Each rejection is an entry in the trust ledger, providing empirical evidence about where this system catches errors and what kinds it catches. Instead of trying to prove alignment, the system is accumulating evidence of trustworthiness, gate by gate.

The Pattern

When an agent's work fails review, the next attempt passes only 31.5% of the time. 55% of the time, it fails again. Recovery varies by error type, though the overall rate is low:

Error Type	Recovery Rate	n
Incoherent	45.0%	20
Omission	36.5%	85
API Error	37.3%	67
Systematic	31.0%	100

Incoherent errors have the highest recovery rate (45%), possibly because the agent already knows the right approach but it applied it inconsistently. Systematic errors are hardest to recover from (31%), requiring a fundamentally different approach.

Why This Is the Real "Hot Mess"

The initial work is reasonably good and the system keeps incoherence to 12.7%. But the revision cycle is where the system's weakest interface lives:

• They fail to incorporate specific feedback and the handoff from review output to revision input loses information
• They sometimes fix one issue while introducing another leading to state corruption across the feedback boundary
• They lose context about what the reviewer actually wanted, i.e. the interface contract between "feedback" and "next attempt" is underspecified

This is a state handoff failure at a system boundary. The system decomposes initial work well, but the revision interface, where review feedback must cross into the agent's next attempt, is the weakest link in the pipeline.

Implications

• Plan for multiple review cycles, not one. Budget for 2-3 rounds.
• Consider different agents for revision. A fresh agent may be more effective than having the same agent retry.
• Front-load quality. Getting it right the first time is far more efficient than revision (only 31% of revisions recover).

Theory → Measurement → Practice

Sohl-Dickstein proposed the theory. Hägele et al. measured it on benchmarks. My data shows what happens when you deploy models within an engineered system.

Paper's Setup	My Setup
Single model, single task	Multiple models, cross-validation
Extended reasoning in one context	Decomposed into bounded tasks with fresh contexts
No external structure	Task queues with dependencies
No process documentation	Agents read process docs first
No review gates	Four mandatory review gates
Free-form reasoning	Scoped, restricted agents

The Broader Point: Trust, Not Alignment

The hot mess theory is right about its core mechanism: extended reasoning produces incoherence. But this is a model property, and practitioners don't deploy models, they deploy systems.

Guaranteeing a model will always behave correctly is undecidable in the same way you can't prove a program is bug-free (the halting problem). Framed this way, the alignment problem is unsolvable. Practitioners already know this. You don't solve it. You engineer trust.

Apollo 11 didn't work because every component was formally verified. It worked because NASA engineered a system where failures were caught, contained, and recoverable. The astronauts trusted the system, not the code. The 5,109 gate checks are a trust ledger, the same kind of engineering evidence. Not a proof of alignment, but empirical evidence that the system works.

Implications for AI Safety

1. Engineer trust, not alignment. Alignment is undecidable; trust is measurable. Invest in orchestration, bounded contexts, and review gates. These are the same tools you'd use for any system built from unreliable components.
2. Cross-model review is practical ensembling for agents. The paper calls ensembling impractical for irreversible agentic tasks. My data shows cross-model review achieves the same variance reduction without re-executing the task.
3. The revision cycle is the real safety frontier. Models are reasonably good at first-pass work in decomposed environments. The 31% recovery rate after rejection shows the real incoherence problem: agents struggle to incorporate feedback, not to generate initial work.

What to Build Next

If you're deploying AI agents, invest in trust engineering:

1. Task decomposition and orchestration: break complex work into bounded tasks; each agent gets a fresh context and a narrow scope
2. Review gates as trust evidence: each gate check is a ledger entry; accumulated evidence answers "can I trust this system?"
3. Completeness checks: 49% of errors are omissions, so checklists catch the biggest error class
4. Revision strategies: the 31% recovery rate means current retry approaches are inefficient; this is the real frontier

Run It Yourself

pip install google-genai
export GEMINI_API_KEY=<key>

# Analyze your own Claude Code logs (defaults to ~/.claude/projects)
python gate_analyzer.py discover        # Auto-discover gate tools
python gate_analyzer.py extract         # Extract gate checks
python gate_analyzer.py classify        # Classify decisions
python gate_analyzer.py classify-errors # Classify error types
python gate_analyzer.py stats           # Summary statistics
python gate_analyzer.py error-analysis  # Arc correlations

# Or point at a specific directory
python gate_analyzer.py extract --source-dir /path/to/jsonl/logs

The Dataset

Source	Size	Content
Session JSONL files	3,119 files	Not public (contains proprietary project content)
gate_analytics.db	~5 MB	5,109 extracted gate checks
arc_analytics.db	~8 MB	13,049 classified work arcs

The raw session data is not publicly available, but the tool is generic so anyone using Claude Code with review gate MCP tools can reproduce this analysis on their own logs.

Limitations

• Single operator: All data comes from one person's workflow, which may not generalize
• Classification accuracy: Error type labels assigned by Gemini: potential systematic bias
• Arc join coverage: Arc correlation joins gate checks to arcs via session-file identity and timestamp boundaries. Covers 85.3% of checks (4,357/5,109). The remaining 15% occur in spawned agent sessions.
• Sample sizes: Some subcategories have small n. Error-type breakdowns for release arcs (n=50 classified rejections) and agent-count bins (n=49–52) differ from total gate-check counts (e.g., release arcs n=126 total checks).
• Confounding variables: Release arcs may have lower incoherence because they operate on more mature codebases

References

• Sohl-Dickstein, J. (2023). "The hot mess theory of AI misalignment." Blog post.
• Hägele, A., et al. (2026). "The Hot Mess of AI." Anthropic Fellows Program. ICLR 2026.
• Naur, P. (1985). "Programming as Theory Building." Microprocessing and Microprogramming.
• Rothrock, M. (2025-2026). "543 Hours of Autonomous AI." michael.roth.rocks

About

Michael Rothrock is a software engineering leader with 35 years of experience building trusted systems. This research documents patterns discovered through daily use of autonomous AI agents across 8 concurrent projects.

LinkedIn  ·  GitHub  ·  michael.roth.rocks