Google is turning Managed Agents into scheduled workers with budgets and hooks

Google has expanded Managed Agents in the Gemini API with several controls that make long-running agents easier to operate as real software. Environment hooks can gate tool calls, token budgets can cap an agent's total consumption, scheduled triggers can reuse persistent sandboxes, and the Environments API can inspect or delete those sandboxes.

Since BTN's published version, Google has also changed the default model behind the Antigravity managed-agent runtime. Google's current Antigravity Agent documentation, last updated August 13, 2026, says `antigravity-preview-05-2026` now defaults to Gemini 3.7 Flash when `agent_config.model` is omitted; Gemini 3.6 Flash remains available as an explicit model choice. The earlier July 28 launch material had made 3.6 Flash the default.

That default-model change matters operationally because builders who rely on the implicit default can receive a capability and behavior change without changing the agent identifier or their own code. Google currently prices Gemini 3.7 Flash and 3.6 Flash at the same promotional standard API rate through December 31, 2026, so the switch does not itself raise the published per-token rate today, but it can still change task success, latency and total token usage.

Agent products are increasingly becoming runtime products. A strong model is only one part of the system; developers also need a place where the agent can work, limits on what it can spend, controls over what it can do and a reliable way to run the same task again later.

Google is bundling more of that operational layer into the Gemini API itself. A builder can ask a managed agent to work in an isolated environment, intercept file writes or code execution with custom checks, stop a run when a token budget is exhausted and schedule recurring work without first building a separate orchestration service.

The switch from Gemini 3.6 Flash to Gemini 3.7 Flash also makes model pinning part of runtime governance. If repeatability matters, relying on the managed agent's implicit default means Google can move the underlying model as the platform evolves. Explicitly selecting `agent_config.model`, and re-running production evaluations before changing it, gives teams a more stable operating baseline.

Environment hooks can run custom commands or HTTP handlers before or after tool execution inside the managed sandbox. A pre-tool hook can deny a write or code-execution action, while a post-tool hook can lint, inspect or audit what the agent just produced.

That matters because prompt instructions are not the same thing as enforcement. Telling an agent not to edit a protected file is weaker than placing a deterministic gate in front of the write operation. Hooks give teams a place to attach existing policy, security and quality checks without trying to teach every rule to the model.

Managed agents can be given a `max_total_tokens` budget covering input, output and thinking tokens. When a run reaches that limit, execution returns incomplete while preserving its environment and context so the developer can inspect or continue it with a fresh budget. Google notes that the limit is best-effort and actual usage can slightly exceed it between budget checks.

This is a small control with a large practical effect. Autonomous agents can take unexpected paths, repeat failed approaches or spend far more than a short interactive prompt. A hard budget makes cost part of the runtime contract rather than something discovered after the invoice arrives.

Google has also added scheduled triggers that bind an agent, prompt, environment and cron schedule together. Runs reuse the same sandbox, so files can persist between executions.

That makes Managed Agents relevant to recurring jobs such as dependency audits, periodic research, repository maintenance or report generation. Builders should still think carefully about idempotency, stale state and what happens when one scheduled run overlaps another, but the platform is clearly moving beyond request-response agents.

Google's July 28 announcement made Gemini 3.6 Flash the default model for the `antigravity-preview-05-2026` runtime. The current Antigravity Agent documentation, last updated August 13, now says the same agent defaults to `gemini-3.7-flash` when `agent_config.model` is omitted. Gemini 3.6 Flash, Gemini 3.5 Flash and Gemini 3.5 Flash-Lite remain selectable.

For builders, the important point is not just that the newer model is stronger. It is that the underlying default can change while the managed-agent identifier stays the same. Teams that need reproducible behavior should explicitly set the model and treat a model upgrade like any other production dependency change: evaluate it on real traces, then roll it out deliberately.

Antigravity Agent pricing is pay-as-you-go based on the underlying Gemini model tokens and the tools the agent uses. Google's current Gemini API pricing lists the same promotional standard rate for Gemini 3.7 Flash and Gemini 3.6 Flash through December 31, 2026: $0.75 per million input tokens and $3.75 per million output tokens, with published rates of $1.50 input and $7.50 output starting January 1, 2027.

The equal headline rate means the default move to 3.7 Flash does not by itself increase today's per-token price. Total task cost can still change if the newer model uses a different number of reasoning tokens, tool calls or retries, so production comparisons should measure end-to-end job cost rather than assuming equal token rates mean equal bills.