Google Managed Agents Commentary: Why agent apps should be designed with isolation runtime, state resumption, and tool permissions ahead of models

1. One-line problem definition

Key takeaway: The challenge for agent apps lies less in model calls than in keeping the execution environment safe.

On May 19, 2026, Google released Managed Agents in the Gemini API. This feature allows you to launch an agent that makes inferences, uses tools, and executes code with a single API call in a remote Linux environment.

To put it simply from a novice developer's perspective, Managed Agents is not an “API that only receives answers from models” but is closer to an “API that even lends you a desk to work on.” Attached to the desk are files, execution status, web browsing, and code execution environments.

The scope of this article is development teams that want to include agents for research, file processing, code execution, and repetitive tasks in their products. This may be an overkill for apps with simple question-and-answer chatbots, fixed FAQs, and little external tool execution.

2. First, conclusion

Key summary: Managed Agents are strong for quick experiments, but if attached without permission design, operational risk increases first.

Managed Agents is suitable for “teams that want to quickly verify product functionality without creating the agent infrastructure themselves.” It is especially valuable when a long operation must be continued multiple times or when subsequent requests must be processed while preserving the file state.

Conversely, if a team already has its own sandbox, work queue, audit log, and permission separation system, there is little reason to change unconditionally. Using Google's managed environment reduces infrastructure burden, but control over execution location and data boundaries must be considered separately.

This is my judgment. If you are introducing it now, it would be better to start with “internal auxiliary tasks that can be recovered even if they fail,” rather than “automating all core tasks.” For example, it is a flow with human review gates, such as creating a research draft, summarizing logs, running code for testing, and organizing internal documents.

3. Decomposition of core structure

Key takeaway: The architecture should be viewed in five layers: model, agent harness, containment environment, tools, and state resumption.

According to Google's explanation, Managed Agents are based on Antigravity agents. Antigravity is a harness that helps agents create plans, call tools, and subsequently process the results. Like a car's engine control unit, the harness bundles the necessary procedures to move the model to actual work.

Above that is Gemini 3.5 Flash. Google describes this model as a fast model tailored to agent tasks, and presented figures such as Terminal-Bench 2.1 76.2%, GDPval-AA 1656 Elo, and MCP Atlas 83.6% in the I/O 2026 announcement.

The execution layer is a remote Linux environment. This is where agents can run code and manage files. The important thing is that this environment is not simply a temporary response buffer, but a workspace that can be retrieved from subsequent calls.

Finally, there are tools and states. This includes retrieving the latest data from the web, creating files, or retrieving the results of previous work. The quality of an agent's product depends on how separate these five layers are and whether it is possible to trace where failures occurred.

4. Description of design intent

Key takeaway: Google's intention is to extend the Model API from a “response generator” to a “task execution runtime”

The basic units of the existing LLM API were generally requests and responses. The user asked the question, the model answered, and the application did the rest. This method quickly gets blocked in the agent app. This is because the model must break the work into steps, create intermediate files, check external data, and restart from the point of failure.

The design of Managed Agents is aimed at reducing this bottleneck. Google takes on some of the burden of manually launching containers, creating task state storage, designing file isolation, and configuring tool call flows.

But this choice comes at a cost. Instead of being able to get started faster than your own infrastructure, the detailed policies and data locations of your execution environment must be interpreted within Google's product contracts. If the agent handles customer data or runs internal code, this is more important than a simple feature comparison.

So, when looking at this technology, we should first ask “What tasks can our product entrust to us?” rather than “How smart is Gemini?”

5. Evidence and Comparison

Key takeaway: Your competitors are not chatbot APIs, but your own sandbox, browser automation, and coding agent platforms.

Approach	Correct situation	What you get	Give up or check
Gemini Managed Agents	When quickly adding managed agent functionality to a product	Isolated Linux environment, file status, tool execution, resume subsequent calls	Data boundary, permission policy, cost estimation, preview feature stability
Generic LLM API + calling your own tool	When the task is short and no execution environment is needed	Simple structure, high control, low initial complexity	State management and sandbox must be implemented yourself
Own container sandbox	When security, audit, and data location control are strongly required	You can design execution boundaries and log policies yourself	Increased infrastructure operation costs and failure response burden
IDE/CLI type coding agent	Automation of code work by individual developers or teams	Suitable for local workflow and easy to create review flow	Difficult to embed in end-user product or requires separate design

The key sentences in Google’s official blog are “single call” and “isolated Linux environment.” These two expressions are not simple convenience functions. This means that the two most cumbersome areas in agent products, namely preparation of the execution environment and task status management, have been commercialized.

Another basis is the Google I/O 2026 developer announcement. Google released Antigravity 2.0, Antigravity CLI, SDK, Gemini Enterprise Agent Platform, and Managed Agents as a bundle. This is closer to a strategy to bundle it into an agent development platform rather than a single feature release.

6. Actual operation flow and step-by-step execution method

Key summary: Do not entrust customer tasks from the beginning, but start with small tasks with fixed input, authority, and output inspection steps.

It is safer to set the actual introduction flow as follows.

1. Limit the scope of work to one sentence. Example: “Read product log files and tabulate failure candidates.”
2. Minimize files and tools that agents can access. Exclude customer original data, payment information, and secret keys from the first experiment.
3. Create directives in the form of AGENTS.md or SKILL.md. Google mentions markdown-based instructions and skills in Managed Agents. In other words, it is better to view it as a method of registering an operation manual rather than a single prompt.
4. Creates an environment and executes the task on the first call. At this stage, check the execution log and file creation location rather than the results.
5. In subsequent calls, the same environment is inherited and the possibility of resumption is verified. If state resumption is not possible, the advantage of a managed agent is greatly reduced.
6. Only the output that has passed the human inspection gate is reflected on the product screen. At the preview stage, it is better to reflect after approval rather than automatically reflect.

A simple work contract example can be written as below:

{
"task": "Classify error logs from the last 24 hours into candidate causes, supporting logs, reproducibility, and next actions.",
  "allowed_files": ["logs/app-2026-05-22.txt"],
"blocked_actions": ["External Deployment", "Delete Customer Data", "Print Secret Key"],
"definition_of_done": "Create a tabular summary and draft reproduction instructions, marking anything you are unsure about as an estimate."
}

The point of this example is not the sentence that makes the agent smart. First, fix what can be done, what cannot be done, and what the completion criteria are.

7. Mistakes and Pitfalls

Key summary: Failures occur in authority, status, cost, and inspection flows before model answers.

The first pitfall is giving broad permissions. It is convenient if the agent can execute code, but it also makes it possible to modify incorrect files or make external calls. A preventive measure is to start with read-only data and open write permissions separately for each task. If a problem occurs, a recovery procedure is required to discard the environment and reconnect only the input file.

The second pitfall is to blindly trust state resumption. The fact that files and states are continued in subsequent calls is an advantage, but stale intermediate results can contaminate subsequent decisions. The precaution is to distinguish between “files valid for this run” and “files for reference only” for each task.

The third pitfall is calculating the cost like a chat API. Managed agents can affect the cost structure not only with model tokens, but also with execution time, tool calls, web browsing, and file operations. A preventative measure is to first set the maximum number of steps per task, maximum execution time, and number of retries.

The fourth pitfall is to show the results directly to the user. Even if the agent browses the web and executes the code, fact verification does not end automatically. Sourced assertions, actionable commands, and failed assumptions should be indicated separately.

8. Strengths and Limitations

Key takeaway: Strength is startup speed, limitations are operational control and preview stability.

The biggest strength is the infrastructure startup cost. Creating a remote Linux environment for agents, file states, tool execution, and subsequent resumes by hand is a huge burden for small teams. Managed Agents reduce this burden, speeding up product experimentation.

The second strength is the connection to the Google ecosystem. In the I/O announcement, Google emphasized connectivity with AI Studio, Android, Firebase, Workspace, and Enterprise Agent Platform. For teams already in the Google Cloud and Android app development flow, adoption friction may be low.

The limitations are also clear. First, Managed Agents have a strong preview nature at the time of announcement. Rather than entrusting core tasks right away, they should be verified in the internal workflow. Second, in industries where data sovereignty and audit logs are important, a managed execution environment may actually increase review items. Third, the more work an agent can do, the clearer product responsibility should be. This is because users accept that “our service did it” rather than “Google agent did it”.

Therefore, highly regulated tasks such as financial, medical, legal, and customer personal information processing must first check the terms of their own sandbox or enterprise contract. Conversely, internal productivity tools, development assistants, and research automation can be good candidates for experimentation.

9. Points to study more deeply

Key takeaway: Agent contracts, tool permissions, and state management documentation should be read before model documentation.

Beginner developers must first distinguish “what the agent remembers and what it executes.” Memory is context and file state, execution is tool invocation and code execution. If you mix the two, the authority design becomes blurred.

The next thing to look at is the Antigravity series document. Antigravity is the name used by Google to group the entire agent development environment. Don't just look at Managed Agents separately, but also look at how they are connected to AI Studio, CLI, SDK, and Enterprise Platform.

Finally, it is necessary to observe web standard flows such as WebMCP. As websites move toward providing agents with structured tools, managed agents take on more external tasks. What is important then is not “can it be connected?” but “is it possible to approve and withdraw?”

10. Implementation checklist and author's perspective

Key summary: The introduction standard is not a model performance table, but a structure that can be stopped in case of failure.

• If this operation fails, can it be reversed without customer damage?
• Are the files the agent can read and the files it can write separated?
• Have you distinguished between the state to be inherited and the state to be discarded in subsequent calls?
• Do you leave sources and dates in external web browsing results?
• Have you set the maximum execution time, maximum number of retries, and maximum number of tool calls?
• Is there human or separate verification logic before showing to the user?
• Have you prevented the secret key, personal information, and payment information from entering the execution environment?

Definition of Done: Managed Agents experiments are considered completed when “the input, authority, execution log, output inspection, and recovery procedures are recorded as a single operation,” rather than “a result that appears to be the correct answer.”

My recommendation is clear. For teams already using Google Cloud or AI Studio flows, it's worth testing Managed Agents as an internal automation pilot right away. However, core tasks involving customer data still need to be approached conservatively. The quality of an agent app is determined by the clarity of task boundaries rather than the model name.

Reference material

• Google Blog: Introducing Managed Agents in the Gemini API (2026-05-19)
• Google Blog: Building the agentic future, Developer highlights from I/O 2026 (2026-05-19)
• Google Blog: 100 things we announced at I/O 2026 (2026-05-20)
• Google AI for Developers: Gemini API Agents Overview
• Google AI for Developers: Interactions API documentation