Agents Without Code: Skills, YAML, and Filesystems Replaced Python — Philipp Schmid, Google DeepMind

A GitHub pull request reviewer needs to retrieve changes, inspect code, and decide what deserves attention. Philipp Schmid of Google DeepMind builds that same agent three ways, deleting implementation code between versions. The working definition is deliberately small: an agent runs tools in a loop until it achieves its goal. The experiment changes who implements that loop and how the agent obtains its capabilities.

The common interface is the Gemini Interactions API, presented here as an API for both models and agents. It supports server-side state and background execution, alongside tool calls and multimodal inputs and outputs. Selecting a model or a managed agent can therefore preserve the application's basic request interface while changing how much execution the service handles.

Agent activity also needs a richer history than alternating user and model messages. A user request can lead to reasoning, a function call, a function result, and more reasoning before an answer appears. Interactions represents those events as a flat timeline of steps. A tool result can retain its own type instead of being squeezed into the user role merely to return environmental data to the model.

The first implementation makes the developer responsible for the complete execution cycle. A Python run function calls the model, inspects its response, distinguishes a function call from text, matches the requested function to an implementation, and executes it. Results—and errors when something goes wrong—must return to the conversation so the model can choose its next action. That repeated request, dispatch, and return is the agent loop.

Three pieces define the reviewer:

• System instructions: A separate prompt file establishes the role of GitHub PR reviewer.
• Tool declarations: Handwritten JSON schemas describe the available actions and the arguments the model must generate.
• Tool implementations: Python functions send requests to the GitHub API and return the data needed for review.

The declaration tells the model what it may request. The implementation performs the request outside the model.

The demo asks for a review of a pull request in the Gemini Skills repository. Function calls and results begin appearing, showing that the loop reaches the supplied GitHub capabilities. But a request outside that tool set receives a refusal. The model's ability to understand a question does not supply an implementation for answering it: this reviewer can act only through the tools the application defines.

The maintenance cost extends beyond GitHub logic. The application also owns routing, schemas, execution, error handling, and state. Each part is ordinary software, but each adds another place for the agent's execution to break. This is the boilerplate the second version removes.

ADK replaces the custom agent implementation with an agent class that handles tool loops, function calling, retries, and errors. The reviewer keeps the same prompt and Python tools. Its handwritten JSON declarations disappear too: the framework derives the schemas from function signatures and supplies them to the model. Schemas still exist in the execution path; the developer no longer maintains them separately.

The second reviewer retrieves PR data, the diff, and the code needed for inspection. Then comes the revealing question: what is the weather in San Francisco? There is no weather tool, so the expected response remains that the agent cannot obtain it. Packaging the loop in a framework reduces implementation work without expanding the agent's available actions.

The framework owns turn-taking, routing, execution mapping, and schema creation. The application still owns Python tool implementations, domain rules, and the environment that runs them. Extending the reviewer still means adding application code and arranging somewhere for that code to execute.

The third approach uses the Antigravity remote agent on the Gemini API. It shares the harness—the machinery around the model—with the Antigravity IDE, but sharing a harness does not make the agents identical. The IDE agent is described as a coding agent; the API agent is general purpose, with potentially different instructions and tools. In particular, the Gemini API already supplies Google Search.

An environment parameter supplies a hosted, isolated cloud sandbox. The agent can run Bash commands, use tools, and save files there. Sources can come from a GitHub repository, a GCS bucket, or inline files. Instead of implementing every GitHub operation as a Python function, the application can provide an environment in which the agent uses existing software.

Authenticated requests pass through a network proxy around the sandbox. The agent initiates an outbound request, and the proxy injects the configured credential on the way to the external service. The agent can use GitHub without receiving the token itself. This separates access to the secret value from the ability to perform authenticated operations; it does not, by itself, limit what those operations may do.

Which component holds the credential, and which component sends the request? The diagram traces that separation. Network access has another control: permitted domains can be restricted, while the default described in the talk allows access to all domains for convenience. The demo later combines credentials for GitHub destinations with general web access that carries no GitHub credentials.

For reuse, the Agents API lets the developer register a configuration under a custom ID. That configuration includes the system instructions, base agent, and environment. Subsequent calls select the ID through the same style of interface used to select a model or the base remote agent. The configuration becomes a reusable agent definition rather than something rebuilt for every request.

In the third demo, the source directory is gone. An AGENTS.md file carries the review instructions and tells the agent that it has a GitHub CLI, Bash, and a filesystem. Dedicated functions for accessing a PR or reading its files have disappeared. The model chooses commands using its existing knowledge of the CLI.

There is still one small executable dependency: a Bash script that checks whether the GitHub CLI is installed and downloads and installs it if necessary. This matters immediately. When the review starts, the agent explores the sandbox, tries the CLI, discovers that it is missing, installs it, and proceeds with the review. The environment visibly changes from lacking the required program to containing a usable tool. The model handles that prerequisite through general commands rather than a developer-written branch in the PR-review loop.

The client streams the interaction so calls and results appear while the remote work continues. The same San Francisco weather question now produces a Google Search call and an answer of around 20°C, for July 2 in the demonstration. That is a concrete change from refusal to retrieval through an available general tool. It demonstrates broader task reach, rather than establishing weather accuracy or PR-review quality across repeated runs.

The weather answer also explains the architectural difference. No weather-specific Python wrapper was added. The API agent already had Search, and the model chose it for a question the GitHub CLI could not answer. General tools let the model compose a route to a task without the application naming every task-specific action in advance.

The client still makes an API call. It supplies user input, the environment, and the previous interaction ID to continue a multi-turn conversation. The environment sources include the installer script and AGENTS.md; credentials cover both GitHub API access and github.com, serving HTTP and Git commands. The backend starts the sandbox, loads the instructions and skills, and runs the repeated tool-call and tool-result cycle.

Where did the deleted Python work go? The following diagram shows the remaining client request beside the execution cycle now handled by the service. One client call can contain many model–tool exchanges. The loop remains essential; its implementation has moved out of the application.

The managed agent also handles conversation and session state, tool routing, and context compaction. The client sends new input instead of rebuilding the entire history or implementing its own compaction step. A remote Linux sandbox supplies the execution environment. These are the infrastructure responsibilities removed from the developer's reviewer.

Three responsibilities remain:

• Instructions and rules: Define the desired behavior and domain requirements in AGENTS.md.
• Capabilities and context: Supply the files, skills, and software the agent needs to accomplish the work.
• Evaluations: Decide what successful behavior means and verify the outcomes.

Reducing orchestration code leaves more attention for these product-specific decisions. A hosted loop cannot decide whether a review meets your standards.

Security scanning makes the extension cost concrete. In the earlier design, adding a scan requires choosing a scanning CLI, wrapping it in a Python function, defining a function schema, registering the tool, and running the updated implementation. In the file-based design, the developer provides skill instructions describing the scanner and, when needed, places the CLI in the environment. The agent can use those additions through its existing execution tools.

A skill does not make the scanning software unnecessary. It removes the need for a new application wrapper when Bash and the supplied program already provide the required action. The extension changes the agent's available knowledge and environment, while its client-side orchestration stays the same.

The talk points to a Git-worktree example that replaced roughly 12,000 lines of TypeScript orchestration with about 200 lines of agent files, skills, and Markdown. It also cites Manus refactoring its harness five times in six months during the previous year. These examples motivate revisiting orchestration as model capabilities change: a workflow that once required hardcoded coordination may become something a model can carry out from instructions.

The closing heuristic is pointed: if the harness grows more complex as the model improves, it is probably being overengineered. New capability should prompt a question about what can be removed. The aim is to benefit from improved model judgment rather than keep adding execution paths that reproduce decisions the model can now make.

Files can hold more than capabilities. An agent asked to remember a preference can write a note to disk and reuse it in a later session. A long-running session can also externalize a new feature request as a handoff file, leaving it available for later work. The mechanism is explicit storage followed by retrieval: later work benefits when the relevant file is available and read.

That brings the practical advice back to ownership. Give the agent general tools and room to explore, reason, and find a solution. Keep domain instructions and workflows clear, define useful tools, own the evals, and verify the results. “Build to delete” is the phrase that lands: preserve the behavior the product needs while allowing improved models to retire unnecessary implementation.

The final invitation is to try the harness in AI Studio, where prompting it starts a custom sandbox, then begin building files and skills. API-key setup is offered as another route. A free tier for the API is described as work in progress at the time of the recording, so the invitation does not establish free API availability.