Contents
Every team I have talked to about shipping an autonomous coding or research agent in production hits the same two walls: they cannot stop the agent from doing something dangerous mid-run without killing the whole sandbox, and they cannot cap how much a runaway loop will cost before it happens. Google’s Gemini API just shipped answers to both, and they are worth a close look because the design choices reveal how the industry is converging on the same guardrails independently.
The update to Managed Agents in the Gemini API makes Gemini 3.6 Flash the default model behind the Antigravity managed agent, and adds two features that matter far more than the model swap: synchronous environment hooks that can block or audit a tool call before it runs inside the remote sandbox, and a max_total_tokens spending ceiling that pauses a run instead of discarding it. Managed agents are also now usable on free-tier projects, so you can test all of this without a billing account attached.
Three details worth understanding
Hooks intercept tool calls, not just log them. A config file at .agents/hooks.json inside the sandbox defines two lifecycle events, pre_tool_execution and post_tool_execution, matched against tool names like code_execution, write_file, or delete_file with a regex. A pre_tool_execution hook can return {"decision": "deny", "reason": "..."}, and the agent pauses and waits synchronously for that verdict before the tool runs. Crucially, the denial reason is fed back into the model’s own context, so it can course-correct instead of just failing silently. Hooks fail open: a crashing script, a timeout, or a non-2xx response is treated as allow, so a broken audit script never deadlocks a production pipeline. The tradeoff is that hooks only see built-in sandbox tools, not custom function calls or external MCP servers, so they are not a complete security boundary on their own.
The spending ceiling preserves state instead of throwing it away. Passing max_total_tokens inside agent_config caps input, output, and thinking tokens combined. Hit the limit and the interaction returns status: "incomplete" with the sandbox still alive, so you resume it later by passing previous_interaction_id with a fresh budget rather than starting the whole task over. That is a meaningfully different failure mode than the hard-stop budget caps most agent frameworks ship today.
Scheduled triggers turn agents into cron jobs with memory. A trigger binds an agent, an environment, a prompt, and a cron schedule into a persistent resource, and every run reuses the same sandbox, so files written in one run are still there in the next. Combined with the Environments API for listing and cleaning up sandboxes early, instead of waiting on the default 7-day TTL, this closes a gap that used to require external orchestration.
Try the hooks gate yourself
Below is a simulation of how a pre_tool_execution hook evaluates a tool call against a hooks.json config. Nothing here calls a real sandbox; it mirrors the matcher and decision logic from the docs.
About the demo
This simulates the hook matcher and decision shape described in Google’s documentation, not a live Gemini API call.Pick a tool call and click Run.
Where this leaves agent builders
Anthropic shipped self-hosted environments and cross-session messaging for Claude Code just last week, and now Google ships synchronous tool-call interception and resumable budgets for Gemini’s managed agents. Neither vendor is copying the other; both are independently discovering that the hard part of production agents was never getting the model to call the right tool, it was building the seatbelt around the call. If you are running agents against untrusted repos or customer data today, the practical move is to stop treating hooks and budget ceilings as nice-to-haves and start treating them as the same non-negotiable layer you would put around any service account: deny by default on destructive operations, cap the spend, and make sure a crashed guardrail fails safe rather than fails open into silence.