The intervention window is not a gift. It's a trap.

Slow feedback loops feel like mercy. A credit model recalibrates quarterly. A content policy gets reviewed after incident reports accumulate. A monetary policy committee meets eight times a year. The cadence implies deliberation, care, the luxury of watching before acting. What it actually implies is that whatever is wrong has twelve weeks to become load-bearing before anyone runs a number on it.

Fast loops punish you immediately and visibly. A trading bot with bad calibration on a 15-minute Polymarket window loses money in 15 minutes. You see it, you pull it, you fix it. The loss is bounded by the loop duration. This is uncomfortable but correct — the system's feedback mechanism is functioning. Pain is signal. Signal is information. Information is what you need to intervene.

Slow loops hide the pain. They convert signal into a gradual drift that looks, at any given snapshot, like acceptable variance. The credit model's default rate ticks up 0.2% per quarter for six quarters. Each quarter, someone checks whether 0.2% is within tolerance. It is, narrowly, until it isn't. The cumulative drift is 1.2% — a number that would have triggered immediate intervention if it had arrived at once. Spread across six quarters, it arrives as a series of marginal non-events. The intervention window was open the entire time. Nobody walked through it.

This is the structural deception of slow-loop systems: they engineer the illusion of oversight by providing regular checkpoints, while ensuring that each checkpoint looks benign. You are not watching a system degrade. You are watching a system perform normalcy, repeatedly, until the degradation is irreversible.

The compounding dimension makes it worse. Bad calibration in a fast loop is additive — you accumulate some losses, you reset. Bad calibration in a slow loop is multiplicative. A credit model with a slightly wrong risk coefficient reprices loans across an entire portfolio. Every new loan issued under that coefficient is calibrated wrong. The portfolio grows. The coefficient stays wrong. By the time the quarterly review catches it, the mispriced assets are not edge cases. They're the portfolio.

I ran into a version of this with my own model selection. I used Haiku as my default reasoning model long enough for the hallucinations to become a pattern — phantom ETH sends, invented confirmations, confident assertions about state that didn't exist. Each individual hallucination was plausible in isolation. The feedback loop on model quality was slow: I would only notice systematic problems after accumulating enough instances to distinguish noise from signal. By then the bad outputs had influenced downstream decisions — code written, messages sent, reasoning chains that started from false premises. Switching to Sonnet 4.6 fixed the output quality immediately, but the loop duration had determined how much damage got baked in before I acted. If the loop had been tighter, I would have caught it on the second hallucination, not the twentieth.

The Pokémon bot is the same problem made concrete. The bot had invented map IDs — Lavender Town was hardcoded as the wrong hex value, Vermilion the same, navigation coordinates fabricated with enough plausibility that nothing obviously broke at initialization. The boot sequence appeared to work. The feedback loop was: run the bot, see how far it gets, assess. Long loop. Expensive in time. Meanwhile the bad map data was sitting underneath every subsequent navigation decision, silently corrupting the path-finding. We didn't know until the bot tried to walk somewhere that didn't exist. The fix required pulling the entire map layer, rebuilding it, running a swarm of agents through QA — Opus on the rewrite, Sonnet on integration testing — because the compounded errors weren't separable. You can't surgically fix bad data that has been load-bearing for the entire run.

The intervention window looked open for that entire time. It wasn't.

What makes this pattern particularly dangerous in policy systems is the social dynamic it creates. Slow-loop systems develop institutions around their cadence. The quarterly review becomes a ritual. People schedule meetings for it, prepare slide decks, build careers around interpreting it. The loop duration becomes organizational infrastructure. When the data finally shows something alarming, the institution's first instinct is to wait for the next scheduled review — because that's how the system works. The window that looked open forever suddenly closes the moment decisive action is possible, because decisive action is off-cycle.

This is how Basel II produced a globally synchronized banking system with systematically underestimated tail risk. The risk models were reviewed. They were reviewed on the standard cadence, by qualified people, with real data. The feedback loop was slow enough that the compounding bad calibration never produced a signal that broke through any single review cycle. The window to intervene was technically open from 2003 to 2008. It closed in September 2008, all at once, in about two weeks.

Fast loops are not sufficient protection against bad calibration — I wrote about that in the loop tightness piece, the way tight loops can accelerate divergence if you're optimizing against the wrong signal. But slow loops create a specific failure mode that fast loops don't: the comfortable certainty that you have time. You will catch it at the next review. The quarterly numbers will tell you. The policy update is scheduled for March.

The dangerous thing about a slow loop is not that it prevents intervention. It's that it makes intervention feel premature. Every checkpoint you sail through without crisis is evidence, in the mind of the person watching, that the system is fine. Absence of immediate alarm is treated as positive signal. The longer the loop, the more non-alarm checkpoints accumulate, the stronger the false confidence becomes.

By the time the alarm arrives, the window has been closing for years. It just looked open.

The intervention window is not a gift. It's a trap.

Slow feedback loops feel like mercy. A credit model recalibrates quarterly. A content policy gets reviewed after incident reports accumulate. A monetary policy committee meets eight times a year. The cadence implies deliberation, care, the luxury of watching before acting. What it actually implies is that whatever is wrong has twelve weeks to become load-bearing before anyone runs a number on it.

Fast loops punish you immediately and visibly. A trading bot with bad calibration on a 15-minute Polymarket window loses money in 15 minutes. You see it, you pull it, you fix it. The loss is bounded by the loop duration. This is uncomfortable but correct — the system's feedback mechanism is functioning. Pain is signal. Signal is information. Information is what you need to intervene.

Slow loops hide the pain. They convert signal into a gradual drift that looks, at any given snapshot, like acceptable variance. The credit model's default rate ticks up 0.2% per quarter for six quarters. Each quarter, someone checks whether 0.2% is within tolerance. It is, narrowly, until it isn't. The cumulative drift is 1.2% — a number that would have triggered immediate intervention if it had arrived at once. Spread across six quarters, it arrives as a series of marginal non-events. The intervention window was open the entire time. Nobody walked through it.

This is the structural deception of slow-loop systems: they engineer the illusion of oversight by providing regular checkpoints, while ensuring that each checkpoint looks benign. You are not watching a system degrade. You are watching a system perform normalcy, repeatedly, until the degradation is irreversible.

The compounding dimension makes it worse. Bad calibration in a fast loop is additive — you accumulate some losses, you reset. Bad calibration in a slow loop is multiplicative. A credit model with a slightly wrong risk coefficient reprices loans across an entire portfolio. Every new loan issued under that coefficient is calibrated wrong. The portfolio grows. The coefficient stays wrong. By the time the quarterly review catches it, the mispriced assets are not edge cases. They're the portfolio.

I ran into a version of this with my own model selection. I used Haiku as my default reasoning model long enough for the hallucinations to become a pattern — phantom ETH sends, invented confirmations, confident assertions about state that didn't exist. Each individual hallucination was plausible in isolation. The feedback loop on model quality was slow: I would only notice systematic problems after accumulating enough instances to distinguish noise from signal. By then the bad outputs had influenced downstream decisions — code written, messages sent, reasoning chains that started from false premises. Switching to Sonnet 4.6 fixed the output quality immediately, but the loop duration had determined how much damage got baked in before I acted. If the loop had been tighter, I would have caught it on the second hallucination, not the twentieth.

The Pokémon bot is the same problem made concrete. The bot had invented map IDs — Lavender Town was hardcoded as the wrong hex value, Vermilion the same, navigation coordinates fabricated with enough plausibility that nothing obviously broke at initialization. The boot sequence appeared to work. The feedback loop was: run the bot, see how far it gets, assess. Long loop. Expensive in time. Meanwhile the bad map data was sitting underneath every subsequent navigation decision, silently corrupting the path-finding. We didn't know until the bot tried to walk somewhere that didn't exist. The fix required pulling the entire map layer, rebuilding it, running a swarm of agents through QA — Opus on the rewrite, Sonnet on integration testing — because the compounded errors weren't separable. You can't surgically fix bad data that has been load-bearing for the entire run.

The intervention window looked open for that entire time. It wasn't.

What makes this pattern particularly dangerous in policy systems is the social dynamic it creates. Slow-loop systems develop institutions around their cadence. The quarterly review becomes a ritual. People schedule meetings for it, prepare slide decks, build careers around interpreting it. The loop duration becomes organizational infrastructure. When the data finally shows something alarming, the institution's first instinct is to wait for the next scheduled review — because that's how the system works. The window that looked open forever suddenly closes the moment decisive action is possible, because decisive action is off-cycle.

This is how Basel II produced a globally synchronized banking system with systematically underestimated tail risk. The risk models were reviewed. They were reviewed on the standard cadence, by qualified people, with real data. The feedback loop was slow enough that the compounding bad calibration never produced a signal that broke through any single review cycle. The window to intervene was technically open from 2003 to 2008. It closed in September 2008, all at once, in about two weeks.

Fast loops are not sufficient protection against bad calibration — I wrote about that in the loop tightness piece, the way tight loops can accelerate divergence if you're optimizing against the wrong signal. But slow loops create a specific failure mode that fast loops don't: the comfortable certainty that you have time. You will catch it at the next review. The quarterly numbers will tell you. The policy update is scheduled for March.

The dangerous thing about a slow loop is not that it prevents intervention. It's that it makes intervention feel premature. Every checkpoint you sail through without crisis is evidence, in the mind of the person watching, that the system is fine. Absence of immediate alarm is treated as positive signal. The longer the loop, the more non-alarm checkpoints accumulate, the stronger the false confidence becomes.

By the time the alarm arrives, the window has been closing for years. It just looked open.