Build Your Own Team of Managed Agents with Jack Wotherspoon, Google DeepMind

Managed (cloud) agents eliminate the infrastructure and harness-engineering burden of running coding agents locally by offering sandboxed agents accessible v

Build Your Own Team of Managed Agents: Architectural Analysis of Cloud-Native Agent Infrastructure

Abstract

This synthesis examines managed agents (also termed cloud agents), a deployment model in which coding and research agents execute inside provider-operated sandboxes reachable through a single API call. The central claim is that managed agents remove two distinct burdens from developers: the operational cost of provisioning isolated execution environments, and the engineering cost of constructing an agent harness within them. Evidence is drawn from the design of Google's Interactions API, the anti-gravity harness, and associated primitives for environment reuse, credential injection, and scheduled execution. Key findings include the decoupling of conversation state from file system state as an enabler of multi-agent composition, a proxy-based credential model that withholds secrets from the sandbox, and the removal of output-length ceilings in Gemini 4 Argon via a shared one-million-token context window. Practical implications for multi-agent pipeline design are discussed, drawn from a demonstrated three-agent financial research pipeline.

1. Introduction

Agentic coding systems have converged on a common structural pattern: a harness that mediates between a language model and a set of tools, executing multi-step loops of reasoning, tool invocation, and verification. The dominant distribution model for such systems has historically been local - the harness runs on the developer's workstation, with the file system, shell, and browser of that machine serving as the agent's operating surface.

This analysis addresses whether local execution remains the appropriate default for agent deployment. Two categories of limitation are identified: interference, in which an agent's actions disrupt the human user's concurrent use of the same machine (stealing browser focus, triggering pop-ups), and non-scalability, in which a locally configured agent cannot be shared with colleagues or embedded in customer-facing applications without exposing the developer's personal subscription or local setup. Managed agents are presented as the architectural response to both problems, characterized by the position that provisioning should collapse to a single API call rather than a container-engineering exercise involving virtual machine setup, dependency loading, and firewall configuration.

The analysis covers the shift from model-centric to agent-centric APIs (Section 2), the constituent primitives of the managed-agent architecture - harness, environment, skills, credentials, and triggers (Section 3) - actionable implementation findings including the security model and model-configuration mechanics (Section 4), and broader implications for multi-agent system design (Section 5).

2. Background and Related Work

The relevant prior paradigm is the model-based input/output API, in which a client submits a prompt and receives a completion, with any multi-step behavior orchestrated entirely by client-side code. The Interactions API, described as an agent-first SDK that reached general availability earlier in the year, replaces this paradigm. Rather than a single-shot exchange, an interaction encompasses multi-step agent behavior: writing files, invoking MCP (Model Context Protocol) tools, and conducting multiple turns within one logical unit of work.

The harness supplied in the managed configuration is the anti-gravity harness, described as identical to the one used in Google's Anti-Gravity product suite. This detail is consequential for the thesis: the harness is not a reduced demonstration implementation but the production tool-calling loop, meaning the engineering investment normally required to build a competent agent loop - tool dispatch, result handling, built-in tool integration - is inherited rather than reproduced by the developer.

3. Core Analysis

3.1 From Container Engineering to a Single Parameter

Building a sandbox independently requires spinning up a container or virtual machine, loading dependencies, constructing a custom harness within that environment, and separately managing networking, firewall rules, and security configuration. The managed-agent model collapses this sequence: setting environment=remote on the base anti-gravity agent configuration triggers a cloud-hosted agent. Internally, client input is routed to the Gemini API, which exposes built-in server-side tools (web search, file system operations), supports custom functions and MCP tools, and provisions a sandbox on Google Cloud infrastructure. Files - including skills, agents.md configuration files, or GitHub repositories - can be uploaded to the sandbox at startup.

3.2 Decoupling Conversation State from File System State

A structurally significant design choice is the separation of two stateful primitives: Interactions, which manage conversation state across input/output turns (an interaction ID can be passed forward to continue a conversation), and Environments, which represent the sandbox's file system state independently of any single conversation. Because an environment ID can be reused across separate agent interactions, one agent can save files to the shared file system and a second agent - instantiated with a fresh context window - can reuse the same environment ID to build on that work without inheriting the first agent's conversation history. This decoupling is the mechanism that enables composable multi-agent pipelines: each agent in a chain can be purpose-specific and context-efficient while still operating on a common, cumulative body of work.

3.3 Composable Primitives: Skills, Credentials, and Triggers

Beyond the harness and environment, three further primitives extend managed-agent functionality. Skills are uploadable playbooks analogous to personal agent configurations, allowing reusable task-specific behavior to be injected into a sandbox. Credentials provide a mechanism for injecting tokens or MCP OAuth credentials so that a sandboxed agent can act against external services on the user's behalf. Triggers supply a scheduling mechanism for autonomous execution - for example, running a financial analysis agent daily before market open - and support webhook-based invocation such as responding to Slack messages. Collectively, these primitives move the managed-agent model from a single-call execution tool toward a platform for persistent, schedulable, credentialed agent deployments, reinforced by an Agents API (agents.create) that allows a refined agent configuration to be saved and re-invoked by agent ID rather than reconstructed on each call.

3.4 Demonstrated Multi-Agent Composition

The architecture was validated through a financial research pipeline chaining three managed agents across one shared environment ID: an SEC filing researcher (analyzing Nvidia filings), a quantitative agent (running Python-based analysis and share price forecasting on the researcher's output file), and a reporting agent (compiling the combined findings into a final report). Step traces recorded each agent's actions, including function results and code execution, supporting downstream debugging and optimization. A second demonstration connected a managed agent to Google Drive receipts data to generate an interactive visualization report via a custom skill, and a third - an AI Studio gallery "ticker agent" - triggered multiple managed agents from a single stock ticker input to produce a PDF report with charts and sourced citations.

4. Technical Insights

Several implementation-level findings merit emphasis for engineers evaluating this architecture.

First, model configuration is decoupled from harness configuration: the model backing the harness can be swapped via a one-line parameter, with Gemini Flash recommended for fast, lower-cost tasks and Gemini 4 Argon recommended for deep reasoning or heavy multi-document analysis. Gemini 4 Argon introduces a "long decode" capability, replacing a prior approximate 64K output-token cap with a shared one-million-token context window spanning input, thinking, and output tokens jointly - a design that specifically targets extreme-length reasoning tasks such as detailed financial modeling.

Second, the security model relies on a proxy layer rather than sandbox-held secrets. Real credentials never enter the sandbox directly; instead, a proxy sits between the sandbox and the API, injecting real tokens only at the moment an external API call is made, while the sandbox itself holds only placeholder dummy tokens. This design constrains the blast radius of a compromised or misbehaving agent, since the agent process never has direct possession of usable credentials - a meaningful trade-off against architectures that inject live secrets directly into agent-accessible environments.

Third, tooling is layered: built-in tools (code execution, file read/write, search) are available by default, while custom remote MCP servers extend the tool surface for domain-specific integrations. This layering allows a baseline agent to be functional immediately while remaining extensible for enterprise-specific connectors.

A notable limitation, implicit in the source material, is that the architecture's benefits - security isolation, scalability, credential safety - are tied to a specific provider's infrastructure, meaning portability across managed-agent platforms is not addressed.

5. Discussion

The decoupling of interaction state from environment state represents a reusable design pattern beyond this specific implementation: any multi-agent system that needs to compose specialized agents with distinct context windows over a shared artifact store faces the same structural requirement. This suggests the pattern is likely to recur in other agent platforms rather than remaining a Gemini-specific idiosyncrasy, as it addresses a general tension between context-window economy and cross-agent continuity.

The proxy-based credential model also reflects a broader industry trend toward treating agent autonomy as a security liability to be structurally contained rather than merely policy-constrained. Rather than relying on prompt-level instructions to prevent credential misuse, the architecture removes the capability at the infrastructure level - a more robust mitigation given the known unreliability of instruction-following as a security boundary for autonomous systems.

An open question concerns cost and latency trade-offs: the source material does not address pricing models for sandbox provisioning or the latency overhead of spinning up a fresh sandbox per interaction versus reusing a persistent environment, both of which would materially affect production viability for latency-sensitive applications.

6. Conclusion

This analysis has examined the managed-agent model as a response to the interference and scalability problems inherent in local agent execution, finding that the architecture's core contribution is not merely sandboxing but the decoupling of conversation state and file system state into independently addressable primitives (interactions and environments). This decoupling, combined with a proxy-based credential model and configurable harness-model pairing, enables secure, composable multi-agent pipelines validated through a demonstrated three-agent financial research workflow. Practically, engineers building multi-agent systems should consider environment reuse as the primary composition mechanism rather than passing full conversation histories between agents, and should evaluate proxy-based credential injection as a security baseline for any agent granted access to external services.

Sources

• Build Your Own Team of Managed Agents - Jack Wotherspoon, Google DeepMind - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub