---
title: "Agent Complaints Are Factory Requirements"
description: "Coding-agent failures become solvable when teams turn each complaint into a routing, authority, proof, or recovery requirement for the factory."
author: "Gunner Technology"
published: "2026-10-31"
url: "https://www.gunnertech.com/blog/agent-complaints-are-factory-requirements"
---

# Agent Complaints Are Factory Requirements

When a coding agent wastes the night, burns the expensive model on grunt work, or asks permission to name a branch, the model is not the whole problem. The factory around it is unfinished.

## Your frustration is a requirement list

Coding-agent complaints tend to sound like personality defects. The agent is lazy. It cannot plan. It picks the wrong model, waits when it could work, and stops over a decision no reasonable person would escalate. That language is understandable when you are the person staring at an idle session. It is also too vague to fix anything.

Translate each complaint into an operating requirement. If independent tasks run one after another, the system needs a dependency graph and a scheduler. If a routine naming choice blocks the run, the route needs a default and a deadline for escalation. If expensive intelligence spends its time searching for a simple pattern, the factory needs a cost-aware router. The complaint names the symptom. The requirement names the missing machinery.

Our position is blunt: these are solved classes of problems. Queues, sandboxes, policies, timeouts, worker pools, and evidence gates are not speculative inventions. The hard part is assembling them into a delivery system that gives agents useful freedom without handing them unlimited authority.

## The default agent is not the product

It is fair to want a coding tool to arrive with better defaults. A useful default should understand its own controls, explain a plan in human terms, and avoid sitting idle over a reversible choice. But expecting one vendor's interface to encode your repositories, risk limits, cost preferences, release rules, and definition of done confuses a general tool with your operating model.

The agent is one worker in the line. Your factory decides how work enters, which context travels with it, what can run in parallel, which model gets which job, and what proof permits the result to move forward. Those decisions belong to the organization because their consequences do. A vendor can offer knobs. It cannot decide which production mistake your business is willing to accept.

That distinction also explains why switching models rarely cures the frustration for long. A stronger model may plan better or recover from ambiguity more gracefully. It still enters the same missing route, broad permission boundary, or manual review queue. Better judgment inside an unfinished system can hide the gap. It cannot close it.

## Authority needs real walls

Security is where polite instructions become indefensible. Telling an agent not to read a directory is not the same as preventing access. Asking it to use a credential carefully is not the same as keeping the credential outside its context. A boundary the worker can ignore, reinterpret, or route around is only a preference.

Build the wall with the operating system, the network, and narrow credentials. Give the task access to the repository it needs, not the machine that happens to contain it. Inject secrets at the request boundary instead of placing them in readable files. Separate the authority to build from the authority to release. Then test the refusal from outside the builder's chosen conditions.

This is not a reason to click an approval button hundreds of times. Repeated approval trains the person to stop judging. The factory should grant routine, reversible actions in advance inside a hard sandbox and reserve human attention for consequences that cannot be cheaply undone. Good control removes interruptions because the safe path is already defined.

## Autonomy needs routing and recovery

A long-running task should not depend on a person being awake for every small choice. Give the route explicit decision rights. The agent may choose a reversible default, retry a bounded failure, and continue through independent work. It must stop when the missing decision changes the product, expands authority, or creates a consequence the system cannot reverse.

That requires more than a better prompt. The scheduler needs to know which tasks depend on one another. The router needs cost, latency, capability, and quota signals. The control room needs to show what is running, what is blocked, and why. Recovery needs a checkpoint that another worker can pick up without reconstructing the entire session from a transcript.

Once those controls exist, parallelism becomes a choice instead of a stunt. The factory can run independent jobs together, hold risky work behind a stronger gate, and spend expensive intelligence only where the decision earns it. More agents do not automatically create more throughput. A governed route does.

## Make every failure install a control

The first bad run is information. The fifth identical bad run is an operating decision. If an agent repeatedly misunderstands a plan, rewrite the task contract and check its shape before execution. If it chooses the wrong model, change the router. If it stalls on a trivial question, add a default. If it reaches beyond its scope, narrow the sandbox and add an adversarial test.

Do not solve these failures by teaching one person a longer ritual for babysitting the tool. That creates a private craft that disappears when the person leaves and keeps human attention trapped at the lowest level of the system. Capture the correction where every relevant run will meet it.

Coding agents are not waiting for a magical model to make them useful. They are waiting for organizations to stop treating the chat window as the whole system. Turn the complaint into a requirement, the requirement into machinery, and the failure into proof that the machinery changed. That is how an annoying assistant becomes a productive asset—and how the work stops depending on someone watching it all night.

In response to [Why are coding agents so dumb?](https://mtlynch.io/why-are-coding-agents-so-dumb/) by Mtlynch.
