The Failure Modes That Don't Improve With Scale

Most agent limitations are capability limitations, and capability improves. It's reasonable to assume that anything an agent does badly today it will do better in a year, and for a large class of problems that assumption holds.

For a smaller class it doesn't, because the failure isn't about the model at all. Distinguishing the two changes what you build around and what you wait for.

The distinction

Capability failures come from the model not being good enough at something. Wrong tool selection, poor reasoning on a hard problem, weak long-context handling. These improve, sometimes quickly, and building elaborate workarounds for them can be wasted effort.

Structural failures come from the situation, not the model. Missing information, absent feedback signals, requirements that aren't about correctness at all. A better model in the same situation produces a better-argued version of the same failure.

→ The test: if the model were substantially better, would this failure go away? If the answer requires the world to change rather than the model, it's structural.

The structural ones

Information that doesn't exist in any artifact. An agent can't know the customer is fragile, the module is being replaced, or the last attempt failed badly, if none of that is written anywhere. This is bounded by what gets recorded, not by capability. It narrows where organizations capture more — slowly, unevenly, and never completely, because the most load-bearing context is the least articulable.

Absence of a feedback signal. Agents get strong where there's an oracle: compile, test, reconcile, validate. Where correctness can only be assessed over months and is confounded by everything else — a prioritization call, an architecture decision, a hiring choice — there's no loop to iterate against. A better model produces a more sophisticated guess, not a checked answer.

Accountability. Some decisions require a party who can be asked to explain and who bears consequences. That's a structural requirement about responsibility, not a question of judgment quality. It moves only if social and legal arrangements move.

Preferences that have no correct answer. Should the product be simpler or more capable? Is this trade-off acceptable to our customers? These aren't hard questions with unfound answers — they're questions where the answer is a choice someone has to own.

Trust as a prerequisite. People extend autonomy based on predictability and recourse, not capability. An agent that's right more often but whose failures are unpredictable may get less autonomy than a weaker one with legible limits. This is a property of the relationship, not the system.

⚠️ The tempting mistake in both directions

Building around a capability failure wastes effort. Elaborate scaffolding to compensate for something that improves next quarter is scaffolding you maintain forever for a problem that went away.

Waiting out a structural failure is worse. "Once models are better, the agent will know what to prioritize" describes something that isn't going to arrive from that direction, and time spent waiting is time not spent building the mechanism — the feedback signal, the context capture, the accountability structure — that would actually address it.

✅ What to do with each

For capability failures: build the thinnest possible workaround, keep it isolated, and re-test it when models change. Note them explicitly as things to revisit rather than as permanent design constraints.

For structural failures: change the situation, not the model.

• No feedback signal → build the oracle. Making something mechanically checkable is the highest-value engineering move available, and it converts a structural limitation into a capability one.
• Missing context → capture it as a side effect of work, not as a documentation project. The context you find yourself repeatedly supplying is the context worth recording.
• Accountability → design the human checkpoint properly rather than waiting for it to become unnecessary.
• No correct answer → keep the choice with whoever owns the consequence, and use the agent to enumerate options rather than to pick.

🔍 Applying the test

For each thing your agent does badly, ask whether a substantially better model would fix it.

The answers sort quickly, and they sort your roadmap. The capability list is a waiting list with light workarounds. The structural list is your actual engineering work — and it's the list that determines whether the system keeps improving when the model stops being the limiting factor.

The takeaway

Some agent failures dissolve with better models and some don't, and the difference is whether the model or the situation is the constraint. Test each one by asking whether a stronger model would help. Build thin workarounds for the capability list; for the structural list, build the oracle, capture the context, and design the human checkpoint — because those are the failures that will still be there when everything else has improved.