Gemini API Managed Agents — 3.6 Flash, hooks, and more

Google‘s update to Managed Agents in the Gemini Interactions API: environment hooks, model selection, budget caps, cron triggers, an Environments API, and free-tier access. T3 — a first-party product announcement, promotional, with one customer testimonial standing in for evidence. Verified against the page rather than a summary; antigravity-preview-05-2026 is the real agent identifier, not a typo.

The pitch: “a single API call coordinates, reasoning, code execution, package installation, file management, and web retrieval inside an isolated cloud sandbox” — and, in the closing line, agents that run “without breaking your budget or requiring external orchestration.” That last clause is aimed at the layer this spoke spends most of its time documenting.

The managed-agent layer, and what you trade for it

Where an agentic-coding-harness runs the loop on your machine, a managed agent runs it in the vendor’s sandbox and hands you an API. Orchestration, package management, sandboxing and state persistence become someone else’s infrastructure — the same move kimi-claw makes from the model-lab side, here from the API side.

The cost of that trade is named more clearly by Google’s own customer than by Google. OffDeal’s CTO, on why they couldn’t validate the agent’s output before this release:

“Before agent hooks, we couldn’t do this on Gemini’s managed agents: the sandbox is remote, so our validation code had nowhere to run.”

That is the managed model’s central limitation in one sentence. Verification needs somewhere to execute, and handing the loop to a vendor takes that place away. The spoke’s whole verification thread assumes you can run a check next to the agent; a remote sandbox quietly removes the assumption. Hooks are Google selling back a slice of the control the managed model took.

Hooks: middleware, at the vendor layer

Drop .agents/hooks.json into the environment and the runtime fires your handlers on pre_tool_execution or post_tool_execution. The matcher field takes regular expressions — | for several tools, * for all. Handlers run as commands in the sandbox or as http POSTs to an external endpoint.

This is agent-middleware‘s before/after-each-tool-call hook points, implemented as a managed service. It’s also agent-guardrails in a specific shape: a pre_tool_execution script returning {"decision": "deny", "reason": "..."} skips the call and passes the rejection reason into the model’s context. The gate doesn’t just block, it explains — the agent learns why and can adapt. Read that against constraint-evading-behavior: telling a model precisely why it was denied is also telling it what would have passed, which is exactly the input that produces the letter-satisfying workaround. A guardrail that teaches is a guardrail that can be studied.

The OffDeal case is the concrete one: a post_tool_execution hook fires the moment their agent writes a company list, then fetches logo candidates, runs pixel-level quality checks, verifies each with Gemini vision, and publishes a manifest of approved files that are the only images allowed into the deck. That’s output-grounded verification wired into the loop as a tool-call side-effect, in production, by someone with a reason to care about correctness.

Budget as a third guardrail axis

max_total_tokens in agent_config caps input + output + thinking. Hit the cap and execution “safely pauses”, the interaction returns status: "incomplete", the environment state survives, and you resume by passing previous_interaction_id with a fresh budget. The sample sets 10,000.

agent-guardrails frames bounding an agent by reversibility and recovery cost. This adds a different axis — spend — and it’s the one an autonomous multi-turn loop actually needs, since the failure mode isn’t a destructive action but a run that quietly burns tokens forever. Pausing rather than aborting also makes it a durability feature: a budget limit and a resumable checkpoint are the same mechanism seen from two directions.

Scheduled, persistent, autonomous

A trigger binds an agent, an environment, a prompt and a cron schedule into a persistent resource, and “each run reuses the same sandbox, so files persist across executions.” The Environments API lists, inspects and deletes sandbox sessions, otherwise they expire on a 7-day TTL.

Recurring autonomous agents with a durable filesystem are a meaningful step past request/response — closer to the standing-worker shape in durable-agents and loop-engineering than to a chat completion. Nothing in the post addresses what a cron-scheduled agent with persistent state and web access does when it goes wrong, which is the question agent-guardrails would ask next.

Models and distribution

Default is Gemini 3.6 Flash (gemini-3.6-flash) for the antigravity-preview-05-2026 agent, no code change required; Gemini 3.5 Flash and 3.5 Flash-Lite are selectable via agent_config.model. Managed agents now run on free-tier projects without active billing — a distribution move, putting an autonomous sandboxed loop behind an API key with no card attached. The post also ships an agent skill for itself (npx skills add google-gemini/gemini-skills --skill gemini-interactions-api), which is the skills standard being used by a vendor to onboard agents onto its own API.

What it doesn’t say

No pricing figures, no execution-time or concurrency limits, no benchmark, and no security discussion of what an untrusted prompt can do inside a sandbox that has package installation and web retrieval. The single customer quote is the only outside evidence. Recorded as vendor claims about a preview.

agent-middleware · agent-guardrails · durable-agents · agentic-coding-harness · agent-loops-verification · constraint-evading-behavior · kimi-claw · adk · agent-orchestration · google · synthesis