How AI Design Patterns Evolve as LLM Capabilities Improve

Many “must-have” agent patterns started as workarounds for weak models: multi-step scaffolding because the model lost the plot, brittle routers because it could not follow a long policy, critic loops because it could not self-check reliably. As base capabilities rise, some of that machinery becomes optional. The durable question is not “what is trendy this quarter?” It is which control shapes still earn their keep when the model gets better — and which ones you should plan to delete.

Patterns are partly capability debt#

Treat a pattern as two layers:

1. Capability patch — structure that compensates for what the model cannot do yet (long-horizon planning, tool discipline, format obedience).
2. System contract — structure you need even with a perfect model (permissions, budgets, audit, human gates, deterministic business stages).

Capability patches should shrink over time. System contracts should not. Teams get hurt when they fuse the two and refuse to retire scaffolding after a model upgrade.

What tends to simplify#

Verbose chain-of-thought scaffolding#

Hand-authored “think step by step across five mandated sections” prompts were a patch for models that skipped constraints. Stronger models follow structured output schemas with less ceremony. You still want schemas and validators. You often need less ritual prose around them.

Deep Planner–Executor for medium jobs#

When models were weak at multi-step tool use, explicit plan nodes helped. As tool-calling and instruction following improve, a bounded ReAct-style loop — or even a short fixed chain — clears the same eval set with fewer moving parts. Keep planners for genuinely open investigations, not for “update three CRM fields.”

Ensemble critics for style nits#

Multiple judge models fighting over tone were a hedge against noisy single judges. Better base models plus a crisp rubric and a golden set often beat a committee. Keep human review or a single critic where risk is high; drop decorative ensembles.

Micro-routers in front of everything#

Fine-grained intent routers proliferated when one model could not hold a large policy. Larger context and better instruction following collapse many micro-routes into one policy-grounded call — still behind a coarse Router when blast radius differs (read-only vs money movement).

What tends to persist#

These are closer to system contracts than capability patches:

• Tool allowlists and argument schemas — capability does not grant permission
• Step / token / time budgets — smarter models can still loop
• Deterministic business stages — compliance and finance do not care that the model “could” improvise
• Human gates on irreversible actions — risk, not IQ
• Evals and traces — you still need proof the upgrade did not regress

A stronger LLM can propose better tool sequences. It should not become the policy engine for who may refund a customer.

What is likely to disappear (or become rare)#

Disappear does not mean “never.” It means default off unless risk or complexity scores demand it.

A migration playbook when models improve#

Do not rewrite the product on every model launch. Run a controlled peel:

from dataclasses import dataclass

@dataclass
class PatternStage:
    name: str
    kind: str  # "capability_patch" | "system_contract"
    kill_candidate: bool

def peel_order(stages: list[PatternStage]) -> list[str]:
    """Remove capability patches first; never delete contracts in the same change."""
    patches = [s.name for s in stages if s.kind == "capability_patch" and s.kill_candidate]
    return patches

pipeline = [
    PatternStage("coarse_router", "system_contract", False),
    PatternStage("verbose_plan_node", "capability_patch", True),
    PatternStage("tool_allowlist", "system_contract", False),
    PatternStage("style_ensemble", "capability_patch", True),
    PatternStage("budget_stop", "system_contract", False),
    PatternStage("refund_human_gate", "system_contract", False),
]

assert peel_order(pipeline) == ["verbose_plan_node", "style_ensemble"]

Practical sequence:

1. Freeze contracts — allowlists, budgets, human gates, audit logs stay.
2. A/B remove one patch — e.g. drop the planner node; keep the same tools and evals.
3. Compare golden + online metrics — task success, latency, cost, safety denials.
4. Delete or keep — no “temporary” stages that live a year.
5. Document the new default pattern — so the next team does not re-add the patch from an old blog post.

Designing patterns that survive upgrades#

Build for deletion:

• Name stages by job, not by fashion — policy_gate, draft, validate, not smartAgentV3
• Mark capability patches in the architecture doc — so future you knows what is fair game
• Keep contracts outside the prompt — code, config, and policy engines outlive system prompts
• Bind evals to outcomes, not to pattern cosmetics — “plan present” is a weak metric; “correct tool sequence under budget” is not
• Prefer fewer, sharper patterns in the catalogue — Router, chain, bounded loop, planner, reflection — not twenty near-duplicates

When you adopt a heavier pattern today, write the retirement condition: “Remove planner when golden set X passes without it at p95 ≤ Y.”

How this changes architecture reviews#

Old review question: “Which cool pattern should we use?”
Better review questions:

• Which parts of this graph are capability patches vs system contracts?
• What model improvement would let us delete a stage?
• If we upgrade next quarter, what is the peel order?
• Are permissions and budgets implemented outside the model?

Teams that answer those ship less archaeology later.

Summary#

AI design patterns evolve with the models underneath them. Capability patches — verbose scaffolding, default planners, decorative critic ensembles — should shrink as LLMs improve. System contracts — allowlists, budgets, deterministic stages, human gates, evals — stay. Design for peel: mark what is temporary, freeze what is authoritative, and delete structure when the evals say you can. The winning catalogue is not the largest. It is the one that still makes sense after the next model upgrade.