On July 28, 2026, Google announced a set of changes to Managed Agents in the Gemini API: a new default model (Gemini 3.6 Flash), environment hooks, budget controls, scheduled triggers, free-tier access, and a new API for managing sandbox environments directly. None of this is flashy on its own. But taken together, it answers a question that has been sitting unanswered in most agent pilots: who is watching what the agent does, and what happens when it goes too far or costs too much.
If your team is running or considering an agent pilot on any platform, this update is worth five minutes, not because Google solved agent governance, but because it shows what a governance layer for agents is starting to look like.
What Actually Changed
Managed Agents in the Gemini API let a developer make a single API call that spins up an isolated Linux sandbox in the cloud. Inside that sandbox, the agent reasons, executes code, installs packages, manages files, and browses the web on its own. That capability already existed. What's new in this release is the control layer around it:
- Environment hooks run custom scripts or HTTP requests before or after supported sandbox operations, including code execution and file access. They can block or audit those operations, although they do not currently cover external MCP tools or custom functions.
- Budget controls cap total token consumption (input, output, and thinking tokens combined) with a max_total_tokens setting. When the cap hits, the run pauses in an "incomplete" state rather than failing outright, and the environment is preserved so work can resume.
- Scheduled triggers bind an agent, its environment, a prompt, and a cron schedule into a standing resource that runs on repeat, reusing the same sandbox so files persist between runs.
- Free-tier access means teams can try the pattern without a procurement conversation first.
- An Environments API lets developers list, inspect, and delete sandbox sessions instead of waiting out the default seven-day expiration.
By default, these sandboxes have unrestricted outbound network access, though teams can restrict it with an allowlist. Google's own documentation is direct about the rest: scope credentials to the minimum needed, and verify outputs before you act on them. That's not boilerplate. It's an admission that the model doing the work is not the thing that makes it safe to use.
Hooks Turn Oversight Into a Checkpoint, Not an Afterthought
The most interesting piece for a business reader is hooks, because it changes where oversight sits. Right now, most agent pilots review output after the fact. Someone reads the report, checks the code, or spot-checks the summary once the agent is done.
A pre-tool-execution hook moves that review earlier, into the moment before a supported sandbox action happens. It can approve or deny a code-execution or filesystem step, and if it denies the call, the model sees the rejection and can adjust. A post-tool-execution hook runs after the fact, for things like formatting, validation, or telemetry, but it can't undo an action that already happened.
This is a small technical detail with a real business implication. It reframes the governance question from "how do we review what the agent did" to "what should the agent never be allowed to do without an automated rule, or an external human-approval workflow, stopping it first." Hooks do not create a built-in human approval system on their own, but an external HTTP hook could connect to one. That's a question every leader running a pilot should be able to answer specifically, not generally. If you can't name three actions your agent should never take unsupervised, that's the gap to close before the hooks matter.
There is also an important limit: hooks are operational guardrails, not a complete security boundary. Google's documentation says invalid hook responses default to allow, and the practical setup matters. If hook configuration lives in a writable place inside the same environment, a sufficiently capable agent may be able to interfere with it. For stricter tamper resistance, the configuration needs to be protected, for example with read-only mounting or a controlled external endpoint.
Budget Controls Put a Ceiling on Runaway Loops
Agent tasks don't run at a fixed cost. Google's documentation says a single managed-agent interaction typically consumes 100,000 to 3 million tokens, and especially complex workflows can reach 3 to 5 million. On paid-tier projects, model tokens and tool usage are billed on a pay-as-you-go basis; Google says environment compute is not billed during preview. An agent stuck in a retry loop, or one that keeps expanding its own task list, can burn through a budget fast with nobody watching in real time.
A best-effort cap on total tokens is a blunt tool, but it's the right kind of blunt. Google's max_total_tokens control can stop an interaction with an "incomplete" status while preserving the work and environment for continuation, but it is not a strict dollar cap. Cached tokens do not count toward that limit, tool charges may still apply, and actual usage can slightly exceed the limit because checks happen between agent steps. For a pilot, the point is still useful: autonomous loops need an exit, because without one they don't reliably find their own.
Scheduled Triggers Change What "Pilot" Means
Binding an agent to a cron schedule turns it from a chat session someone runs deliberately into a recurring worker that acts on its own timetable, reusing the same environment and files each time. That's a meaningful shift. A one-off agent run gets reviewed because someone triggered it and is waiting on the result. A scheduled agent runs whether or not anyone is watching that day.
That raises the stakes for three things pilots often skip: clear ownership of the schedule, logging that a human actually reads, and a defined review cadence. A pilot that graduates from "let's try this" to "this runs every morning at 6am" has quietly become a small piece of production infrastructure, even if nobody called it that in the planning meeting.
Free-tier access lowers the cost of finding this out. It does not lower the need to find it out before the agent touches a real workflow. MIT NANDA's 2025 GenAI Divide report found that about 95% of the organizations in its dataset were seeing little or no measurable P&L impact from their GenAI initiatives. The report associated the divide less with raw model capability than with integration, workflow fit, adaptability, and organizational execution.
The Real Question Isn't "Should We Switch to Google"
It's tempting to read this update as a competitive move, and it is one. But the more useful takeaway for a business leader isn't about picking a vendor. It's that Google just published, in effect, a checklist of controls a serious buyer should expect from any agent platform: a way to gate actions before they happen, a way to cap runaway spend, a way to make recurring runs visible and ownable, and a low-cost way to test all of it before committing budget.
None of these controls make a pilot enterprise-ready by themselves. They make it more testable and more governable while it's still a pilot, which is exactly the stage where most of these programs currently break down.
Coursera next step: If this post has you thinking less about agent demos and more about the operating model around them, AI Governance from Oxford Saïd on Coursera is a useful next step. The course gives business leaders a clearer way to think about AI oversight, accountability, risk, and responsible adoption before pilots turn into recurring workflows.*
Closing Takeaway: Four Checks for This Week
Before your next agent pilot touches a real workflow, run these checks regardless of which platform you're using:
- Name the forbidden actions. List the specific tool calls or actions (file deletion, external sends, code execution, purchases) that should require a gate or human approval, and confirm your platform can actually enforce that gate.
- Set a run-level token budget. Confirm there is a token budget or other enforceable usage limit that can pause the agent, and separately confirm how tool charges, cached tokens, and any overage are controlled.
- Ask if anything runs on a schedule. If an agent is going to repeat without a person triggering it each time, assign an owner and a review cadence before it goes live, not after.
- Separate "cheap to test" from "safe to deploy." Free-tier or low-cost access is a reason to pilot faster, not a signal that the guardrails are already in place.
Sources
- Gemini API Managed Agents: 3.6 Flash, hooks, and more, Google, July 28, 2026
- Agents Overview, Google AI for Developers
- Hooks documentation, Google AI for Developers
- Antigravity Agent docs, Google AI for Developers
- Gemini Developer API pricing, Google AI for Developers
- The GenAI Divide: State of AI in Business 2025, MIT NANDA