Why Agent Architectures Must Shrink As Models Improve

Engineers are trained to add. A new failure mode appears, so a new validator goes in. A new edge case surfaces, so a new branch handles it. In ordinary software that instinct is correct — the accumulated layers are a moat against regression. In agent systems it inverts: the scaffolding that solved last quarter's model limitation is a candidate for this quarter's binding constraint, and the layer that took the most engineering to get right is the one with the most to lose from a better model.

That is a claim about mechanism, not a mood. Any layer written to compensate for a model's weakness is a bet that the weakness persists, and every model release settles that bet. The bitter lesson on general methods scaling with compute (Sutton, 2019) makes the long-run case: hand-engineered structure loses to methods that ride capability gains. The corollary for a system already in production is uncomfortable — the architecture has to be able to shed the structure it was built with, on a cadence, without a rebuild.

ML LABS runs an agent loop to build its own systems, this site included, and the loop is designed around exactly that split. Its durable parts are structural: a builder and a verifier drawn from different model families, so the model that wrote a change is never the model that approves it; a verifier that reads the spec and the diff cold, without the builder's accumulated justification; and four named stop states, with escalation — the task as written is wrong — as a first-class outcome rather than a failure code. None of those rules depend on which model sits behind them, which is why they survive model upgrades. Everything that exists to compensate for a specific model's weakness is scaffolding, and scaffolding is written on the assumption that it will be deleted.

The Scaffolding Decay Loop

The lifecycle of agent scaffolding follows an arc where each stage looks like progress in isolation. Only the second-derivative view — what the same code does one model generation later — exposes the decay.

1. Build systems around the model so the agent solves specific tasks well.
2. The underlying model improves, rendering parts of those systems redundant or harmful.
3. Remove the prior scaffolding to recover the model's new performance.
4. New capability opens a set of harder problems the agent could not previously touch.
5. Return to step one against the new problem surface.

The trap sits between steps two and three. Steps one and four feel like engineering; step three feels like throwing away work, and nothing in a normal roadmap creates pressure to do it. No user files a ticket against code that still works. No incident review flags a layer that never errors. Step three is the only step in the loop that has to be scheduled deliberately, because it is the only one with no natural sponsor — and where it does not get scheduled, the codebase grows monotonically and the agent ages with it.

graph TD
    A["Ship Agent V1"] --> B["Scaffolding Around Model"]
    B --> C["Model Generation Improves"]
    C --> D{"Audit Against Raw Model"}
    D -->|"Scaffolding Helps"| E["Keep Layer"]
    D -->|"Scaffolding Hurts"| F["Delete Layer"]
    F --> G["New Capability Surface"]
    E --> G
    G --> H["Harder Problems In Reach"]
    H --> A

    style A fill:#1a1a2e,stroke:#16c79a,color:#fff
    style B fill:#1a1a2e,stroke:#0f3460,color:#fff
    style C fill:#1a1a2e,stroke:#ffd700,color:#fff
    style D fill:#1a1a2e,stroke:#ffd700,color:#fff
    style E fill:#1a1a2e,stroke:#0f3460,color:#fff
    style F fill:#1a1a2e,stroke:#e94560,color:#fff
    style G fill:#1a1a2e,stroke:#16c79a,color:#fff
    style H fill:#1a1a2e,stroke:#16c79a,color:#fff

Where Scaffolding Becomes Friction

Chunking strategies are the cleanest example. Early retrieval systems split documents into small windows because the model could not attend to long inputs effectively. As context windows expanded, the same chunking rules began severing semantic units the model would have handled in one pass. Analysis of how models use long contexts (Liu et al., 2023) shows that the failure modes shift rather than disappear, which is the point: a chunking heuristic frozen at one generation is calibrated against a failure surface that no longer has the same shape.

Custom rerankers and hardcoded planners decay the same way. A reranker built when the base model was weak at relevance judgment can later return worse passages than a single retrieval call would have. Nothing throws — the system still produces an answer, so the regression has no error message to attach itself to and no alert to raise. A planner that decomposes tasks into rigid steps protects the agent against a model that cannot plan, then forces a more capable model to execute the agent's stale decomposition instead of its own.

Output validators are the third category and the most treacherous, because they mutate rather than merely misroute. A regex that strips malformed JSON is essential against an unreliable model. Once the model stops producing the broken output, the same regex is a corruption layer: every now-valid output that superficially resembles the old defect gets rewritten or rejected, and the validator becomes a defect generator. The shape is the same in each case — scaffolding encodes assumptions about one model's failure surface, and when that surface shrinks, the assumptions misfire in the direction nobody instrumented.

The architecture that absorbs model upgrades cheaply is the one that keeps the model-dependent parts small and separable. A thin tool layer with stable, model-agnostic interfaces lets capability gains land where they belong: guidance on agent design (Anthropic, 2024) makes the case that simple compositions of well-scoped tools outperform elaborate orchestration in most production settings. The mechanism that makes decay visible is an eval suite that runs against two targets — the current production stack and a stripped-down baseline of the raw model with minimal scaffolding. When the baseline catches up to or beats production on a slice of cases, that slice is now overfit to a model that no longer exists. Research on hidden technical debt in ML systems (NeurIPS, 2015) named the underlying dynamic a decade ago for classical pipelines: glue code and configuration sprawl accumulate faster than anything removes them, and eventually cost more than the model they wrap.

The architecture that survives is the one you can dismantle without rebuilding.

When Scaffolding Is Worth Keeping

The argument has boundaries, and they are sharp. Some scaffolding is not a workaround for a model limitation; it is the product, or a non-negotiable property of the operating environment. Regulated domains require auditable rule paths, deterministic checks, and traceable decision provenance no matter how capable the model becomes — a system that arrives at the right answer through an inscrutable path is inadmissible where the path is the regulated artifact, which is the whole argument behind how AI execution works in regulated systems.

Cost control and rate limiting stay for the same reason: they encode a constraint of the deployment, not a deficiency of the model. So does scaffolding that carries proprietary differentiation — domain-specific tool integrations, customer-specific guardrails, the business logic that is the product. The test is a single question asked of each layer: does this address a transient model defect, or a permanent property of the environment the system runs in? The first should carry an expiry condition. The second should be hardened and documented as deliberate.

First Steps

1. Tag every piece of scaffolding with the model limitation it addresses and the condition under which it expires — a capability threshold, never a calendar date.
2. Run the production eval suite against a stripped-down baseline (raw model, minimal scaffolding) each time the underlying model changes, and record every slice where the baseline now wins.
3. Treat the resulting deletions as a release in their own right, with the same review, staging, and rollback the additions get.

Audit Scaffolding Against Frontier

The practical form of this discipline is a scaffolding audit against the current frontier model, where every layer of the stack is re-justified or removed on eval evidence rather than on the memory of why it was written. The output is two artifacts: a leaner system, and a documented map of which layers exist for compliance or differentiation rather than for model compensation. The distinction between essential and accidental complexity (Computer, 1987) is the frame — accidental complexity has to come out, essential complexity stays and gets named as such. Agent quality across model generations is set by that deletion discipline, not by the cleverness of the original architecture, and the same separation of duties applies here as inside the loop: the engineer who wrote a layer is the worst-placed person to judge whether it still earns its keep, which is the argument for a verifier that never shares the builder's priors.

Where the architecture itself is the open question — which layers still earn their place against the current model, what the system looks like without them, and whether the tool boundary is drawn in a place that can survive the next release — an AI system design engagement answers it concretely: the architecture, a written build plan, a fixed-price quote for the work, and a working spike that runs in your stack against your data, so the answer is demonstrated rather than argued. Teams whose agent stack is already carrying more layers than it can defend should read that alongside what it actually takes to deploy enterprise agents, because the layers below the agent are where the aging happens first.

References

1. Sculley, D., et al. Hidden Technical Debt in Machine Learning Systems. NeurIPS, 2015.
2. Sutton, R. The Bitter Lesson. Incomplete Ideas, 2019.
3. Anthropic. Building Effective Agents. Anthropic Engineering, 2024.
4. Liu, N. F., et al. Lost in the Middle: How Language Models Use Long Contexts. arXiv, 2023.
5. Brooks, F. No Silver Bullet: Essence and Accidents of Software Engineering. Computer, 1987.