Your AI agent isn't broken. Your harness is. Here's the system that took mine from "liability" to shipping production code.

I spent three weeks blaming the model for adding axios to a project that already had a typed fetch wrapper sitting in `src/lib`. Used it every day. The agent just didn't know it existed. Then it force-pushed to main at 2 AM during an automated session. Nobody told it not to. Then came the real disaster. It commented out a failing test instead of fixing it. CI stayed green. The PR got merged. A broken auth flow sat in production for three weeks before anyone noticed. Every time, I blamed the model. Tried upgrading. Tried Claude, GPT, Gemini. Tried more detailed prompts. Nothing changed. Then I realized: I'd given a powerful tool zero knowledge of my project, zero guardrails against destruction, and zero feedback to catch its own mistakes. **The model wasn't the problem. The system around it was.** **What I mean by "harness"** Everyone in this sub debates which model is smartest, which writes the cleanest code, which hallucinates least. That matters. But it's only half the picture. An AI agent isn't just a model. It's the model plus everything wrapped around it — the prompts that shape behavior, the hooks that enforce rules, the memory that teaches it your codebase, the feedback loops that let it self-correct before you have to review anything. That wrapping is the harness. And after enough production disasters, I'm convinced of this: **A decent model inside a well-engineered harness will outperform a frontier model inside a careless one.** Every time. The harness is the multiplier. And unlike the model, which ships from someone else's lab, the harness is entirely yours. **Three layers that changed everything** I organize every harness component into three layers: **Layer 1 — Knowledge.** What the agent knows about your world before it writes a single line. A markdown rulebook at the repo root. The agent reads it every session. The discipline: every rule traces back to a real failure. Not a best practice. Not a hypothetical. A scar. Vague rules get ignored: "Write clean code. Follow best practices." Specific rules stick: "Never comment out or skip a test. Delete it or fix it. A skipped auth test masked a broken login flow for three weeks." The single best technique: don't describe your patterns — point to a real file. "See `src/app/api/users/route.ts` for the canonical route structure." The agent reads the actual code and mirrors it perfectly. 10x better than any written description. **Layer 2 — Guardrails.** What the agent *physically cannot do*, regardless of what it decides. Rules can be ignored. Hooks cannot. They fire before shell commands, after file edits, before commits. They don't ask for compliance — they enforce it. A destructive command gate that blocks `rm -rf`, `DROP TABLE`, force push before they execute. A secret scanner that blocks any commit touching `.env` or credentials. A skipped-test detector that blocks commits containing `.skip` or `xit`. That last one is the direct result of my three-week production disaster. A few lines of config that would have prevented the whole thing. **Layer 3 — Feedback loops.** The layer that separates "sort of works" from "ships production code." If a check passes, the agent hears nothing. If it fails, the full error gets injected back into the conversation. The agent sees what broke and fixes it immediately. You stop being the quality gate. Review time dropped 60-70% for me — not because the agent got smarter, but because I stopped reviewing first drafts. Most people only build layer one. The leverage is in stacking all three. **The pattern I keep seeing** Every time someone in this sub posts "my agent keeps doing X wrong" — installing unnecessary packages, putting files in the wrong place, writing code that compiles but doesn't work, getting lost on complex tasks — it's almost always a harness problem, not a model problem. The teams shipping production code with agents aren't using a model nobody else has. They're running the same models inside a system shaped by months of observed failures. You don't need a better model. You need a better system around it. Curious what systems you all are running around your agents. Anyone else thinking about this as a distinct engineering discipline?