Autonomous Finance Agents Need More Than a Capable Model

Philipp Schmid frames an AI coworker as a shift from answering questions to taking responsibility for a defined task. A chatbot answers when asked; an assistant uses tools while a person watches; a coworker gets a goal, works in its own environment and reports back. Schmid describes the shift this way: “Give an agent its own computer, give it a task and hopefully come back a few hours later with a good result.”

For a finance example, Schmid builds “Buck,” a quant on the Meridian desk. Buck’s assignment is to audit a portfolio, flag positions that drift from their targets, update a spreadsheet and report the result. That workflow requires more than a capable model. Schmid breaks the setup into seven needs: a brain, a computer, a playbook, tools, logins, house rules and a schedule.

The architecture he demonstrates is Google’s Gemini API Managed Agents. Rather than run the usual loop in which an application receives a model’s tool call, executes it and sends the result back, the API gives the agent a remote sandbox for code execution and files. The agent can work in that environment through an API interaction; its persistent setup can include files, tools and credentials.

Schmid presents Gemini 4 Argon as Buck’s “brain.” He says it has a one-million-token context window, including the ability to generate up to one million output tokens, and more than 64,000 tokens available for reasoning. He also points to Google employees’ internal use of the model and a slide comparing it with other models on finance, coding, legal and tax tasks.

The comparison slide reports Gemini 4 Argon at 68.9% on the Vals Index and 65.4% on a finance-agent benchmark called Finance Agent v2. Schmid’s slide describes the Vals Index as agentic performance across finance, coding, legal and tax tasks, weighted by each sector’s share of U.S. GDP; Finance Agent v2 is described as multi-step, strict financial reasoning tasks.

The API example is deliberately small: create a client, start an interaction with the model, provide a prompt and print the output. For a persistent agent, the developer instead creates an agent with an ID, a base agent, a model and a system instruction. Buck’s instruction identifies him as a quant on the Meridian desk; subsequent interactions refer to the agent by its ID.

The larger change is the computer around the model. Managed Agents provides a remote environment where the agent can execute code and work with files. Schmid says this avoids having the developer operate the tool-call loop themselves. It also gives the agent somewhere to keep artifacts and work across interactions.

The environment can be provisioned with inline files, a repository or a Google Cloud Storage bucket. Schmid’s examples include an agents.md file describing who Buck is, skills pulled from a Git repository and exports in a storage bucket. The slide gives size limits of 1 MB per inline file and 2 MB total for inline files, 500 MB for a repository, and 2 GB for a Cloud Storage source.

In Schmid’s framing, the agent’s knowledge and working materials live in a file system: it can read supplied files, create new ones and retain information across sessions. That means files are not just initial setup. They are the place where the agent’s skills, rules and work products can live.

Schmid separates an agent’s knowledge into three layers. The first is always present: concise system instructions and brief descriptions of available skills. The second is loaded when a task matches a skill’s description: the skill’s detailed instructions. The third—scripts, references and other supporting material—is consulted only when a step requires it.

The reason for this layering is both practical and economic. Information included in every request consumes context and, in Schmid’s account, increases cost. A long system prompt or dense skill can burden work that does not need all of it. Short descriptions can tell the agent when a skill applies, while detailed references and scripts remain available on demand.

Buck’s portfolio-audit skill makes the distinction concrete. Its description says when to use it—portfolio audits and rebalance checks—and when not to use it, including 13F filings and placing trades. The instructions tell Buck to run a Python script rather than calculate weights by hand, flag positions with absolute drift of at least two percentage points, save a formatted result and update only specified spreadsheet columns and rows.

Schmid says that rewriting a skill’s description improved its triggering by about 50 percent. The description is therefore not just a label: it helps determine whether the agent selects the procedure at all. The exact steps, meanwhile, belong in the skill and its script, not in a sprawling set of instructions that must accompany every request.

Schmid groups tools into three kinds: built-ins, remote MCP servers and developer-provided functions. Built-ins include code execution and Google Search. For services such as Google Sheets or Gmail, an agent can connect to an MCP server. A developer can also define a function that runs on their own server.

That last option preserves a boundary between the agent’s environment and systems the developer wants to operate themselves. When Buck requests a function, execution pauses; the developer runs the function, returns its result with the matching call ID, and the interaction continues. Schmid describes this as a way to give the agent capabilities without running that work inside its sandbox.

These choices determine what Buck can actually do. A playbook may specify how to audit a portfolio, but tools provide the mechanisms to retrieve prices, read or update a sheet, and send a report. The design is not simply “give the model access”: it is a set of different routes for work, some inside the managed environment and some controlled by the developer.

Schmid calls credentials one of the hardest parts of deploying agents safely. Managed Agents supports three credential types: bearer tokens for API calls, OAuth credentials for services and environment variables for tools such as command-line interfaces. The slides show that OAuth credentials can be refreshed by the proxy, while environment-variable credentials can be restricted to trusted domains and binaries.

The presentation’s central security design is that real credentials are stored outside the agent’s sandbox and are write-only: they can be replaced, but not retrieved after creation. A network proxy mediates their use. The sandbox receives a dummy placeholder; when a request goes to a configured domain, the proxy can substitute the real credential. Schmid’s example is a token usable with an approved service but not with an unapproved destination. The agent gets the service’s response without being given the actual token.

Schmid says the proxy’s domain restrictions are intended to prevent an attacker from stealing credentials that are substituted on a request: “the proxy only swaps them for the domains you define.” This is meant to limit the damage of prompt injection. If malicious content tells an agent to print secrets from an environment file, the real credentials are not sitting there for it to reveal. And if an untrusted service tries to obtain a token, the proxy’s domain restrictions are intended to prevent that token from being sent to it. Schmid presents this as a way to connect agents to services while constraining where credentials can go.

Credentials control access; hooks control decisions. Managed Agents’ hooks can inspect tool calls before or after execution. A pre-execution hook can allow a call or deny it, making it the place for a gate that requires approval or blocks a particular operation. A post-execution hook can log what happened, but Schmid emphasizes that it cannot block the call. The hook files are protected so the agent cannot modify the rules it is meant to follow.

Buck’s seventh requirement is a way to start work without someone prompting him. Schmid demonstrates a cron trigger for a weekday pre-market audit at 8:30 a.m. Eastern time. The example sets a 900-second execution timeout and pauses the trigger after three consecutive failures. Each run uses the same environment, so files created on one day remain available to the next.

Cron is the trigger Schmid says Managed Agents currently supports. He separately says the team is working on webhooks to make event-driven integrations possible, with examples such as an SEC provider or a Slack mention. The slide lays out a proposed pattern: an event reaches the developer’s server, the server verifies it, then starts an agent run. For Slack, a handler could use the thread’s interaction and environment so Buck continues with the same context and files.

A schedule can initiate recurring checks; the webhook pattern would let a verified event start a response to something that has just happened. In either case, the agent’s proactive behavior depends on a developer-defined trigger, not on the model deciding on its own when to wake up.

The demo slide shows a portfolio spreadsheet beside a “Pre-market audit” agent task. The visible sheet lists five holdings and their weights, targets and drift; the task text says to run the portfolio audit, update the portfolio master and post a verified summary in #trading-desk. Schmid says the browser-based Google Sheets-style replication was created with Gemini and that clicking the control sends a real API call to Managed Agents to simulate the cron trigger.

He describes Buck reading the portfolio-audit skill, making tool calls and updating the displayed sheet. The Slack screenshot shows a report identifying three positions beyond the two-point drift limit: AAPL at +3.00%, MSFT at +10.00% and AMZN at -9.73%.

A follow-up question—“any recommendation?”—appears in a Slack thread after a message about a 13F filing. Schmid says Buck has the thread’s previous turns available as context. He also says Buck is not taking actions based on the system instructions. The demonstration establishes the threaded context and the constraint on action, but does not show the content of a recommendation response.