The agent hung. Same error. Three times. I closed the IDE, reopened it, and watched it hang again. At some point I stopped blaming the agent and asked a different question. If this were a new hire crashing the same system three times in a row, I would not let it continue. I would stop. I would ask whether the problem was mine: did I give them the right requirements, the right tools, the right environment? The Jest config had never been updated for agent-scale development. The monorepo had mushroomed in size, velocity through the roof, and the root config was still scanning the whole repo as though nothing had changed. The agent was not failing. I had never properly introduced the agent to the system it was supposed to work in. That is a management failure. The fifteen-character fix came second. The honest self-audit came first.
This is the frame most engineering teams are missing. When an AI coding agent keeps failing, the instinct is to blame the model, retry the prompt, or close the IDE and start over. None of those responses is management. Management requires a stop, a binary diagnostic, and a decision. Is this a management failure or a performance failure? That question is not rhetorical. It has a protocol. And the protocol has to be built into the agent system before the failure happens, not improvised after the third hang.
The industry has the velocity conversation. It has the prompt engineering conversation. It does not yet have the management conversation. That is the gap, and it is costing teams more than they have calculated.
§ 01 — The management self-audit: assume it is you first
Every experienced manager knows the first move when a capable person keeps producing bad output: look inward before looking at the person. Did I communicate the requirements clearly? Did I give them the tools they needed? Did I put them in an environment where success was actually possible? The same discipline applies to AI coding agents, and most teams are skipping it entirely.
The Jest story is a clean example of what management failure looks like in an agent context. The monorepo had been designed for hand-coding at human scale. The root Jest config scanned the entire repo, which was fine when the repo was bounded by the pace of human authorship. Switch to agent-assisted development and the assumption collapses. The agent does not increment. It produces. Code volume that would take a developer a week arrives in an afternoon. Services multiply. The root config, never updated, now attempts to traverse a repo two orders of magnitude larger than the one it was designed for, and the process runs out of memory before a single test executes.
The agent was doing exactly what it was asked. The toolchain had never been introduced to the agent it was supposed to support. That is not a performance problem. That is a management failure.
The self-audit has three questions. Does the agent understand the task, the domain, and the codebase structure? Does it have the right goal, with no conflicting rules pulling it in the wrong direction? Does it have the tools, memory, and environment to actually execute? These map directly to the three levers available when the answer is no: sharpen the agent definition, rewrite the skill, or fix the scaffolding. The model is not on the list. The model is the last variable you adjust, after you have exhausted the ones you own.
§ 02 — The circuit breaker as a management trigger
A circuit breaker in an electrical system does not diagnose the fault. It stops the current before the damage compounds and creates the conditions for diagnosis. The pattern applied to AI coding agents works the same way, with one critical addition: the stop forces a management decision, not just a technical one.
The trigger is a terminal command, whether a test run, a build, or a lint pass, failing twice with the same or substantially similar error signature. The action is an immediate stop: no third attempt. The output is a structured report presenting what the agent tried, the repeated error signature, and a hypothesis for root cause. Then comes the question that matters: is this on me, or is this on the agent?
The third attempt is never the answer. The third attempt is what you do when you have abdicated the management decision. Stop at two. Ask the binary. Then act.
Why twice? Once is a legitimate attempt: the error could be a genuine code defect worth a quick fix. Three times means a full wasted cycle has already elapsed and you are now in a loop you chose not to break. Two is the threshold that preserves the value of the first attempt whilst forcing the management question before the waste compounds. The developer almost always carries context the agent cannot access: a config file that predates the agent, a memory ceiling that was never raised, a scope assumption baked in before agent-coded volume was even a consideration. The agent surfacing the binary is worth more than a third blind attempt, every time.
If the self-audit clears and the problem persists, the diagnostic shifts to the agent. Does the agent get it: does it understand the task, the domain, the structure of the codebase? Does it want it: is it aligned to the right goal, or are conflicting rules pulling the output sideways? Does it have the capacity: the right tools, the right skill definitions, the right context window to execute what is being asked? Every answer points to the same resolution: update the agent definition, the skills, or the tools. You are not blaming the model. You are managing the system.
§ 03 — Building the management discipline into the instruction set
The circuit breaker does not work if it lives only in the developer’s head. The decision to stop has to be built into the agent system itself, which means it has to be in the instruction set before the failure happens. A 500-line instruction file is a context window waiting to fail; rules buried at line 340 will not reliably surface when the agent is deep in a task and its attention is saturated with code context. Placement is the mechanism. Layering is the solution.
Three layers carry the rule reliably into every agent session. The first is a global rule in the master instruction file every agent inherits. Short, definitive, impossible to miss. Five lines maximum:
CIRCUIT BREAKER: If any terminal command (test, build, lint) fails twice
with the same or similar error, stop immediately. Do not attempt a third
fix. Present what you tried, the repeated error signature, and your
hypothesis. Ask the developer whether to proceed differently or address
a configuration issue first.The global rule establishes the behaviour. The second layer, a skill-level protocol in the domain-specific skill file, carries the diagnostic detail: what constitutes a “same or similar” error signature, the class of failures caused by toolchain configuration that predates agent-scale code production, and the three management questions the developer should run before assuming the agent is at fault. The skill file loads when relevant, reaching the agent precisely when the circuit breaker is most likely to fire. The third layer is a one-line pointer in each specialist agent definition, ensuring the rule is loaded even when the global instruction set is not invoked directly.
The global rule catches attention. The skill carries the protocol. The agent pointer ensures coverage. You are not prompting the agent to behave better. You are installing the management discipline into the system itself.
§ 04 — The same scene, managed differently
Return to the Jest hang. The agent runs the tests. Memory ceiling. Hang. The agent applies a fix and runs them again. Same signature. The circuit breaker fires. The agent stops and reports: “This has failed twice with the same pattern. Jest appears to be scanning the full monorepo and exhausting memory before any tests execute. This looks like a configuration scope issue, not a code defect. The root Jest config may predate the current repo size. Should I audit the Jest configuration, or do you have context about recent scope changes?”
The developer runs the self-audit. Requirements clear? Yes. Right goal? Yes. Right environment? No. The root config had never been updated when the team switched to agent-assisted development. Management failure. The fix takes two minutes: scope the config to the affected service, add forceExit: true. Done.
The agent did not fail. The system had never been set up for the agent to succeed. Those are not the same thing, and confusing them is how teams stay stuck.
The developers extracting the most from AI coding agents are not the ones with the best prompts or the most powerful models. They are the ones who have internalised the management frame: assume it is you first, run the audit honestly, and fix the system before you question the agent. They have upgraded the toolchain to match the velocity the agent introduced. They have built the circuit breaker into the instruction set so the stop is automatic, not improvised. They treat every failure as a management signal and act on it.
The industry has the velocity. Most teams do not yet have the management discipline to match it. The teams that build it first will compound. The teams that keep closing the IDE and reopening it will keep losing hours they have not yet learned to count.
The best agent managers assume it is always them first. That assumption is not humility. It is the fastest path to a system that works.