The longer an agent runs, the less I care about the prompt

I used to read most agent failures as prompt problems. Now I’m not so sure. Once an agent runs for a few hours, the failures get much more boring: it reads an old design note, copies a bad pattern from the repo, decides its own output is good enough, or stops because the context window is getting crowded. A better opening prompt does not really fix any of that. I was reading about “harness engineering,” which is basically the environment around the agent: tools, docs, validation, architecture rules, and stopping conditions. I first ran into the term in a Milvus write-up, but the part that stuck with me was not vector search at all. One detail I liked was keeping AGENTS.md small and using it as a map, instead of stuffing every rule into one giant instruction file. Another was moving important rules into linters and runtime checks so the agent cannot simply forget them. The evaluator-agent idea is where I’m still undecided. In one experiment, separating the planner, generator, and evaluator produced a usable app where a solo agent produced something that launched but had broken core behavior. It also cost roughly 20x more. That is a pretty expensive default. My current feeling is: start with hard checks and real runtime evidence, then add a separate evaluator only for things normal tests cannot judge. But maybe that still leaves too much self-evaluation in the loop. For anyone running agents on longer tasks, what actually made the biggest difference for you: better docs, stricter architecture, browser/log access, or a separate evaluator?