Building agents that can find, fix, and verify their work

From patrolling buildings to working in repositories

A security robot patrolling an office or warehouse has to notice anomalies and call for help. Before joining Anthropic, Erik Schluntz co-founded Cobalt Robotics and served as CTO, building roughly five-foot-tall inspection robots that called remote operators when needed. He described about 100 deployed robots and a team of similar size.

His move toward language models began with Copilot writing substantial amounts of his code. AI had become useful in his own engineering work. After a sabbatical studying language models, he joined Anthropic, drawn by trusted colleagues, cultural fit, and concern about AI safety. At the time of the November 2024 Latent Space interview, he worked on tool use, computer use, and SWE-bench.

On Anthropic’s Product Research team, Schluntz focused on capabilities customers needed. He initially worked on function calling and tool use; demand from startups building coding agents later drew him toward repository-level software work. He helped implement SWE-bench and build a reference agent. Anthropic’s SWE-bench write-up published the agent’s tools and prompt so developers could reuse the approach.

SWE-bench tests changes inside an existing system

SWE-bench evaluates an agent’s ability to make software changes inside existing repositories. It adds a dimension isolated coding puzzles largely omit: locating relevant files and understanding how a patch interacts with the surrounding system. Its coverage is narrow—12 popular open-source Python repositories, with tasks selected around existing passing tests and new tests for the requested behavior—but Schluntz valued their origin in real engineering work.

That realism costs time and tokens. An attempt may read substantial repository context, write code, run it, and revise it repeatedly. Schluntz therefore favored retaining varied evaluations: generating code from scratch still matters, and quick HumanEval-style coding tests provide a cheaper signal than a full agent run.

A task completed by a human is not necessarily solvable from the description available to an agent. A test might require an exact error-message string without specifying that wording in the issue. SWE-bench Verified used human review, in partnership with OpenAI, to filter out obstacles of this kind. Reviewers also estimated completion time, from under 15 minutes to more than four hours. The aim was solvability, while some ambiguity remained.

Two failures show what remained difficult. The agent could choose the wrong level of abstraction, adding a local patch where a broader refactor was needed. It could also miss an essential verification step. The evaluated agent had no interface for visual inputs; in some matplotlib traces, it ran a script that saved an image and declared success without inspecting it. Visual capability cannot help when the agent never receives the image.

One proposed diagnostic was to combine all tasks solved by any attempt across submissions, then inspect the remaining problems among Verified’s 500 tasks. That analysis could help separate persistent capability failures from inadequate descriptions. It had not yet been performed; reaching roughly 90–92% was an aspiration. Correlations between estimated human difficulty, token use, runtime, and success were also unmeasured.

Match the instructions to the work

More detailed instructions did not help every task equally. A coworker named Simon developed a prompt for problems estimated to take humans more than four hours. It scored better on that hardest subset but worse overall than a simpler prompt. The reported effect was small; no numerical comparison was given.

The proposed explanation was overengineering. A crash caused by None may need only a guard check, while elaborate instructions can encourage unnecessary architectural work. This suggests routing distinct tasks to distinct prompts: solving a difficult programming problem and writing a quick test for existing code need different guidance. Separate prompts can stay smaller and be changed independently.

A host proposed meta-prompting—asking the model to generate task-appropriate instructions—and recommended Anthropic Workbench from personal experience. The response endorsed Claude’s ability to write prompts for itself, without a benchmark result for this approach. A broader heuristic was to ask how much instruction a human would need for the same work: expertise reduces the need for scaffolding, but does not make checklists useless.

Output completeness is a separate concern. Choosing an insufficient fix differs from abbreviating unchanged code in an answer. Make the requested output explicit: complete code or only the relevant changes.

A minimal loop, with carefully designed tools

The reference agent used a minimal control loop: give Claude tools, let it choose an approach, and continue reasoning and calling tools until it considers the task complete. The updated Claude 3.5 Sonnet was described as better at recovering from failed approaches than earlier models. That reduced the need for external systems to detect repetition and force a change of direction.

Failed attempts stayed in context—the history available to the model—at a substantial token cost. Pruning unsuccessful paths was unnecessary for good performance on these benchmarks, but remained a possible way to fit longer tasks into the 200K-token context window.

Agentic search applied the same principle to file discovery: the model chose what to inspect, read the results, and decided whether to continue searching. It listed directories and viewed files until it found a likely bug location, without a code indexer selecting context in advance. The file tool’s directory-view operation limited listings to two levels deep to avoid overwhelming output.

Many SWE-bench issues supplied a helpful starting point: a stack trace pointing toward relevant code. Feature requests may offer no such clue, and iterative search takes many tool turns and tokens. For a product that must answer in one turn, the recommendation was retrieval-augmented generation: retrieve relevant material first and place it in the initial prompt.

The team spent more engineering effort on tools than on the overall prompt. Its editing tool used string replacement: the model supplied existing text and its replacement, and the tool swapped them. Experiments also covered generated diffs and full-file regeneration. String replacement was described as the most reliable approach; full-file regeneration was separately described as the most accurate, but prohibitively expensive for large files. No quantitative comparison was supplied.

An agent computer interface—the tools and representations through which a model acts—deserves the design attention given to human interfaces. Representing the same edit differently can change how easily the model produces a valid action. Tool descriptions should explain behavior and include common examples, so a first-time user can understand how to use them without reconstructing usage from a bare schema or a long list of flags.

Verification and clarification belong in the workflow

The released tools supported general terminal work through bash and file editing, without a benchmark-specific run-tests operation. The Computer Use demo extended that foundation with a tool for screenshots and mouse and keyboard control.

SWE-bench’s grading tests were hidden from the agent to prevent it from tailoring a solution directly to them. A typical run instead wrote a small script to reproduce the reported error and reran it after editing. That provided local feedback, but fixing the reproduction did not rule out regressions: the agent could repair one behavior while breaking another test it had not checked.

Ordinary development also involves follow-up questions and outside information. Pretrained knowledge may reduce a model’s need to search, but newer software and external context still matter. For a practical coding agent, the recommendation was to clarify an underspecified request immediately, before spending hours implementing the wrong thing.

TAU-bench provides an interactive evaluation pattern: one large language model plays a customer and another a support agent, and they converse to resolve an issue. A proposed coding equivalent would allow clarification exchanges before implementation, with safeguards against revealing the solution.

Replit’s plan-and-approval flow illustrated a shorter feedback loop: a person can revise the proposed approach before reviewing a completed implementation. Planning was argued to improve downstream reasoning and make the result easier to audit, though no quantitative evaluation was offered.

Make mistakes harder and execution easier to inspect

Multiple agents can use the same model with different prompts and priorities. Such personas were suggested as an aid to thorough planning, based on limited firsthand exploration and reports from others. They also add calls, tokens, and complexity—overhead that is harder to justify for a request to write one function.

Output formatting is another interface choice. Descriptive XML-style opening and closing tags can make content boundaries explicit. One argument for wrapping code in a tag was to reduce the escaping required by JSON strings. The claimed performance benefit was qualitative, and possible complications with HTML inside XML had not been tested.

Poka-yoke, or mistake-proofing, gives tool iteration a concrete method: inspect execution traces, find recurring misunderstandings, and change the interface to prevent them. Two reported failures illustrate the approach: - Relative-path confusion: changing directories caused the model to supply paths that did not match the file tool’s location. Requiring absolute paths reportedly eliminated that failure. - Interactive commands in a noninteractive tool: launching Vim stalled a text-in, text-out connection. The tool description was updated to discourage commands that would not return and explain background execution with & when needed.

SWE-Agent provided a starting framework because of its shared authorship with SWE-bench, implementation quality, and ease of modification. The adapted agent retained think–act–observe labels in its logs because the printing code was unchanged. Underneath, it used function calls and allowed consecutive calls without an intervening thinking step.

Framework convenience can encourage unnecessary architecture: a task needing one prompt can become a five-agent conversation because that is easy to instantiate. Abstractions can also hide the prompts and outputs needed for debugging. The recommended starting point was small utility functions, such as a wrapper centralizing model-call defaults, while keeping execution visible. Shared tools can help, but end applications were expected to need bespoke tools.

Longer runs need memory

The agent runs had no effective turn cap before exhausting the 200K-token context window. Some failures exceeded 100 turns, and successful runs were recalled as exceeding 100 too, without an exact maximum. Difficult engineering work can require many reads, edits, and retries; the benefit of allowing thousands of turns remained unknown.

One proposed memory strategy was to roll back unsuccessful paths while keeping summaries of what failed. Total token consumption could then exceed 200K without any single context exceeding that limit. The challenge is preserving what the agent learned: removing an unsuccessful attempt saves space, but losing its lessons can lead to repeated mistakes.

Model specialization offered another possible efficiency gain. Claude 3.5 Haiku could read a 10,000-line file and extract relevant functions for Sonnet. The proposed 90% token saving was illustrative, and the combination had not been tested. Haiku’s own SWE-bench performance encouraged the view that smaller models could handle agentic reasoning, but did not establish the effectiveness of this pipeline.

The team’s intended handoff was to application builders: demonstrate a minimal working agent, release the tools, and let the ecosystem develop richer systems. The larger product question was where benchmark improvements diverged from what paying customers needed.

Computer use lowers the cost of integration

An early computer-use experiment installed and opened Minecraft after a request to play it—a successful setup and launch, without a claim of successful gameplay. The capability was still in beta. Its practical appeal was reducing the engineering work required to connect an agent to existing software.

Cobalt’s elevators made the tradeoff tangible. Integrating with a new elevator vendor’s API reportedly took roughly six months. Installing the required hardware on a particular elevator could sometimes take another six months. A small robotic arm guided by computer vision could instead press the existing buttons and be deployed in a day. It operated more slowly and less reliably, sometimes retrying missed presses, but removed a deployment bottleneck.

For software agents, the corresponding choice is a bespoke API integration or operation through an existing interface. A hypothetical support team could give an agent a browser already logged into its systems, reducing the initial integration work. The proposed division of labor was APIs for high-volume workflows, computer use for the long tail: prototype through the interface, confirm adoption, then build an API path for faster execution and lower token use.

Predictable workflows might eventually avoid repeated model calls altogether. Proposed paths included having an agent discover an API, generate a robotic process automation script—a script for a repeatable sequence of actions—or turn its computer-use actions into a saved script. These were development ideas, not demonstrated capabilities.

The launch included a Dockerized environment with its own browser. This separate workspace constrained the agent’s access and let the user keep working without surrendering their screen and input devices. The preferred experience resembled pair programming with two laptops: give the agent its own desktop and check progress periodically.

For coding agents, a consequential application was closing the visual verification loop: build a frontend, operate it, and inspect the result. Examples of agents testing their own frontends were already being observed. Computer use could also support exploration—using vision, web searches, and outside material while working through a problem.

Robotics exposes the gap between demos and dependable systems

The closing robotics assessment was explicitly personal opinion from a self-described burned-out founder, rather than Anthropic’s position. It identified two promising advances: language models could reduce the burden of specifying tasks, and learned motion control could reduce the need to program movements explicitly.

A request to make a Reuben sandwich illustrates the task-specification benefit: a language model brings recipe knowledge that engineers previously would have had to encode. For motion, diffusion-inspired control learns from demonstrations, with text instructions allowing one model to learn multiple tasks. The account credited Toyota Research and named Physical Intelligence among startups pursuing this direction, while qualifying that the methods may borrow diffusion’s ideas rather than use diffusion models directly.

Learning to pick up cups and books, then handling an unseen backpack, remained an aspiration. A more immediate product goal was reliable performance on a bounded set of useful tasks. That still requires generalization within a task, such as picking up an unfamiliar coffee mug.

Reliability was the central concern. A hypothetical robot that breaks one in every 100 dishes is 99% successful and still undesirable. Dropped warehouse boxes and misplaced automotive welds make the same point: acceptable error rates depend on the consequences. The comparison to self-driving cars emphasized how many years can separate impressive demonstrations from dependable deployment across edge cases.

Hardware adds another source of variance. Nominally identical robots and motors can behave differently, so scaling requires repeatedly manufacturing reliable units. At Cobalt, thermal cameras began failing without an identified software or hardware-design change. The investigation eventually uncovered a procurement switch to nominally equivalent USB cables costing a dollar less. The replacement cables reportedly caused intermittent failures requiring substantial reboots; resistance and electromagnetic interference were possible causes, without a settled diagnosis.

That incident informed the speaker’s advice against USB for highly reliable unattended robotics: recovery that assumes someone can unplug and reconnect a device becomes costly when nobody is nearby. Software agents’ ability to be cloned offered an attractive contrast to manufacturing physical copies with variable components.

The economic concern was equally concrete. Expensive robots sold as one-for-one labor replacements face a ceiling on what customers will pay. For autonomous vehicles, eventual profitability also differs from recovering upfront investment after vehicle costs and depreciation. The skepticism about Waymo focused on profit per car and the time needed to recover capital, with an explicit acknowledgment of no access to its financials.

The final constraint returns to software: can the user trust five hours of agent work? Completing a task creates value only if the person can assess the result. Useful agents must make their work auditable and explain what they did, why, and how they reached their conclusions.