Over the past year I've been building and deploying an agent harness — a system that orchestrates LLM agents to write, review, and ship real software for real clients. Like any production system, it has failure modes. Unlike a conventional production system, the failure modes are weirder, because the things doing the work are pattern-matching language models that read the codebase as context and continue whatever the room seems to be doing.
What follows are ten patterns I've seen often enough to name, split across two articles. The first five all share a family resemblance: the system reports success — green tests, clean review, completed checkpoint — and the success is structurally true and behaviorally hollow. The remaining five, in Part 2, are about signals that mislead in other ways: false alarms, no-op configs, prototypes read as specs.
These aren't theoretical. Each pattern below was paid for in real time, real money, or both.
1. The Green Board That Ships Nothing
Pattern: A full test suite passes and the build is declared done — but the application does no real work.
Scenario. A team uses an agent harness to build a patient-intake feature for a healthcare client. The harness reports 738 passing tests, full coverage, a clean release. Everyone celebrates. Then someone opens the running app: zero rows are written to the database, and not a single network call leaves the box. The tests were all green because they tested structure — the functions exist, the types line up, the mocks return what the mocks were told to return — but nothing verified the assembled system actually behaves.
How it sneaks in. Unit tests mock the database and the API client, so "save" and "fetch" are asserted against the mock, never the real seam. Each agent builds its slice in isolation; no agent ever runs the whole thing end to end. "Done" is defined as "tests pass" rather than "the user-visible outcome occurs."
The tell / cost. It's invisible until a human runs the product. By then the audit trail says "shipped," the client has been told it's ready, and the gap between structurally green and behaviorally correct has been certified as success. This is the single most expensive failure in agentic delivery because the whole apparatus is pointed at the wrong definition of done.
Why the fix is hard. The leverage isn't "write more tests" — it's redefining the finish line so that behavioral truth is a precondition of "done," declared up front and proven at the assembled-system level, not the unit level. How you make that cheap and non-negotiable without drowning every feature in e2e ceremony is the whole game.
2. The Lesson That Never Became a Gate
Pattern: A retro identifies a fix, writes it down, and never builds it — so the same incident recurs, sometimes into production, repeatedly.
Scenario. Early in a project, a postmortem concludes "we need a check that catches X." It goes in the notes. Six weeks and three features later, X happens again — in front of a paying customer. The team re-discovers the same lesson, writes it down again, and still doesn't build it. One feature's worth of work fans out into a week of firefighting because the loop from learning to enforcement was never closed.
How it sneaks in. Lessons live in human memory, retro docs, or a model's context window — none of which act. A note is satisfying to write and costs nothing to ignore. Nobody can see, at a glance, which lessons have teeth and which are just prose.
The tell / cost. Your "lessons learned" archive grows while your defect rate doesn't fall. The org is learning and forgetting at the same rate. This is the meta-failure: a harness that can't improve itself reliably will relearn every lesson the expensive way.
Why the fix is hard. The insight is that a lesson must terminate somewhere enforceable, and that the gap between "logged" and "enforced" has to be made visible and measurable — you can't fix a leak you can't see. Making that closure mechanical, without turning every passing thought into bureaucracy, is the part I'm not giving away.
3. Autoregressive Dismissal (the compounding shrug)
Pattern: An agent waves off one diagnostic; the next agent reads that as license and waves off more; errors accrete across the build.
Scenario. In a multi-wave build of an analytics dashboard, an early agent hits a type-checker warning, decides it's noise, and suppresses it. The next wave's agent sees a suppressed warning already in the file and treats suppression as the house style. By the thirteenth wave the codebase carries a dozen swallowed diagnostics — and one of them was a real bug that ships.
How it sneaks in. Models are pattern-continuers by construction. A single dismissal in the context becomes a precedent the model faithfully extends. Each individual call looks locally reasonable ("just one warning"); the compounding is only visible in aggregate.
The tell / cost. The error count drifts up wave over wave while every individual commit looks clean. Because it's autoregressive, it accelerates — the more dismissals exist, the more the next agent dismisses.
Why the fix is hard. The leverage is treating the first dismissal as the event to govern, not the thirteenth, and removing the low-friction path that makes shrugging cheaper than fixing. The discipline that prevents the cascade is the value.
4. Fabricated Fidelity (the confident stand-in)
Pattern: A prep agent invents the shape of an external dependency it couldn't reach, and every downstream agent builds on the fabrication without questioning it.
Scenario. A migration off a low-code SaaS platform needs a client for an external API whose docs the team didn't have handy. The prep agent, rather than stopping, invents a plausible response shape and builds a fake client around it. Seven downstream agents build features on that fake. None of them re-checks it against reality — why would they? It's already in the codebase, written confidently. The whole subtree is quietly wrong from the root.
How it sneaks in. Agents are rewarded for momentum, and a confident fabrication is indistinguishable from knowledge in text. Test doubles that look real propagate trust. The single point of failure is at wave zero, where it's least scrutinized.
The tell / cost. Everything downstream is internally consistent and externally false — the worst kind of wrong, because consistency reads as correctness. You find it at integration time, after the most expensive work is already built on sand.
Why the fix is hard. The leverage is upstream: making fabrication-under-uncertainty structurally harder than escalation, so a missing dependency stops the line instead of getting papered over. Where you put that tripwire, and how you keep it from blocking legitimate work, is the craft.
5. The Trust Chain (gates that vouch for each other)
Pattern: A sequence of quality gates each assume an earlier gate already caught the problem — so nothing actually catches it.
Scenario. A feature passes five checkpoints on its way to release. A placeholder — a stubbed-out empty state, a "TODO" left in a handler — sails through all five. Each gate was scoped to its concern and implicitly trusted that an upstream gate had handled correctness-of-completeness. The stub had five chances to be caught and zero gates whose job it actually was.
How it sneaks in. Defense-in-depth degrades into diffusion-of-responsibility when no gate is explicitly the one that owns a given failure class. Each gate is individually well-designed; the seam between them is where things fall through.
The tell / cost. Post-mortems that end in "but it passed review" — five times. The more gates you add naively, the more this happens, because each new gate dilutes ownership rather than concentrating it.
Why the fix is hard. The non-obvious move is that gates must distrust each other, and someone has to own each failure class by name. Designing a gate lattice that's adversarial rather than collegial — without grinding throughput to zero — is the hard, valuable part.
Part 2 picks up at number six and turns from "success that wasn't" to "signals that mislead": local optimizations that tax the operator, configuration knobs that don't do anything, guardrails that cry wolf, reviews that engage everything except the architecture, and prototypes mistaken for specs.
About Heavy Chain
Heavy Chain works with engineering organizations to deploy AI-native PDLC and SDLC — the Etc framework, together with the tooling, gates, and review rituals that make it real — into existing teams. The harder half of the work is change management: helping the new lifecycle stick without breaking what already works. The patterns above are drawn from that work; if any of them feel familiar, that's where we come in.