Agent II: If the Model Can Use Tools, Why Does It Still Fail?

“The change is complete. The command succeeded.”

A coding agent found the file, applied a patch, and received exit code 0 from the terminal. It called the right tool, supplied valid parameters, and even produced syntactically valid code. But when you open the page, stale data is still sitting in the cache. When you inspect the working tree, you discover that it also overwrote one of your uncommitted changes.

The agent was not entirely incapable of writing code. On the contrary, this failure occurred in a model that appeared capable enough: it could reason, use a terminal, edit files, and explain its changes. What it did not know was the initial state of the working tree, the project’s requirement to invalidate the cache after a write, or an acceptance result capable of disproving its claim that the work was done.

As models become more capable, the center of agent failure quietly shifts. Early work repeatedly asked how to make a model follow instructions, select tools, and supply valid arguments. As post-training turns more of those interaction patterns into relatively stable capabilities, the largest gap is no longer always “Can the model do this?” It becomes:

Is the model acting on a task state that is real, current, and verifiable?

This is the second essay in the Agent series. The previous essay explored how a prompt selects a working mode from the behavioral possibilities created during training. But a prompt can only prescribe how the model should process information. It cannot restore facts that never entered the input, nor can it let the model directly see the outside world. Once the behavioral entry point is open, the next problem is keeping the right information in control of every decision.

That is context engineering.

Using a tool is not the same as seeing the worksite

A language model does not stand inside your working tree.

Whether another person has changed a file, how many rows are currently in a database, what the last command actually changed, or whether a page truly satisfies the request all exist outside the model. The model sees only the portion that a runtime converts into text or structured objects and returns in a later call.

Tool use therefore moves in two directions:

• The model converts intent into an action and asks the environment to execute it.
• The environment converts what happened into an observation and returns it to the model for another decision.

When the second direction is missing, a tool becomes a hand the model can extend without bringing back any sense of touch. It can continue executing a plausible plan even after the environment has diverged from the assumptions in its head.

ReAct placed reasoning and actions into an interleaved trajectory: actions obtain new information from outside, and reasoning uses that information to update plans and handle exceptions. Its importance is not that it invented one mandatory format. It exposed the smallest loop required by a long-horizon task—the reality produced by one step must be able to change the next.

The question therefore expands from “What does the prompt say?” to “What exactly does the next model call get to see?”

Context is the complete state of one decision

When people discuss context, they often begin with the context window: how many tokens a model can accept. That definition describes the size of the container without describing what belongs inside it.

For a real agent call, context is closer to the model’s current task state:

• The objective describes the desired environment and the outcomes that are unacceptable.
• Knowledge supplies project rules, relevant facts, and existing conventions.
• Current state describes what the environment is now, not what it was when the task began.
• Available actions tell the model how it may explore or change the environment.
• Observations describe what just happened.
• Feedback judges how far the result remains from the objective.

Not all of this comes from the user’s first message. With every step, the environment changes, old judgments expire, and new evidence appears. Context engineering is therefore not the act of writing an enormous preamble before work begins. It is the maintenance of a changing cognitive worksite throughout the action process.

The model and objective in the figure never change. Remove “Required knowledge,” and the next action falls back to reading the project rules. Remove “Current state,” and the model must inspect the working tree. Remove compaction, and the important result disappears back into raw logs. Remove verification feedback, and the model loses the evidence needed to decide that the task is complete.

Context does not change what the model is capable of. It changes what that capability can act upon in this invocation.

Context engineering addresses four different gaps

Reducing context engineering to “give the model more information” collapses several distinct problems into one. Too little information can cause failure, but so can information that is excessive, stale, or impossible to verify. A more useful model separates four directions.

Can the required knowledge arrive?

The model does not need to remember an entire codebase in every turn, but it must be able to find project conventions, interface definitions, and relevant implementations when they matter. This is an availability problem. Retrieval, file indexes, search tools, and targeted reads all build paths from a question to the facts that can answer it.

“Let the model know more” does not mean preloading every document into the window. Much knowledge only needs to remain retrievable. Letting the model see filenames, directories, and summaries before deciding which body to read often resembles real work more closely than loading everything at once.

Can task state persist?

A long task can span dozens of tool calls and outgrow a single context window. The model must retain what has already happened, which judgments still hold, and what remains unresolved. A longer window adds capacity; external notes, staged state, and compacted summaries allow critical state to survive across windows.

Capacity answers “Can this be retained?” It does not guarantee “Can this be used well?”

Can useful signal outrank noise?

Ten thousand lines of logs may contain more information than a ten-line summary while supporting a worse next decision. Repeated progress output, obsolete file versions, rejected error paths, and stale plans all compete for attention.

Lost in the Middle found that even models built to accept long inputs can use relevant information very differently depending on where it appears in that input. A long window is not a hard boundary that works perfectly until it is crossed. Position, conflict, and noise can reduce precision well before the limit.

Compaction is therefore not merely a way to save tokens. It increases the share of the context occupied by information capable of changing a decision. Anthropic’s account of context engineering for agents similarly frames the goal as retaining the smallest high-signal set within a finite attention budget, using progressive disclosure, tool-result clearing, and staged summaries to sustain long tasks.

Making tool responses more concise primarily improves this dimension.

Can action results revise the next decision in time?

The first three directions can still produce a static reference packet. Once an agent begins to work in an environment, a fourth property becomes necessary: new state must flow back, and the returning information must be able to change later actions.

This is not “remember more.” It is “keep the context fresh.” A file edit, browser click, or database write changes the environment. If the next turn still reasons from the state before that action, even an enormous context window is only preserving an obsolete world with great precision.

But returning environment state is not yet the same as feedback. One more distinction is necessary.

Tool success is an observation; satisfying the objective produces feedback

An exit code of 0, a changed file, or an HTTP 200 response describes something that happened in the environment. Each is an observation.

An observation does not by itself say whether the result is correct. A page returning 200 may show the wrong content. Code that compiles may break existing behavior. A successfully applied patch may fail to implement the request.

Feedback appears only when the system evaluates those observations against an objective, constraint, or completion criterion:

• “The file changed” is an observation.
• “The change preserved the user’s existing work” is feedback.
• “The test process ended” is an observation.
• “The cache invalidation case still fails” is feedback.
• “The page opens” is an observation.
• “The narrow layout has no horizontal overflow and the interaction remains usable” is feedback.

A concise tool response is therefore not inherently feedback. It can make an observation clearer while still reporting something irrelevant to the objective. Feedback requires a ruler: the model must first know what completion means, and an evaluation must place the current result against that ruler.

This is why “the tool succeeded” is not the same as “the task is complete.” A tool is responsible for executing one action. Task completion is a judgment about the resulting environment.

When feedback re-enters the context, it does not update the model’s weights. It updates the beliefs, plans, and action tendencies within the current task. A failed test leads the model to repair the code. Human rejection leads it to reinterpret the objective. Evidence that contradicts a hypothesis leads it to abandon that path. The capability did not grow in a few seconds, but a system with feedback and a system without it display very different effective capabilities.

Checkable environments turn correctness into the next input

Coding tasks are unusually compatible with today’s agents not only because training data contains a great deal of code, but also because software environments can speak.

Compilers can identify syntax and type errors. Tests map inputs to expected results. Static analyzers expose some rule violations. Version control shows exact changes. These mechanisms turn a vague sense that something is wrong into structured, local, and repeatable feedback.

The SWE-agent study showed that redesigning the computer interface through which a model browses, edits, and runs tests can substantially affect software-task performance without changing the underlying model. An interface does more than make a tool callable. It determines which results the model sees, how much irrelevant output it must carry, and whether it can recover from errors.

Test-driven development (TDD) is especially compatible with this setting. It did not arise because of agents, and it cannot guarantee that a test is correct. But obtaining a repeatable failure first, changing the implementation, and watching the test turn green naturally creates a short, explicit feedback loop. The model does not have to rely solely on its own prose judgment of correctness; the environment can repeatedly reject candidates that violate the encoded constraint.

Proof checkers such as Lean push this property further. DeepMind’s AlphaProof searched for proofs in Lean and used the formal system to check whether candidate proofs were valid. A language model can propose plausible-looking steps; the proof checker supplies a judgment independent of their fluency.

The boundary still matters. Tests only check requirements encoded in tests, and a formal system only proves a formalized proposition. If the acceptance criterion omits the real intent, a system can satisfy the wrong objective with great reliability. Verifiability answers “Does the result satisfy this ruler?” It cannot automatically answer “Is this the ruler we truly wanted?”

The transferable intuition is not that every task must be formalized. It is:

The more an environment exposes state as parseable observations and objectives as repeatable evaluations, the easier it becomes for model actions to form an effective loop.

Context engineering maintains the worksite; harness engineering maintains the loop

We can now return to the coding agent that declared victory too early.

A longer system prompt might remind it to “check carefully.” What actually changes the outcome is placing the project rules, working-tree state, compact tool result, and failed acceptance check into the right later calls. The former requests a behavior. The latter supplies the reality on which that behavior depends.

This gives context engineering a clear boundary:

• Retrieval makes required knowledge available.
• Long contexts and external state preserve continuity.
• Selection and compaction improve signal density.
• Observations and feedback let current judgment catch up with environmental change.

Prompt engineering designs an entry point into capability. Context engineering maintains the task site visible to the model. But once we ask who safely executes actions, collects observations, runs evaluations, persists state, compacts history, and guarantees that the right information returns on time, the problem has moved from “What should the model see?” to “What system can make this loop happen reliably?”

That will be the subject of the next essay: harness engineering.