Agents Fall Apart When Running Long Tasks, and Lunar Says Don't Rush to Rewrite the Prompt

On X, Lunar recommended a 28-minute video by an engineer who helped build Claude Code, on the topic of writing prompts that actually work. The tweet contrasts it with a $600 course and says the first five minutes cover material those courses don't.

Beyond the video, Lunar also linked a long article titled Harness Engineering: The Complete Guide to Building AI Agents That Don't Fall Apart. The article has 19 sections and opens by taking aim at a common reflex: an agent fails, so you rewrite the prompt; it fails again, so you add more instructions; then you switch models, add tools, and expand context. Lunar argues that many failures happen outside the model.

He sums up this layer with one word: harness. For nontechnical readers, a rough analogy: the model is the engine, and the harness is the chassis, brakes, dashboard, maintenance records, and traffic rules. The model handles reasoning; the harness makes that reasoning land reliably in a real environment. The article defines Harness Engineering as the practice of building the environment that turns model intelligence into reliable work. A prompt changes one attempt; a harness changes every attempt.

The article starts with task contracts. A vague 'optimize the onboarding flow' is not enough. The harness must first turn the request into a contract that answers five things: what result must appear, what is in scope, what must not be changed, what evidence proves completion, and which actions require human approval. Without a contract, an agent tends to optimize for 'looking busy'; with a contract, it can move toward verifiable completion.

Next is context. Stuffing the entire repository, docs, and chat history into the context is what Lunar calls context flooding. A better approach is to provide a project map first, then retrieve details as the task requires. Context should expand because the task needs it, not because information exists. The goal is maximum signal per token, not filling the window.

On tools, the article recommends building a tool gateway instead of piling up tools. Every tool should have a contract: inputs, preconditions, success evidence, failure behavior, and risk level. The model proposes an action, the gateway validates it, the tool changes the environment, and sensors observe the result. Twenty tools do not make an agent more capable; they just give it twenty ways to make mistakes.

The article also separates Brain, Hands, and History. Brain handles planning and reasoning, Hands execute tools in a controlled environment, and History stores durable facts, decisions, progress, and lessons. Conversation history is an event stream, not reliable memory. Raw history is kept for audit, while persistent state is compiled for execution. Long tasks must be resumable, inspectable, and repairable.

Completion cannot rely on an agent saying 'done.' The article lists contrasts: if it says a bug is fixed, check whether the failing test passes; if it says a page works, check whether the browser flow completes; if it says a migration is safe, check the dry run and rollback; if it says a report is correct, check whether the numbers match the source data. The model can claim completion; only the environment can prove it. Verification should attack the result: the worker builds the strongest solution, and the verifier looks for reasons to reject it. Asking the same agent to 'check again' in the original context often preserves the assumptions that caused the error.

Policy should live outside the reasoning loop. Reading files, searching, and checking can be automatic; editing the workspace and running tests can be automatic but must leave a trace; sending messages, deploying, and purchasing require explicit approval; deleting data, rotating credentials, and global releases use hard gates or are forbidden. Autonomy does not mean no control; it means freedom to act within clear boundaries. Recovery should also be handled by failure type: back off on timeouts, fix the call on bad parameters, retrieve when context is missing, request approval when permission is denied, and stop on repeated unchanged failures. A retry must change at least one relevant condition; otherwise it just spends money reproducing the failure.

The article also notes that recurring rules should be pushed down into infrastructure. Prompts explain judgment; the harness enforces invariants. Runs should leave traces recording state transitions, context sources, tool inputs and outputs, environment changes, verification results, retry reasons, approval decisions, cost, and latency. Each run should end with a change receipt: goal, what changed, what was verified, what was not verified, decisions, risks, and pending approvals. It summarizes what the system can prove, not what the model said.

Lunar also warns that a harness can rot. Workarounds left over from old model limitations can become today's friction. Every router, evaluator, memory layer, and retry rule should be asked: what failure does it prevent, does that failure still happen often, how much latency and complexity does it add, and what would happen if we deleted it? The best harness is the smallest system that can reliably close the gap between intent and evidence. The article offers a layered path: bounded tasks, readable environment, controlled actions, durable execution, evidence, and recovery and learning. Complexity should be earned by observed failures; don't start with a multi-agent architecture.

The article ends with a measurement: accepted outputs / (human review minutes + run cost). It also lists first-pass rate, recovery rate after tool failure, repeat failure rate, number of human interventions, completion claims without evidence, time from request to verification result, and overhead of each component. An agent that looks productive may simply be creating more expensive review. The article argues that the first generation of AI products revolved around prompts, and the next revolves around environment. Models provide intelligence; harnesses provide structure.

Original tweet: https://x.com/LunarResearcher/status/2118327560589246747

Lunar's long article: https://x.com/i/article/2096536117130481673