Managed Sandboxes Replace Agent Tool Registries With Skills and Filesystems

Philipp Schmid frames the design shift as a removal of application code, not as a claim that agents no longer require design. He builds the same GitHub pull-request reviewer three ways: first with a hand-written Python loop, then with a framework that absorbs part of that loop, and finally as a managed remote agent whose behavior is largely expressed in files. All three can review a pull request. What changes is concrete: the final version has no custom read_pr_diff function, no manually registered GitHub tool schemas, and no application loop interpreting calls and returning results.

His starting definition, credited to Simon Willison, is deliberately spare: an LLM agent “runs tools in a loop to achieve a goal.” But that loop has traditionally carried a large amount of application-specific work: maintaining state, interpreting model outputs, selecting and invoking tools, passing results back, retrying failures, and deciding when the work is complete.

The final implementation gives the model a managed Linux sandbox, a filesystem, bash, a GitHub CLI, and instructions describing its role. A small install script makes the CLI available on first use. The model can inspect the environment, discover that a dependency is absent, install it, invoke the CLI, read its output, and continue the review.

That generality becomes visible in Schmid’s repeated test question: “What is the weather in San Francisco?” The first two reviewers decline because weather retrieval lies outside their declared tool sets. The managed agent uses Google Search and returns a current-weather answer. For Schmid, this is not simply a larger catalog of tools. It is an argument for supplying capable models with a small set of general-purpose means of acting rather than encoding every anticipated workflow as an application function.

The proposed trade-off is not that teams cease to own agent behavior. It is that they should stop rebuilding generic execution machinery and focus instead on instructions, workflows, access boundaries, and evaluations.

The raw Python implementation makes the earlier responsibility boundary explicit. The PR reviewer has a class that calls the API, records an interaction ID and conversation history, and sends tool results back to the model. It needs a system instruction, JSON schemas for every function, Python implementations for those functions, and error handling around execution.

Its prompt identifies the agent as an “automated senior GitHub PR reviewer.” It must parse a repository and pull-request number; retrieve PR details and a diff; read repository files when it needs more context; post line-level comments when it finds issues; and return a final summary. The underlying GitHub client reads a GITHUB_TOKEN from the environment and uses it in authenticated HTTP requests.

The implementation works on the task it was built for. In the demonstration, the agent reviewing pull request 1 in google/gemini-skills calls get_pr_details, receives PR metadata, then calls read_pr_diff. But its scope is exactly its exposed interface. Asked for San Francisco weather, it says it cannot provide it because its capabilities are limited to reviewing GitHub pull requests.

Schmid’s point is not that raw API access is defective. The API handles token generation and native function calling. The issue is the operational code developers continue to carry: execution loops, routing, retries, JSON schemas, function dispatch, message lists, and session state.

Agent frameworks remove an important portion of this burden. Schmid uses Google’s Agent Development Kit as an example of a framework that manages turn-taking, maps model outputs to Python functions, derives JSON schemas from function signatures and docstrings, and handles retries and backoff. The explicit agent-loop file disappears, as do manually authored schemas.

But the abstraction does not move the whole boundary. The same system prompt and GitHub-oriented Python functions remain. Developers still write and maintain each custom tool, update code when a new feature requires a new action, and provide the runtime environment in which those tools execute. The framework governs orchestration; the application still defines the model’s practical world through a function registry.

Schmid describes the managed alternative as a general-purpose remote agent running in an isolated cloud sandbox. The agent available through the Gemini API uses the same harness that powers the Antigravity IDE, he says, while emphasizing that this does not make the API agent and the coding-oriented IDE agent identical. They may have different system instructions and slightly different tool sets; the API agent can also use Google Search.

The consequential interface is the environment parameter. A developer can provide an agent, user input, and a remote environment rather than an API request centered on a list of custom application functions. The environment can include a GitHub repository, a GCS bucket, or inline files. It can be configured for an individual request or saved as a reusable agent configuration and invoked by ID.

In the PR-review demonstration, the project’s source directory is gone. What remains is an AGENTS.md file containing system-level instructions and a basic bash script that checks whether the GitHub CLI exists and installs it if necessary. The instructions tell the agent that it has access to the GitHub CLI, bash, and a filesystem and should use them when relevant.

It no longer receives a custom function for reading a pull-request diff, retrieving metadata, or posting a review comment. Schmid says the agent begins by exploring the sandbox, checks for the CLI, finds it missing, installs it, and then uses the CLI and its existing knowledge of that interface to review the pull request.

This also changes how he proposes extending the agent. Adding a security scan to the earlier versions would require a Python function, a schema, tool registration, and execution plumbing. In the managed version, Schmid says, a team can add a SKILL.md file explaining which CLI tool to use and how to use it, while making that utility available in the environment. The new capability arrives as procedure and context rather than as a newly registered function.

The broader environment does not mean the agent receives unrestricted access to every system or credential. Schmid says the sandbox is surrounded by a network proxy that injects credentials when the agent makes outbound requests. The agent never sees the credential itself. It knows it can call the GitHub API; the proxy supplies the configured token when the request leaves the sandbox.

In the PR-review configuration, Schmid says separate GitHub-related credentials are needed because Git commands and HTTP API calls use different URLs: github.com and the GitHub API. The agent can use both interfaces, but the token is not exposed in its working environment as a value it can inspect.

Network access can also be limited by domain. Schmid says developers can use an allowed-domain configuration to restrict which destinations the sandbox can reach. Leaving that configuration blank locks down access. The default is broader web access because requiring developers to enumerate every possible destination would create friction.

The configuration shown in the demonstration separates these concerns. GitHub receives credentialed access. A “Domain All” setting allows the agent to reach the broader web, but without providing GitHub credentials to those destinations. That policy is what makes the weather answer possible: the managed agent can use search because broader web access is permitted, not because access to GitHub has somehow granted it a general-purpose secret.

Schmid’s setup therefore makes a distinction that the earlier function-based reviewer largely concealed. General tools determine what kinds of action the model can attempt. Environment configuration and network policy determine which systems it can reach, under what credentials, and from which domains.

The managed harness moves the generic operational layer server-side. Schmid lists execution loops, tool routing and dispatch, conversation and session state, context-window management and compaction, and the isolated remote Linux sandbox as work the harness performs.

A client can continue a multi-turn interaction by passing a previous interaction ID. Schmid says that when a conversation becomes long, the service can compact its context and continue without the application managing the message history itself. The developer’s API call supplies the user input and configured environment; the service and sandbox handle the repeated cycle of action, result, and further action.

The team’s responsibilities become more explicit rather than disappearing. AGENTS.md holds instructions, rules, and intended behavior. SKILL.md files hold task-specific procedures and context, such as guidance for PR review or security scanning. The environment establishes sources, available utilities, network destinations, and credential associations. Evals determine whether the result is acceptable.

Schmid does not present model discretion as a substitute for verification. His closing guidance pairs general tools with clean interfaces and strict outcome checking. Teams still need to specify what a good review, escalation, or workflow looks like; decide which resources the agent may use; and test whether it reached the standard.

The recurring code—loops, routing logic, context handling, and runtime management—is what Schmid expects to become infrastructure. Domain instructions, procedures, access policy, and evaluation remain the product work.

Schmid calls the pattern a “bitter lesson of agent engineering”: as models improve, hard-coded orchestration should tend to shrink. His practical test is that a harness becoming more complex as model capabilities improve is probably overengineered.

That test applies to orchestration, not to the durable work of controlling and evaluating an agent. Permissions remain necessary precisely because a general-purpose environment may reach real systems. Domain instructions remain necessary because the model needs to know what a good review, escalation, or workflow looks like. Skills remain necessary to provide procedures and relevant context. Evals remain necessary to determine whether the result is correct or acceptable.

Schmid cites several organizations as examples of teams reducing or repeatedly revising their orchestration in response to changing model capabilities.

Cursor’s example is the most concrete. Schmid says the company had hard-coded orchestration for Git worktrees and side-by-side visual diff judging, then replaced roughly 12,000 lines of TypeScript with a 200-line Markdown skill file. His argument is not that Markdown is inherently superior to TypeScript. It is that a model operating in a sufficiently general environment can replace application logic that prescribed execution paths in advance.

The endpoint of this model is filesystem-native agents. Markdown files extend capabilities. Agents can write memory files when asked to retain notes, preferences, or rules from a session, then use those files later. Long-running work can save summarized state or a handoff to disk for future pickup. Schmid’s example directory contains environment configuration, an AGENTS.md file for persona and rules, a memory/LEARNINGS.md file, and skill directories for PR review and security scanning.

“Build to delete” is therefore Schmid’s engineering heuristic. Write simple, disposable code because improved model reasoning may make parts of the current harness unnecessary. Do not micromanage an execution path when general tools, a well-configured environment, and clear instructions let the model explore and discover a solution. Retain ownership of the parts that do not become generic with model progress: domain behavior, workflow knowledge, access policy, and evaluation.