Put a Checkpoint in the Agent's Toolbox — Gemini's Managed Agents Now Let You Insert 'Halt, Inspect, Log' Around Every Tool Call
On July 28, 2026, Google added governance features to Managed Agents in the Gemini API. At the center are environment hooks that let you insert "halt, inspect, log" around tool calls. Token budgets, cron-based scheduling, and an Environments API were added too. The caveats for adoption are also laid
When you put autonomous AI agents into real production work, the scariest moment is the instant one "goes off and executes something on its own." On July 28, 2026, Google added a bundle of governance features to Managed Agents in the Gemini API — a managed agent execution environment where the cloud side takes care of the entire sandbox for you — designed to let you intervene at exactly that moment. At the center are "environment hooks," which let you slot your own logic in around the moments an agent calls a tool.
Slotting Your Own Checkpoint In Before and After a Tool Call
Environment hooks become active simply by writing configuration into .agents/hooks.json placed inside the sandbox. Every time an agent invokes a tool such as code execution or file writing, the developer's script runs immediately before and after that call and can vet its contents. The key points are as follows.
| Item | What it can do |
|---|---|
| Hook timing | Two kinds: pre_tool_execution (before execution) and post_tool_execution (after execution) |
| Specifying target tools | Matched by regular expression (e.g. code_execution|write_file, or * for all tools) |
| Handler types | command, which invokes a local script, and http, which passes to an external endpoint |
| How to deny | If a pre-execution hook returns {"decision": "deny", "reason": "…"}, that tool call is skipped and the reason is fed back into the model's context |
When denied, the agent doesn't simply stop; it receives "why it was rejected" and can try a different approach within the same conversation. The post-execution hook, meanwhile, is suited to sending the output to an external validation pipeline. In an example Google cited, one company mechanically checks the image quality of financial documents at the agent's output stage.
The Gap: "There Was Nowhere to Put Verification Code"
Why is this needed now? Because in Managed Agents the sandbox lives on the cloud side (remote), there was until now a plain and simple gap: "there was no place to run your own code to check an agent's actions from the side." Hooks provide exactly that — a foothold for verification and auditing inside the remote sandbox. Halting high-risk operations, running output through a linter or inspection, streaming activity logs to an in-house monitoring platform — these "practices of production operation" can now be brought inside the agent itself.
Three More Reins Added Outside the Hooks
This update adds other governance knobs as well.
| Feature | Details |
|---|---|
| Token budget | Set an upper limit on total consumption — including input, output, and thinking — with max_total_tokens. On reaching it, the agent pauses with status: "incomplete" and can be resumed via previous_interaction_id while preserving the environment's state |
| Scheduled-execution triggers | Bundle an agent, environment, prompt, and schedule with a cron expression to run automatically. Because it reuses the same sandbox, files written last time can be referenced next time |
| Environments API | List, inspect, and delete sandboxes from code. Instead of waiting out the 7-day time-to-live (TTL), you can explicitly clean up once processing is done |
Alongside this, the default model switched to Gemini 3.6 Flash for the antigravity-preview-05-2026 agent (changeable to 3.5 Flash and others via agent_config.model), and Managed Agents can now be tried even on the free tier of API keys that don't have billing enabled. Putting an inexpensive Flash-class model as the default can also be read as a design conscious of the token bill of keeping agents running.
Caveats to Keep in Mind Before Adopting
The governance features have grown, but they are not a cure-all. Here are some points to avoid overconfidence.
- Hooks only see the tools inside Google's sandbox. Client-side custom functions and calls made through remote MCP servers operate outside this hook's jurisdiction.
- An agent with write permission can rewrite the hook configuration itself. If you want it to be enforceable, mounting the configuration from a read-only repository is recommended.
- Get the halting wrong and production seizes up. Google urges a conservative failure design: "a broken linter or an unreachable telemetry server must not halt production." It also calls for operational practices such as placing authentication tokens in the network settings rather than in the hook file, and allowlisting external audit destinations in advance.
The lineup of hooks, budgets, scheduled execution, and environment management overlaps with the "reins to stop runaway behavior" that coding-agent vendors have each been adding separately. It looks like a move signaling that the focus of developer-facing AI is shifting from a stage of competing on model intelligence to how to safely embed autonomous agents into real work. The wider you extend the scope you entrust to an agent, the more the question becomes how to design the "checkpoint" that sits in front of it.
References: Google (Gemini API Managed Agents: 3.6 Flash, hooks, and more) / Unite.AI (Google Lets Developers Block Gemini Agents' Tool Calls) / GCN / The AI Navigator
