---
type: "post"
id: "why-agents-are-soon-only-going-to-have-fbd158"
slug: "why-agents-are-soon-only-going-to-have-fbd158"
title: "Why Agents Are Soon Only Going to Have 1 Tool"
description: "Phil Schmid argues that agents may work more effectively with one exec(code) tool than with a long catalog of individual tool definitions."
retrieval_nugget: "Phil Schmid argues that agents may work more effectively with one exec(code) tool than with a long catalog of individual tool definitions. In this design, the model writes a short script that chains typed calls inside a sandbox, potentially reducing round trips and context growth. The key question for builders is where orchestration, state and policy enforcement should live."
published_at: "2026-11-03"
updated_at: "2026-11-06"
record_date: "2026-11-03"
date_kind: "published_at"
topics: ["mcp"]
entities: ["Phil Schmid","Model Context Protocol"]
related_patterns: ["harness-architecture-outlives-model-choice","agent-protocols-become-interoperability-layer"]
novelty_label: "new_angle"
what_changed: "Argues that increasingly complex agent workflows are pushing tool design toward a single code-execution interface, rather than merely describing multi-tool agent work."
prior_refs: []
source_url: "https://www.philschmid.de/code-mode"
source_urls: ["https://www.philschmid.de/code-mode"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:why-agents-are-soon-only-going-to-have-fbd158"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/why-agents-are-soon-only-going-to-have-fbd158/","markdown":"https://newruntime.com/posts/why-agents-are-soon-only-going-to-have-fbd158.md","json":"https://newruntime.com/posts/why-agents-are-soon-only-going-to-have-fbd158.json"}
markdown_url: "https://newruntime.com/posts/why-agents-are-soon-only-going-to-have-fbd158.md"
---

# Why Agents Are Soon Only Going to Have 1 Tool

## Retrieval answer

Phil Schmid argues that agents may work more effectively with one exec(code) tool than with a long catalog of individual tool definitions. In this design, the model writes a short script that chains typed calls inside a sandbox, potentially reducing round trips and context growth. The key question for builders is where orchestration, state and policy enforcement should live.

## Summary
Phil Schmid argues that agents may work more effectively with one `exec(code)` tool than with a long catalog of individual tool definitions. In this design, the model writes a short script that chains typed calls inside a sandbox, potentially reducing round trips and context growth. The key question for builders is where orchestration, state and policy enforcement should live.

## What happened
In a post dated November 1, 2026, Phil Schmid describes a shift from agents selecting and invoking one tool at a time toward “Code Mode,” also called programmatic tool calling. Rather than exposing dozens of JSON Schema tool objects directly to a model API, a harness can expose a single `exec(code)` surface. The model writes TypeScript or Python that calls underlying tools, combines their results and decides what output to return. The article presents this as an emerging design direction, not as a universally adopted standard or a release announcement.

The proposed flow compiles tool schemas into compact type declarations available to the model. A script can call functions such as `tools.linear.listProjects()` and then use returned project identifiers to request issues. It can filter those results and invoke another action without sending each intermediate result back through a separate model turn. Schmid’s example archives unassigned issues across projects and returns a one-line summary. He also describes searching sources, reading and filtering results in a script; coordinating multi-file edits and verification; scripting browser interactions; and running parallel lookups or specialist-model calls before making a subsequent API call.

This design does not mean the underlying tools disappear. The model-facing interface is consolidated, while the sandbox still needs access to service methods. Schmid says MCP servers increasingly provide `outputSchema` as well as `inputSchema`, giving the model advance information about result types that can support chaining. For very large catalogs, the harness could avoid exposing every namespace up front and instead provide a searchable tool map. The article also describes helpers for returning text, images or audio to the model and for keeping values in host memory across turns.

Schmid contrasts a JavaScript or Python runtime with shell-based orchestration. Typed functions and native objects avoid some fragile string handling; an agent need not explore custom command-line flags before acting; and media can be passed back through dedicated helpers rather than treated as ordinary text output. A structured bridge to the host can also inject OAuth credentials, validate schemas or pause for confirmation on destructive calls. The source does not specify a particular sandbox implementation, a commercial product, pricing, or measured performance and cost results.

## What the archive adds
An earlier Telegram post on November 5, 2025 described building agents that execute code to interact with MCP servers more efficiently. That is a genuine antecedent: the new article makes the model-facing consolidation into a single `exec` surface and its proposed runtime responsibilities more explicit. The archive also has [Cloud execution is coming to Antigravity soon Google will retire Jules on Dec.](https://newruntime.com/posts/cloud-execution-is-coming-to-antigravity-soon-google-814edc/), but that story concerns remote execution workflows, not this particular tool-interface design. This is a new articulation of a known code-execution idea, rather than evidence of a newly launched capability.

## Trend signal
The proposal supports [Harness architecture outlives model choice](https://newruntime.com/patterns/harness-architecture-outlives-model-choice/): the harness, not the individual tool list, becomes the durable boundary that compiles interfaces, runs scripts and controls access. It also touches [Agent protocols become the interoperability layer](https://newruntime.com/patterns/agent-protocols-become-interoperability-layer/), since typed MCP methods are presented as callable capabilities behind that boundary. The article is an architectural argument, not evidence that the industry has already converged on one interface.

## Why now
Schmid attributes the timing to two developments: models have become more reliable at combining and chaining actions in code, and MCP servers increasingly expose output schemas. Together, these make it more plausible for a model to compose dependent calls before seeing every runtime result. The source offers this explanation but no adoption data or dated rollout schedule.

## Connections to other events
The earlier Telegram post on code execution with MCP described using code to interact with servers efficiently. Schmid’s account connects that practice to a broader harness design: code execution becomes the single surface exposed to the model, while individual service calls remain behind it. The connection is conceptual; the article does not report that MCP itself has adopted or standardized this model-facing arrangement.

## Why it matters
A large tool catalog creates a choice problem for the model and consumes space in its available context. Code Mode moves some of that work into a runtime: the model can write a small program to choose calls, pass data between them, branch on results and return a compact answer. For teams, that suggests a way to design workflows in which intermediate data stays outside the prompt and dependent actions do not require a model round trip each time.

The consolidation also concentrates responsibility. A single execution tool is only useful if the harness can constrain what code may do, control credentials, validate inputs and outputs, preserve useful state, and require confirmation where appropriate. A smaller surface for the model is not automatically a safer system. Teams should evaluate the execution boundary and its policy controls alongside the convenience of composing calls in code. The article explains possible advantages but does not establish that those advantages outweigh implementation and security costs in production.

## Limits and uncertainty
The post is a practitioner’s argument and design description, not a controlled comparison. It supplies no benchmark for latency, token use, reliability, or cost against conventional tool calling. The illustrative script and workflow examples do not establish that models will consistently write correct orchestration code or that every tool is suitable for this pattern. The source also leaves important operational details open: sandbox isolation, resource limits, error recovery, audit trails, and how permissions should be scoped. Its references to improving model reliability and growing MCP schema support are qualitative; no model versions, provider adoption figures, or rollout commitments are given.

## Skill to build now
Take one workflow that currently requires several dependent tool calls. Sketch it as a small TypeScript or Python function: list its inputs, the typed results passed between steps, where it branches or runs calls in parallel, and what minimal output returns to the model. Then mark every operation that needs credentials, user confirmation, or a read/write restriction. This turns the article’s proposal into a reviewable design exercise without assuming a production sandbox is already in place.

## Reader takeaway
“One tool” describes what the model sees, not what the system contains. Code execution can let an agent orchestrate many capabilities with fewer conversational round trips, but that shifts complexity into the harness. For builders, the useful question is not simply whether to collapse tools; it is whether the runtime can make composition typed, bounded and auditable.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Mcp](https://newruntime.com/topics/mcp.md): Explore the mcp topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)