7 Things Your AI Coworker Needs - Philipp Schmid, Google DeepMind

At 8:30 each morning, a portfolio audit should be able to start while everyone’s laptop is closed. The job is specific: check what changed in the portfolio and record the results in a Google Sheet. Someone reading the update can then ask about it in Slack. For Philipp Schmid of Google DeepMind, the interesting engineering question is what the agent needs in order to do that job on its own.

Schmid built a finance agent called Bug around seven needs: a brain, a computer, playbooks, tools, credentials, house rules and a schedule. Gemini supplies the reasoning. The computer matters because of where tool calls usually run. In a conventional loop, the model emits a function call, the application executes it, and the application sends the result back. If the model wants to run Python or write a file, some application process has to do that work for it.

With the Gemini API’s Managed Agents, Bug has a remote sandbox where it can execute code and write files directly. Schmid defined Bug with an agent ID, a model, system instructions and the same agent harness used in Antigravity. A caller can then address Bug by its ID and give it a task. That separates the application that initiates the audit from the computer that carries it out.

Schmid organized Bug’s knowledge by how often it needs to enter the model’s context. System instructions accompany every request, so a long procedure there incurs a cost even when Bug is answering a follow-up in Slack. A skill has a short description that tells Bug when to open it. Within the skill, separate references and scripts let Bug fetch the detail required for a particular step. One dense skill can still consume substantial context each time the agent selects it.

The portfolio-audit skill illustrates the split. Its description helps Bug recognize an audit request. Its instructions identify a Python script Bug can run, explain what to do with the results and specify where to store them. That last detail is part of the procedure: finishing the calculation still leaves the agent with a spreadsheet to update. The sandbox’s filesystem gives the script, instructions and references a common home. It can also hold lessons from earlier sessions or new skills the agent writes.

Bug’s Python script and its spreadsheet update do different kinds of work. Code execution belongs in the sandbox. For a spreadsheet operation, Schmid configured a Google Workspace Model Context Protocol (MCP) server, which exposes the external service as tools the agent can call. Google Search was another option available directly through the Gemini API. The agent definition is where Schmid selected which capabilities Bug would have.

A managed sandbox still leaves room for application-owned functions. If an operation needs to run on a computer you control, Bug can emit a conventional function call and wait for your application to return the result. That choice carries an implementation cost: your application owns execution and the return path for that operation. It also gives you a clear place to run work that belongs outside the agent’s environment.

A CLI may expect a token in an environment variable. Putting the real token there would give any process that can inspect the environment a way to read it. Schmid’s example was a prompt injection asking the agent to print its .env file. Managed Agents supports credentials for bearer-token API calls, OAuth integrations and tools that expect environment variables. The developer creates the credential outside the sandbox. Once stored, its value can be overwritten for rotation, but the credential interface offers no readback.

For an environment-variable credential, the value inside the sandbox is a dummy. The CLI constructs its request with that value as usual. A network proxy at the sandbox boundary checks the destination against the developer’s configuration. For a matching domain, the proxy substitutes the real credential and sends the request. The service authenticates it, and Bug receives the result.

That destination check is what makes the dummy useful. An instruction to print the environment can expose the placeholder. Sending the placeholder to a malicious MCP server also leaves it a placeholder, because that server’s domain does not qualify for substitution. Bug can still use an authorized service, which raises a separate question: which operations should it be allowed to perform there?

Schmid used system instructions to steer Bug’s behavior in conversation. For commands that need monitoring or human approval, he described a more direct control. The harness checks each proposed tool call against a hook’s regular-expression matcher. A matching call can invoke an approval step outside the conversation, so the model does not have to remember to ask on its own.

Hooks live in files, much like skills, but their permissions differ. Bug can write a skill as it learns a procedure. Its hook files are protected, so it cannot edit the rule that guards a tool call. The distinction matters for the portfolio agent: explaining a change in a position is a conversational task. Requiring approval for a particular command is a decision the harness can enforce whenever it sees a match.

A cron trigger supplies an input to Bug in the same environment on a schedule. Schmid configured the example around an 8:30 a.m. audit. In the live demonstration, he clicked a control in a browser replica of Google Sheets to simulate the timer. The click sent a real Managed Agents API request. Bug read the portfolio-audit skill, called financial services to check for price changes and, according to Schmid, updated the Google Sheet. The demonstration exercised the work downstream of the timer.

In a Slack follow-up, Schmid asked for a recommendation. The agent drew on earlier turns in the thread and discussed three positions. Schmid attributed its decision to stop at an explanation to its system instructions. He presented external webhooks as work in progress. Cron was the trigger available in the system he demonstrated.