Your Agent Isn't Broken — What's Around It Is

The very same model behaves like a reliable senior developer in one repository, yet in another it gets muddled, loses context between sessions and declares features finished when they don't actually work. Many people's instinct at that point is to rush out and upgrade to a newer model. And that almost never helps: the same model copes perfectly well on a well-organised project. So the problem isn't the agent's abilities — it's what surrounds it. That surrounding environment is what we call the harness.

The word 'harness' originally referred to the tack fitted round a horse: everything outside the model's weights that determines how much of its capability actually shows up in your project. The rule is simple: if it isn't part of the model weights, it's part of the harness. That includes instruction files such as AGENTS.md and CLAUDE.md; the tools available to the agent — shell, tests, linter, MCP connectors; the execution environment with its runtimes and containers; state management via progress files and git checkpoints; and feedback loops — verification commands and end-to-end tests.

There's a metaphor that captures the heart of this course rather well: the model is the horse, and the finer its breeding, the greater its potential. The harness is the tack: bridle, reins, stirrups. The point isn't that a fine horse without tack can't get anywhere — if anything, it can bolt off at full gallop. The problem is quite different: without tack, the rider has no way of controlling it. The horse ignores the bit, pays no heed to commands, and goes wherever it fancies rather than where it needs to go. That's why in this course we'll hardly talk at all about picking a finer-bred model — we'll talk about building the tack that makes it rideable.

The first diagnostic rule of this course is simple: when your agent breaks, check the harness first, and only then the model. If the very same model solves similar tasks successfully in well-structured repositories, the problem almost certainly lies in your environment, not in its abilities. Replacing the model is the most expensive and the most unpredictable form of repair, because you change everything at once and never find out which particular change did the trick. Diagnosing the harness is cheaper, faster and almost always points far more precisely to the cause.

If you already use an AI coding agent — Claude Code, OpenAI Codex, Cursor or something similar — and you're getting inconsistent results, this course was written for you. For people who want their agent working for hours and entire sessions, not ten minutes under supervision. For those building internal tooling or platforms around agents, and for anyone answerable for making sure code written by an agent can be merged without fear. To put it briefly: this course is for anyone who wants to move from 'writing prompts' to 'designing a system that writes prompts'.

A course is usually a set of notes that gathers dust on your hard drive within a month. Here it's different: the entire course is built around one project — an imaginary payments backend on FastAPI — and every lecture adds one genuine file to it: AGENTS.md, feature_list., verify.sh, program.md and so on. By the final lecture you won't have an abstract list of ideas; you'll have a working repository containing the complete harness — and you can lift that exact skeleton straight into your own project the very next day.

The route through this course isn't a list of topics but the story of a single agent who steadily improves as we go. We begin with theory: why agents make mistakes, and precisely which layer fails. Then the harness is taken apart piece by piece: the instructions the agent actually reads, memory between sessions, honest verification, and towards the end autonomous loops and graphs of roles. Every lecture opens with a real symptom — 'the agent said done, but the feature doesn't work' — rather than a paragraph of definitions. And it all unfolds on the same growing repository, so by the finale the harness comes together as a whole instead of remaining a scatter of disconnected tricks.

Don't judge this course by its list of topics — judge it by the outcome. After the first lectures, you'll know exactly how to tell whether the harness is broken or the agent genuinely lacks the capability it needs. You'll go on to write an AGENTS.md the agent follows in full, not just its first five lines; you'll put a gate in place that stops it declaring the job done on its own; and at some point you'll simply let it get on with things for hours without watching over its shoulder — because the harness catches its mistakes, not you.

Don't judge this course by its list of topics — judge it by the outcome. After the first lectures, you'll know exactly how to tell whether the harness is broken or the agent genuinely lacks the capability it needs. You'll go on to write an AGENTS.md the agent follows in full, not just its first five lines; you'll put a gate in place that stops it declaring the job done on its own; and at some point you'll simply let it get on with things for hours without watching over its shoulder — because the harness catches its mistakes, not you.

Before we move on to specific techniques, there's one question we need to answer — the question the whole course grows out of: if the agent gets things right ninety-five times out of a hundred at every step, how does it still manage to fail the entire task by step ten? Until you can answer that, every harness technique looks like a random pile of checklists with no explanation of why they'd ever work. And that's precisely where the next lecture begins — not with paragraphs of definitions, but with the maths of one very specific failure.