Evolving Claude APIs for Agents

What does an LLM API need to expose so developers can build a capable coding agent? Katelyn Lesse, who leads Anthropic’s Claude Developer Platform team, frames the problem around developers pushing for the best performance available from Claude. Her recurring example is Claude Code: an agentic coding product that puts those platform capabilities to work.

The platform has three responsibilities. First, expose the capabilities the model is being trained to use. Second, help applications keep the right information in its context window. Third, provide the infrastructure that lets the model use a computer. Agent performance depends on the model’s abilities, the context available to it, and the environment in which it can act.

The first capability is thinking. Lesse describes performance on various tasks as improving with the time Claude spends reasoning through them. An API therefore needs to let the application choose between a quick response and a longer deliberation, rather than imposing the same reasoning effort on every request.

In the API design described here, a thinking token budget gives developers control over how much reasoning to allocate. Claude Code uses that control because complex debugging and a quick coding answer have different needs. The historical manual-budget mechanism remains documented in extended thinking, alongside newer, model-dependent adaptive-thinking configurations; it is not an unchanged contract across every model. The application-level decision remains useful: spend more reasoning where the task warrants it.

Tool use turns model decisions into requests for action. The API exposes built-in tools, such as web search, and lets developers define custom tools. A custom definition supplies a name, a description, and an input schema. These tell Claude what the tool does and what arguments it accepts, so the model can decide when to call it.

A test-running tool illustrates the shape of that contract. The description explains when it is useful; the schema makes the requested input explicit:

{
  "name": "run_tests",
  "description": "Run the test suite for a file or directory after a code change.",
  "input_schema": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string",
        "description": "The test file or directory to run."
      }
    },
    "required": ["path"],
    "additionalProperties": false
  }
}

This definition describes the callable operation; the application supplies its implementation. The slide places a custom run_tests tool alongside bash and a text editor.

Claude Code uses tools throughout a coding session: reading files, searching for files, writing changes, and rerunning tests. Reasoning controls influence how the model works through the problem; tools give it access to the operations needed to investigate and change the codebase.

Once an agent can call tools, selecting its context becomes a continuing engineering problem. A coding session may contain technical designs, code, instructions, and tool calls. Each can be useful, but their usefulness changes as the work progresses. The objective is the right context at the right time, not simply accumulating everything the agent has encountered.

Model Context Protocol, or MCP, standardizes how agents interact with external systems. Lesse describes its introduction as roughly a year before the talk. For Claude Code, GitHub and Sentry are examples of places containing information or tools beyond the agent’s immediate context. Connecting to those systems gives the agent a way to obtain relevant material instead of being limited to what someone placed in its prompt.

External access helps bring information in. Memory lets the agent retain information outside the active window and retrieve it when needed. The first memory-tool iteration Lesse describes is a client-side file system: the developer controls the data, while Claude decides what is worth saving and when to bring it back into context.

Codebase patterns and Git workflow preferences are useful examples. They can matter across multiple tasks without needing to occupy the window throughout every task. Storing them separately makes them available for later use while allowing active context to focus on the current work.

Memory keeps information available outside the window; context editing removes information that no longer belongs inside it. The initial editing feature clears old tool results. Those results can be large, and material returned earlier in a session may contribute little to the next response. A coding agent that calls hundreds of tools can otherwise fill its context with previously read files and other accumulated output.

Lesse reports a 39% performance improvement from combining memory and context editing on Anthropic’s internal evaluations. The accompanying context-management announcement identifies the evaluation as agentic search involving complex multistep tasks. It does not provide the numerical baseline, exact scoring definition, sample size, or an explicit relative-versus-absolute definition, so the result should not be read as a measured coding-productivity gain.

Larger windows complement this editing process. Lesse notes that some models offer million-token context windows; a historical example is the million-token API beta for Claude Sonnet 4, which initially had access restrictions. More capacity provides room for work, while editing controls what occupies that room. The context-editing diagram makes the immediate effect visible: removing old results creates available context.

The next layer is capacity awareness. Lesse describes work on teaching Claude to recognize whether it has substantial room remaining or is approaching the end of its window, and to adjust its behavior accordingly. Context management then involves both choosing the contents and understanding the space left to continue.

Giving Claude a computer changes the question around agent harnesses. Developers debate how much scaffolding to build and how opinionated it should be. Lesse’s position is that a model able to write code gains much broader practical reach when it can also run that code. Producing professional outputs then depends on providing both the execution infrastructure and the expertise needed to use it well.

The launch of Claude Code on the web, which also included an iOS preview, makes the infrastructure requirement concrete. Local Claude Code uses the developer’s machine. When someone starts a web or mobile session and walks away, the work needs another computer on which to continue.

That remote environment has three requirements:

• Secure execution: It must accommodate generated code that the user has not necessarily approved individually.
• Container orchestration: It must support many concurrent sessions at scale.
• Session persistence: Work and results must remain available when users return.

The operational challenge is not merely starting a process. It is keeping many independent coding sessions ready for their users after unattended work.

The API’s code execution tool provides a primitive for this kind of work: Claude can write code and run it in a secure sandbox on Anthropic’s servers. The platform handles the containers and their security, reducing the execution infrastructure the application developer must operate.

Lesse’s example is a request to make an animation more sparkly. An agent benefits from being able to run the code it changes, rather than stopping at generated source. This is the direction she advocates for agents: allow the model to work with substantial autonomy inside a sandbox, with the platform supplying the environment that makes that work possible.

Execution becomes more useful when the model also has domain expertise. Agent Skills package scripts, instructions, and resources into folders that Claude can access while working in its sandbox. The request and the skill’s description guide whether Claude loads the skill into context and uses its contents. Skills can be combined with the code execution tool.

Skills also complement MCP. Their roles are distinct:

Access to a system gives the agent something to work with. A skill supplies the procedures and knowledge for doing that work appropriately.

Consider a team that regularly builds landing pages for product launches. It wants each page to follow its design system and established patterns. A landing-page request is a reason for Claude to load the web-design skill and apply those conventions. The slide’s web-design-system example pairs that skill with a landing-page request and code execution: the skill provides the design guidance, and the execution environment supports the implementation work.

For a deeper treatment, Lesse points attendees to Barry and Mahesh’s skills talk scheduled for the following day.

The platform roadmap follows the model’s development. As Claude acquires new capabilities and improves existing ones, the API needs to expose them so developers can put them to use. For memory and context, Lesse describes a move toward giving Claude more control over what it retrieves, stores for later, and clears from its window.

That direction also requires continued investment in orchestration, secure environments, and sandboxing. Giving an agent a computer creates an infrastructure obligation: the environment must support the work the model can increasingly perform. Lesse closes by inviting people interested in building these developer products to join Anthropic, across engineering, product, design, DevRel, and other functions.