The Shift from Orchestration to Configuration

Traditional agent development has historically relied on complex Python loops, manual JSON schema definitions for tools, and custom error handling. This approach is brittle and requires significant maintenance. Philipp Schmid argues that as models become more capable, the developer's role should shift from micromanaging execution paths to defining high-level instructions and capabilities.

By moving orchestration, session state, and tool routing to the server side (via hosted sandboxes and unified APIs like the Gemini Interactions API), developers can replace thousands of lines of boilerplate code with simple markdown files. In this paradigm, an agent's behavior is defined by system instructions and skill files rather than hard-coded logic.

The Power of General-Purpose Tools

Instead of creating rigid, task-specific tools (e.g., a specific function to fetch a PR diff), developers should provide agents with general-purpose, atomic tools—such as a bash shell, a filesystem, and a CLI (like the GitHub CLI). When an agent is given access to these broader capabilities within an isolated, secure sandbox, it can reason through how to achieve a goal, such as installing dependencies on the fly or searching the web for information it wasn't explicitly programmed to handle. This reduces the need to anticipate every possible user request or tool requirement during the development phase.

The "Build to Delete" Heuristic

Schmid highlights a trend where leading engineering teams are aggressively simplifying their agent harnesses. He cites examples like Cursor replacing 12,000 lines of TypeScript with 200 lines of markdown, and Vercel removing 80% of their tools to improve accuracy and speed.

His core heuristic for builders is: If your agent harness becomes more complex as models improve, you are likely overengineering. The goal should be to own only the domain-specific logic—instructions, rules, and evaluations—while offloading the infrastructure to the platform. If you find yourself constantly refactoring your orchestration layer, you are likely fighting the model's inherent reasoning capabilities rather than enabling them.