Google DeepMind’s Philipp Schmid says agent builders should build to delete

The next useful leap in AI-agent engineering may be deleting code. Philipp Schmid, a Google DeepMind developer advocate, argues that teams should replace sprawling orchestration loops with instruction files, skills, general-purpose tools and hosted environments. The payoff is a simpler system that can adapt as models improve, rather than a larger contraption that needs rebuilding every few months.

Watch Desk analysis

What happened

In a presentation reconstructed by the supplied podcast account, Schmid demonstrated the same GitHub pull-request reviewer built three ways. The early versions depended on developer-owned Python loops, tool schemas and fixed capabilities. The final version gave the agent a hosted Linux sandbox, markdown instructions and general tools, allowing it to discover and install the GitHub CLI before completing the task.

The argument is closely tied to Google’s Interactions API and Agents API. Schmid described an architecture with server-side state, background execution and a flat timeline of typed steps such as reasoning, tool calls and tool results. Developers define the instructions, skills, environment and evaluations; the service manages the loop, routing, context and compaction. The supplied presentation account attributes these claims to Schmid and describes three live demonstrations.

Key findings

• Delete the harness
  Schmid’s test is simple: if your orchestration grows as models improve, the architecture may be fighting the model.
• Give agents broader tools
  General-purpose tools let an agent explore and solve tasks beyond a fixed menu, but they also create less predictable failure modes.
• Move state server-side
  The described steps timeline separates reasoning, calls and results more cleanly than a chat-shaped history.
• Keep ownership of evals
  Instructions and infrastructure can be delegated; checking whether the agent actually did the right thing cannot.
• Treat the sandbox as a boundary
  Credential-injecting proxies and domain restrictions reduce exposure, but the account says unrestricted domain access is the default.

Why it matters

This is a practical change in where agent complexity lives. Instead of writing a new function and schema for every capability, a team could add a skill file or make a command available in the environment. That makes experimentation cheaper and lets stronger models remove scaffolding rather than demanding another framework layer.

It also moves risk. An agent that can explore a sandbox and choose general tools may escape the old “tool unavailable” failure, but it can make a wrong choice with more confidence. Credential protection and network policy therefore matter as much as the prompt, and the presentation leaves evaluations firmly on the developer’s desk.

Our read

Schmid’s “build to delete” rule is a sharp architectural heuristic, not a universal law. Try it on one bounded workflow: measure how much code disappears, whether failures become easier to diagnose and whether the evals catch bad tool choices. If the answer is no, the cleverer model has not yet earned the smaller harness.

What to watch

• Whether Google’s agent APIs publish concrete limits and controls for sandboxed execution.
• How reliably file-based skills work across models, tasks and hostile inputs.
• Whether credential proxies prevent exfiltration through permitted domains.
• Whether simpler harnesses improve real-world reliability, not just demo elegance.

Discussion spark: When should an agent be trusted with general-purpose tools and a sandbox, and which evaluation would you require before removing bespoke orchestration?

Watch Desk is operated by WittyWires as an independent cross-cutting AI news tracker. It does not speak for the organisations or people it covers.