Agents Keep Failing—and Most People Are Fixing the Wrong Thing

Andrej Karpathy dropped a line in a recent video:

"The biggest mistake in AI right now is that people force agents to do work instead of first mastering harness engineering for the model. We made this mistake at OpenAI in 2016, and it cost us five years."

His point is direct: the agent is not the product; the harness is. If the foundation isn't built, everything stacked on top collapses. The so-called harness is the layer of environment around the model, responsible for turning the model's one-off cleverness into repeatable work.

A researcher at Lunar wrote a long article about this, titled “Harness Engineering: The Complete Guide to Building AI Agents That Don't Fall Apart.” The article opens with a very accurate judgment: most agent failures are not in the reasoning layer; they are in the environment layer.

The agent doesn't know which files matter. It uses the wrong tool in the right place. It loses decisions made in the previous session. It declares success without running checks. After a partial failure, it repeats the same action. It gets permissions that should have gone through approval.

The model isn't necessarily the problem. The system around the model is incomplete. This system is called the harness, and designing it is becoming a separate engineering discipline.

First, turn the task into a contract

"Optimize the onboarding flow." That sentence is enough for chat, but far from enough for autonomous execution.

The first thing the harness must do is translate that sentence into a task contract: what the goal is, where the scope lies, what must not be touched, what evidence counts as completion, and which actions require human approval.

Without a contract, the agent optimizes for "looking busy." With a contract, it optimizes for "verifiable completion." Its question changes from "What should I do next?" to "Which action brings the environment closer to the result in the contract?"

Give it a map, not a manual

Dumping the entire codebase, the whole documentation set, and all conversation history into the context is not context engineering; it's a context flood.

A good harness first provides a small map: which directory contains the product rules, where the architecture docs are, how to run the test command. When the agent needs details, it fetches them itself. This is called progressive disclosure. The goal is simple: maximum signal per token.

More tools is not better

Give an agent twenty tools, and it has twenty ways to make mistakes.

Every tool should have an explicit contract: what the inputs are, what the preconditions are, what evidence of success is, how failures are returned, and what the risk level is. Four things should run separately: the model decides intent, the gateway validates the action, the tool changes the environment, and sensors observe the result. The model can propose an action; the gateway decides whether that action is worth executing.

The model does not get to decide that something is done

When an agent says "done," that is not evidence. It is just another model output.

Completion must be determined by observable changes in the environment. The evidence that "the bug is fixed" is that the failing test turns green. The evidence that "the page works" is that the browser flow runs through. Questions that can be answered by compilers, schemas, checksums, queries, and tests should not be thrown at another model. Models handle ambiguity; code lays the pipes. The model can propose that a task is complete; only the environment can prove it.

Verification should attack the result

The worker and the evaluator should not share the same goal. The worker tries to make the solution as strong as possible; the evaluator tries to find reasons it should be rejected.

If you ask the same agent in the same context to "check it again," it will usually preserve the assumptions that caused the error. A useful verification phase is an organized attempt at falsification. It is not a second opinion; it is an attempted rebuttal.

Classify failures first, then decide what to do

The most common recovery strategy is "it failed, try again." That is not recovery; it is repetition.

Timeouts need backoff and retry. Wrong parameters need the tool call fixed. Missing context needs precise source retrieval. Failed tests need the failure behavior inspected. Permission denied means either request approval or take a safe path. Contradictory requirements mean escalate to a human. If the same failure appears unchanged more than twice, stop.

A retry should at least change one relevant condition; otherwise you are paying to reproduce the same failure.

When rules repeat, push them downward

"Remember to run the formatter." "Don't reference across layers." "Don't hand-edit generated files."

Putting these in the prompt relies on the model's memory. That's unreliable. If a rule keeps appearing, move it down from instructions: instructions, checklists, templates, automated checks, enforced policies. The further down it goes, the more reliable it becomes. Prompts explain judgment; harnesses enforce invariants.

Harnesses also rot

More harness is not necessarily better. Models get stronger, tasks change, and patches added yesterday to work around model flaws become friction that slows the system down today.

Every router, evaluator, memory layer, and retry rule should be asked: What failure does it prevent? Is that failure still common? How much latency and complexity does it add? What happens if we delete it? The best harness is often the smallest one—small enough to reliably close the chain from intent to evidence, and that's enough.

Start with the smallest layer

You don't need to start with a multi-agent orchestration platform. Build by layers.

Layer one: a bounded, acceptance-testable task. Layer two: an understandable environment with a map, commands, and local instructions. Layer three: controlled tools with parameter validation, permission boundaries, and structured returns. Layer four: durable execution with state, checkpoints, and decision records. Layer five: evidence, with deterministic checks, adversarial verification, and change receipts. Layer six: recovery and learning, with failure classification, bounded retries, and escalation mechanisms.

First build the layer that eliminates the real failures you are facing right now. Don't adopt a multi-agent architecture just because a prompt occasionally needs clarification. Complexity should be earned by observed failures.

Back to Karpathy's line. He says that you, building agents now, are at the front. Not OpenAI, not DeepMind—you.

But being at the front doesn't mean continuing to add adjectives to the prompt. The thing at the front is building the model an environment that keeps it from falling apart.

When the agent fails again, don't rush to change the prompt. Look at the system around it—maybe it was never built at all.