Antipatterns of Omission

Overview

The first two antipatterns were things that happen. These three are things that were never built.

Nobody made a mistake. A control that would have caught the problem simply does not exist, usually because it produced no visible feature and therefore never won a prioritisation argument. That makes these the antipatterns an architect is most responsible for, because they are the ones with no natural advocate.

Three absences

graph TD
  A["<b>No evaluation</b><br/><i>cannot answer:<br/>is it better than last month?</i>"] --> D["Shipped on<br/>an impression"]
  B["<b>No bounds</b><br/><i>no step cap, token budget,<br/>timeout or spend cap</i>"] --> E["One conversation<br/>visible in the bill"]
  C["<b>No attribution</b><br/><i>cannot say which<br/>component grew</i>"] --> F["Spend climbs with<br/>no decision behind it"]

  classDef gap fill:#D8D3CB,stroke:#B8B2A8,stroke-width:2px,color:#3F3F3F
  classDef cons fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A,B,C gap
  class D,E,F cons

Three missing controls and what each permits. The drained boxes are absences — which is why none of them appears in an incident review as a cause.

The eval-free deployment

What it is. The system ships with no systematic measurement of output quality. It seemed to work in testing, and it continues to seem to work.

Why it happens. Evaluations cost money per run and human time to curate, and they produce no feature. Under deadline pressure they are the easiest thing to defer, and deferring them has no immediate consequence — which is exactly what makes them easy to defer again.

Detection signal. Ask: is it better or worse than last month? If nobody can answer with a number, the deployment is eval-free regardless of what the plan says.

Structural fix. Module 6’s Section 3. The minimum viable version is small — a frozen set of real cases, a grader that handles the structurally checkable properties, and a reported number with variance — and a small eval that runs is worth far more than a comprehensive one that was never built.

The unbounded agent

What it is. A loop with no step cap, no token budget, no wall-clock timeout and no spend ceiling.

Why it happens. It works fine in development, where the tasks are short and the operator is watching. Bounds only matter on the pathological interaction, which by definition has not happened yet.

Detection signal. Cost variance with a long tail; interactions taking minutes; and the specific tell — a single conversation visible as a line item in the monthly bill.

Structural fix. Module 5’s four bounds, with Module 6’s arithmetic as the argument: because cost grows with roughly the square of turn count, an unbounded loop is not linearly expensive, it is quadratically expensive. And Module 7’s retry topic adds the sharper risk: an unbounded loop that can retry consequential actions is not just a cost problem.

The cost spiral

What it is. Spend climbing steadily with no single decision responsible. A prompt grows a paragraph at a time. Retrieval depth creeps up because someone was chasing a quality problem. A cache quietly stopped working after a prompt-assembly change. Three tool schemas were added.

Why it happens. Each individual change is small and defensible, nobody is looking at the aggregate, and the bill arrives monthly while the changes arrive daily.

Detection signal. Cost per resolved task rising while nobody can name a change that caused it. The giveaway is the phrase nothing changed — which here means nothing changed that anyone attributed.

Structural fix. Module 6’s governance: attribution per traffic class, published routinely rather than when something goes wrong, and the one-lever-per-change discipline so effects attribute. Plus the cheapest single check — verify the cache is still being read, from usage data, after every prompt-assembly change.

The common property

All three are prioritisation failures wearing engineering clothes, and all three share a structure: the control produces no visible feature, so it has no advocate.

A feature has a product manager who wants it. A spend cap has nobody. An eval set has nobody. A step cap has nobody until the afternoon it would have saved you.

Which is precisely the architect’s job as Module 2 framed it: these are requirements with owners, written down, in the NFR budget, with names attached. An unowned control is a control that will be cut, and the moment it gets cut is the moment somebody needs to ship by Friday.

Two covered, one still live

Auditing the Modules 4–6 design against all three.

The eval-free deployment: covered, conditionally. Module 6 specifies the golden set, the grader types, the aggregation, the harness proving and the regression gate. The condition is that none of it exists yet, and Module 6 was explicit that the first version will be assembled from the audit sample rather than from traffic the platform has not seen. So the design is not eval-free; the project will be until someone builds it, and the trigger to watch is the first release date arriving before the set does.

The unbounded agent: covered. Step cap of 12, a task budget derived from the p95 cost ceiling, a 25-second timeout, and a spend cap enforced outside the application with degradation at 80%. Four bounds, each with a derivation and an exhaustion path.

The cost spiral: live, and the most likely of the three to bite. Attribution is specified — three traffic classes with separate keys, per-interaction cost in the trace — but nothing yet owns the drift. Specifically unowned: prompt growth, retrieval-depth creep, and cache breakage after a prompt-assembly change.

That last one deserves naming as a requirement because it is both the likeliest and the cheapest to catch. Module 6 established that caching is the single largest cost lever on the action path and that it must be verified from usage data rather than code review. Nothing currently requires that verification to happen after a change. So:

After any change to prompt assembly, confirm from usage data that cache reads still dominate fresh input before the change ships.

One sentence, added to the release checklist, closing the gap that would otherwise produce a cost spiral nobody could attribute. Engineering owns it; Dev Raghunathan sees the monthly number that would otherwise be the first signal.

Feeds the workbook

Three more entries for your antipattern review, and the honest version of this exercise is to check which of the three your own design merely mentions versus actually assigns. A control named in a document with no owner is closer to absent than present.

Check your understanding

1. Which of the three is live in your design? Who would have to own the fix?
2. “Nothing changed” and costs are up 30%. What do you check first, and what would you wish you had been recording?
3. Pick one control in your design with no named owner. What happens to it the week before a deadline?

---

→ Three absences. The next antipattern is the opposite: reaching for something before anyone said what was wrong. — The “just add RAG” reflex