DEV Community: Google AI

Gemini 3.6 Flash & 3.5 Flash-Lite: Developer guide

Patrick Loeber — Tue, 21 Jul 2026 16:08:54 +0000

Gemini 3.6 Flash (gemini-3.6-flash) and Gemini 3.5 Flash-Lite (gemini-3.5-flash-lite) are generally available (GA) and ready for production use.

Gemini 3.6 Flash: Stronger performance on complex agentic and multimodal tasks while reducing token usage, at a lower price point than 3.5 Flash.
Gemini 3.5 Flash-Lite: The fastest, lowest-cost model in the 3.5 family. Outperforms prior Flash-Lite generations for high-throughput execution.

This guide explains what's new in each model, what API changes affect your code, and how to migrate.

Tip: You can automate this migration with a coding agent that supports skills (like Antigravity). Run /gemini-interactions-api migrate my app to Gemini 3.6 Flash

New models

Model	Model ID	Default thinking level	Pricing	Description
Gemini 3.6 Flash	`gemini-3.6-flash`	`medium`	$1.50/1M input tokens and $7.50/1M output tokens	Balances speed with intelligence for agentic and multimodal tasks.
Gemini 3.5 Flash-Lite	`gemini-3.5-flash-lite`	`minimal`	$0.30/1M input tokens and $2.50/1M output tokens	The fastest, lowest-cost 3.5 model for high-throughput execution.

Both models support the 1M token context window, 64k max output tokens, thinking, and the full suite of built-in tools including Computer Use.

For complete specs, see the model pages:

For detailed pricing, see the pricing page.

Quickstart

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.6-flash",
    input="Write a three.js script that renders an interactive 3D robot."
)

print(interaction.output_text)

What's new in Gemini 3.6 Flash

Token and turn reduction: Completes multi-step workflows with fewer reasoning steps, conversational turns, and tool calls than Gemini 3.5. It also reduces execution loop spiraling.
Improved code generation: Produces higher quality production-ready code with fewer unwanted edits and fewer debugging loops.
Better instruction following: Reduces unwanted file changes during diagnostic tasks.
Strong multimodal and spatial reasoning: Improved performance on chart interpretation, visual blueprint conversion, and multi-element web layout generation.
Upfront programmatic inspection: Prefers running diagnostic code scripts before making changes more frequently than Gemini 3.5 Flash. This improves accuracy on complex tasks, but can add extra exploratory steps on simple frontend work.
Computer Use support: Supported as native tool for agentic UI automation.
UI styling preference: Better at creating functional code, though human evaluators preferred earlier models for visual layout and styling. You can mitigate this by providing explicit design guidelines.
Default thinking effort (medium): Uses the same medium default thinking level as Gemini 3.5 Flash.
Reduced pricing: Lower output token costs ($7.50/1M vs. $9.00/1M for 3.5 Flash). Input tokens remain at $1.50/1M.

What's new in Gemini 3.5 Flash-Lite

Reduced task execution latency: Highest throughput in the 3.5 family for high-volume data parsing and document extraction.
Enhanced reasoning and multimodal performance: Strong migration path from Gemini 2.5 Flash, with higher scores on reasoning tasks like HLE (18.0% vs. 11.0%) and multimodal benchmarks like CharXIV (74.5% vs. 63.7%).
Subagent orchestration and tool reliability: Improves tool execution reliability for code execution, search, and MCP workflows. Increase the thinking level for autonomous planning and complex subagent tasks.
Improved document understanding: Improves accuracy on document parsing and structured data extraction. Experiment with both minimal and high thinking levels depending on document complexity.
Interactive web coding and tabular data processing: Performs strongly on frontend JavaScript and tabular data processing by planning via lightweight code execution.
Chatbot and persona persistence: Stronger multi-turn instruction following and persona consistency over Gemini 3.1 Flash-Lite.
Computer Use support: Supported as native tool for agentic UI automation.

Choosing the right Flash or Flash-Lite model

Use this table to select the right model and migration path for your workloads.

Both models require removing deprecated sampling parameters (temperature, top_p, top_k) and prefilled model turns. See API changes for details.

Model	Primary use cases	Recommended migration target
Gemini 3.6 Flash `gemini-3.6-flash`	Code generation, spatial/multimodal reasoning, multi-step agentic workflows	Gemini 3.5 Flash, Gemini 3 Flash (Preview), or Gemini 3.1 Pro
Gemini 3.5 Flash-Lite `gemini-3.5-flash-lite`	Autonomous subagent execution, high-volume data analysis and document extraction, structured JSON parsing	Gemini 3.1 Flash-Lite or Gemini 2.5 Flash

Updated Antigravity agent

Due to its improved performance, Gemini 3.6 Flash is now the new default model powering the Antigravity agent in Gemini Managed Agents. This can be changed by setting a new field on the API.

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="Read Hacker News, summarize the top 10 stories, and save the results as a PDF.",
    environment="remote",
)

print(interaction.output_text)

API changes and parameter updates

Starting with Gemini 3.6 Flash and Gemini 3.5 Flash-Lite, the following API changes apply to these models and all future Gemini model releases.

Sampling parameter deprecation: temperature, top_p, and top_k are deprecated. The API ignores these parameters and returns an error in future model generations.
Prefilled model turn validation: Prefilling model turns is no longer supported. If the last non-empty turn in the request is a model turn, the API returns a 400 error.

Below are detailed explanations and code samples for each API change.

1. Sampling parameter deprecation (`temperature`, `top_p`, `top_k`)

temperature, top_p, and top_k are deprecated and ignored. In future model generations, supplying these parameters returns an HTTP 400 error. Remove these parameters from all requests.

# ⚠️ Remove these parameters (deprecated)
generation_config = {
     "temperature": 0.7,
     "top_p": 0.9,
     "top_k": 40,
}

To improve determinism, define a system instruction with explicit rules for your
specific use case.

2. Prefilled model turn validation {:#prefilled-model-turn-validation}

API requests ending with a non-empty model role turn are disallowed and return an HTTP 400 Error.

⚠️ Avoid

In legacy generateContent or raw REST payloads, ending with a model role turn
is now disallowed:

/* ❌ DO NOT: End payload contents with a 'model' role turn */
{
  "contents": [
    {"role": "user", "parts": [{"text": "Translate 'Hello world' to Spanish."}]},
    {"role": "model", "parts": [{"text": "Translation:"}]}  /* ❌ Returns error */
  ]
}

✅ Recommended Migration (Interactions API)

In the Interactions API, model turns are not manually prefilled. If your application previously prefilled a model turn to suppress preambles or force JSON formatting, use system_instruction or Structured outputs instead.

# ✅ RECOMMENDED: Use system_instruction in the Interactions API to specify output format
interaction = client.interactions.create(
    model="gemini-3.6-flash",
    input="Translate 'Hello world' to Spanish.",
    system_instruction="Output only the translation without introductory text.",
)

Migration checklist

Tip: You can automate this migration with a coding agent that supports skills (like Antigravity). Run /gemini-interactions-api migrate my app to Gemini 3.6 Flash

Migrate to gemini-3.6-flash

Update Model ID: Change your target model string to gemini-3.6-flash.
Remove deprecated sampling parameters:
- Strip temperature, top_p, and top_k from generation configs.
- Replace thinking_budget with the string enum thinking_level set to "medium" or "high".
- Remove candidate_count (unsupported in Gemini 3.x).
Enforce turn validation rules:
- Standardize multi-turn conversations on server-side previous_interaction_id.
- Remove prefilled model turns.
Audit function calling:
- Place multimodal assets inside the response payload.
- Format inline instructions using \n\n.
- If you see Malformed_Function_Call errors tied to pre-tool text, see Workarounds for pre-tool text requirements.
- Only if using generateContent API: Ensure all FunctionResponse objects include call_id and name.
Baseline Gemini 3.x requirements: For SDK updates and thought signature preservation, see the Gemini 3.5 Migration Checklist.

Migrate to gemini-3.5-flash-lite

Update Model ID: Change your target model string to gemini-3.5-flash-lite.
Configure thinking effort level:
- For high-volume extraction, routing, or classification: leave thinking_level at "minimal" (default) for maximum throughput.
- For autonomous subagents with tool calls, code execution, or multi-step reasoning: set thinking_level to "medium" or "high" to prevent premature tool termination.
Remove deprecated parameters and validate function calling: Apply the same rules as for 3.6 Flash above.
Baseline Gemini 3.x requirements: Refer to the Gemini 3.5 Migration Checklist.

Next steps

Review API specs on the Models Overview.
Explore multi-agent orchestration in the Interactions API Guide.
Test and refine prompts in Google AI Studio.
Read the blog post, including info on the new Gemini 3.5 Flash Cyber model

Google Cloud Labs: Accelerate AI with Cloud Run

Shir Meir Lador — Tue, 21 Jul 2026 13:00:00 +0000

Moving Beyond the Prototype

The AI landscape has shifted. While "vibe coding" with tools like Antigravity and AI Studio lets you build and deploy complex agents in minutes, the real work begins on "Day 2". Moving from a magical prototype to a hardened, production-grade application requires professional AI engineering. We're excited to bring back the Accelerate AI with Cloud Run roadshow for 2026. This year, we've updated our curriculum to focus on the full AI agent lifecycle, giving you the keys to productionizing and scaling agentic workloads on Google Cloud's serverless platform.

The Coffee Shop Journey: A Hands-On Experience

Experience the ease of building advanced AI agents on Cloud Run through 'The Coffee Shop Journey'. This interactive session is designed to guide you through the full lifecycle of an AI agent, moving beyond prototyping to focus on real business use cases. You will solve real-world business problems as you evolve from launching a simple cafe to building complex, intelligent assistants.

Our curriculum covers the core pillars of modern AI development:

The Basics: Gain familiarity with Cloud Run by deploying a simple web app (a Coffee Shop launch scenario) to understand the platform fundamentals.
Build a Coffee Recommendation Agent: Create a personalized AI assistant using Google's Agent Development Kit (ADK) and Retrieval-Augmented Generation (RAG).
Optimize Coffee Stand Locations: Use Gemma 4 and the BigQuery MCP server to identify the most profitable locations for new coffee stands by analyzing popular bike routes.
Personal Productivity Assistant for Store Managers: Create a personal productivity assistant using Cloud Run to help a coffee shop manager with daily operational tasks and scheduling.
Master Advanced Features with Antigravity 2.0: Learn how to use skills, context, rules, and hooks with Antigravity 2.0 to build new features for your Cloud Run applications.

Production-Grade AI on Cloud Run

Get first-hand experience with the platform innovations that make Cloud Run the ideal home for production-grade agentic workloads. Through hands-on exercises, you will learn to build, scale, and orchestrate long-running agents using Google's ADK and Antigravity 2.0. Additionally, you will utilize BigQuery MCP for automated, data-driven expansion strategies, and experience low-latency inference for frontier models using Cloud Run's GPU offerings without the traditional overhead of cluster management.

Ready to Build for Scale? Join us in North America

Don't just witness the AI revolution - build it. Find the workshop in your city and secure your spot today! Let's transform your AI journey from a simple prototype into a powerful, production reality.

City	Date	Registration Link
Atlanta, GA (as a part of Atlanta Tech week)	August 12-13	https://www.renderatl.com/tickets Event tickets grant access to the workshops on a first-come, first-served basis.
Sunnyvale, CA	August 13	Register now!
Toronto, Canada	August 27	Register now!
Seattle, WA	September	Registration opens late July!
New York City, NY	October	Registration opens late July!
Los Angeles, CA	November	Registration opens late July!
Boston, MA	October	Registration opens late July!
Washington D.C.	October	Registration opens late July!

Registration Update: Links for our September, October, and November workshops will be added to this page in late July. Stay tuned!

What is an "agentic harness," actually?

Tilde A. Thurium — Thu, 16 Jul 2026 21:19:20 +0000

I've been hearing the word "harness" thrown around a lot lately. I assumed it just meant "the IDE" or "whatever app is running your agent." Turns out, it goes a little deeper than that.

So I sat down with @greggyb and asked him to explain it from the ground up: what an LLM actually does, what turns it into an agent, and where the harness fits into all of it.

What's in the video

Simon Willison's definition of an agent: an LLM with tools, running in a loop to accomplish a goal
What "tools" really means under the hood, and how function calling lets an LLM pull in context it wasn't trained on
The loop part: how an agent programmatically checks its own output to decide if it's actually done
Why the harness is everything after the LLM, and why that's a different thing than the interface
Why you can swap interfaces without touching the underlying harness, and why some agents don't need a UI at all

The point that stuck with me is the harness isn't the app you're looking at. It's the invisible plumbing deciding whether the agent keeps going or calls it done.

Did your mental model of "harness" match up? Or were you picturing something else too?

DiffusionGemma: The Developer Guide

Gemini Team — Thu, 16 Jul 2026 14:27:09 +0000

Following our announcement in our launch blog post, we are sharing this developer guide to help you understand, serve and customize this experimental model.

Built on the Gemma 4 backbone, DiffusionGemma introduces several milestones for developer workflows:

Compute-bound parallel generation: Bypasses memory-bandwidth limitations by shifting the bottleneck to compute, delivering up to 4x faster token generation on GPUs (up to 700+ tokens per second on NVIDIA GeForce RTX 5090 and 1000+ tokens per second on a single NVIDIA H100).
Bidirectional context & self-correction: Uses bidirectional attention to evaluate the entire text block simultaneously during generation, enabling real-time error correction and parallel context propagation.
Developer-friendly sizes: Designed as a 26B Mixture of Experts (MoE) model that activates only 3.8B parameters during inference, allowing quantized deployment within 18 GB VRAM limits.

The Architecture

For developers building with traditional LLMs on GPUs, the primary bottleneck is memory bandwidth. Autoregressive language models must repeatedly load model weights from memory to generate text one token at a time. DiffusionGemma bypasses this limitation by shifting the bottleneck from memory bandwidth to compute, generating and refining a 256-token canvas in parallel. By providing the GPU with a large parallel workload, it utilizes tensor cores that would otherwise sit idle during local serving.

Uniform State Diffusion: Instead of predicting tokens sequentially, DiffusionGemma starts with a canvas of random placeholder tokens and iteratively refines them in parallel. Over multiple denoising passes, highly confident tokens help resolve adjacent positions, causing the entire sequence to snap into focus.
Block Autoregressive Diffusion for Variable Length Generation: For sequences longer than 256 tokens, once a 256-token block is fully denoised, the model processes and commits it to the KV cache. The model then transitions to the next block, initializing a fresh 256-token canvas conditioned on the previously committed history. This combines parallel block speed with the sequential stability of autoregressive models.

Showcase: Solving Sudoku with Parallel Denoising

Traditional autoregressive models struggle with strict, multivariable constrained problems like Sudoku. Because they generate text strictly from left to right, they cannot evaluate future placeholders or backtrack.

To demonstrate customization of DiffusionGemma, we are releasing a fine-tuning recipe and results using Hackable Diffusion, a modular JAX research toolbox. This training setup focuses on a classic multi-variable grid task: the Sudoku Solver.

Why Sudoku is Interesting for Diffusion

In an 81-character Sudoku string representation (where empty cells are marked with periods), every digit is bound by strict intersecting horizontal, vertical, and 9x9 grid constraints.

Bidirectional Context Propagation: Unlike autoregressive models, DiffusionGemma's denoising step allows every canvas query to attend to all positions in parallel. Information flows symmetrically across the board, resolving global dependencies in each step.

Error Correction via Re-Noising: Under Uniform State Diffusion, the model evaluates the entire board simultaneously. If confidence drops, the sampler replaces digits with random ones, allowing for continuous self-correction.
Efficient Early Stopping: Fine-tuning on Sudoku shows that adapters enhance early stopping. The SFT-tuned model stabilizes faster than the base model, allowing the engine to halt sooner, reducing latency and compute costs.

controls
loop
muted
autoplay
playsinline
width="100%"
style="border-radius: 8px; display: block; margin-bottom: 0; padding-bottom: 0px;"
aria-label="">

Your browser does not support the video tag.

Left: DiffusionGemma generating Sudoku output. The base model is unable to solve the Sudoku after 48 steps. Right: Fine-tuned (SFT) DiffusionGemma solves the puzzle after 12 steps. It is able to complete early thanks to adaptive stopping.

The Performance Impact: While the base DiffusionGemma model is not specifically trained to solve Sudoku puzzles (~0% success rate), applying the simple JAX SFT recipe on a Sudoku dataset raises correctness to 80% success, while decreasing the overall inference step count.

Block Autoregressive Denoising

To enable block autoregressive denoising, DiffusionGemma alternates between incremental prefill and denoising during inference:

Prefill / Incremental Prefill (Causal): Uses causal attention to ingest the prompt context and write to the KV cache. This runs once to prefill the initial context and then once per block to append each finalized 256-token canvas to the KV cache before proceeding to denoising the next canvas.
Denoising (Bidirectional): Uses bidirectional attention to iteratively denoise the canvas. Query tokens at any position on the canvas can attend to all other canvas tokens (as well as KV cache), letting the model process context bidirectionally.

This architectural choice makes the following possible:

Global Context Awareness: Unlike autoregressive (AR) models that only "look backward," the Denoiser's bidirectional attention allows every token on the canvas to attend to every other token. This makes the model much more effective at solving non-sequential problems, such as Sudoku, where a digit in the first cell must respect constraints in the last cell.
Self-Correction: Because the model iteratively refines the whole canvas, it can "fix" earlier mistakes. If a token's confidence drops during a pass, the sampler can re-noise and replace it. This is a capability AR models lack since they are "stuck" with a token once it is generated, especially during long output sequences.
Efficient Long-Context Scaling: The "block-autoregressive" approach allows the model to handle long sequences. It combines the parallel speed of diffusion for blocks with the proven sequential stability of AR models for long-form text.
Simplified Deployment: Using the same architecture as the Gemma 4 26B A4B model means developers only need to implement a denoising step, making it easier to integrate into existing serving frameworks like vLLM.

Serving DiffusionGemma

To serve this experimental architecture efficiently, we worked with the vLLM team to implement DiffusionGemma into vLLM. This integration allows the engine to run the iterative parallel denoising loops efficiently across batched request streams.

Developers can deploy DiffusionGemma out of the box using vLLM's standard OpenAI-compatible local server.

vllm serve google/diffusiongemma-26B-A4B-it \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --gpu-memory-utilization 0.85 \
  --attention-backend TRITON_ATTN \
  --generation-config vllm \
  --hf-overrides '{"diffusion_sampler": "entropy_bound", "diffusion_entropy_bound": 0.1}' \
  --diffusion-config '{"canvas_length": 256}' \
  --enable-chunked-prefill

Getting Started Today

Ready to explore the frontier of non-autoregressive text generation? Take a look at the following resources to find out more:

Download the Weights: Access the weights of the experimental model (released under the Apache 2.0 license) directly on Hugging Face.
Integrate & Learn: Review the Visual Guide to DiffusionGemma to understand the mechanics of text-based diffusion models. Read more about DiffusionGemma in the Gemma documentation.
Use Your Favorite Inference Frameworks: Run the model efficiently using vLLM, Hugging Face Transformers, SGLang, and MLX.
Adapt & Fine-Tune: For rapid experimentation, we are releasing the official training recipes using Hackable Diffusion You can also explore efficient fine-tuning using Unsloth or NVIDIA NeMo.
Deploy Your Way: Instantly deploy on Google Cloud using Model Garden or via NVIDIA NIM. The model is optimized natively across the hardware stack from consumer RTX 4090 and 5090 cards to enterprise Hopper and Blackwell servers.

DiffusionGemma: 4x faster text generation

Gemini Team — Tue, 14 Jul 2026 15:06:56 +0000

Our newest open experimental model delivers up to 4x faster inference on dedicated GPUs and opens the door to exploring speed-critical, interactive local workflows.

Introducing DiffusionGemma, an experimental open model that explores text diffusion, an exceptionally fast approach to text generation. Released under an Apache 2.0 license, this 26B Mixture of Experts (MoE) model moves beyond the sequential token-by-token processing of typical autoregressive Large Language Models (LLMs). Instead, it generates entire blocks of text simultaneously, delivering up to 4x faster text generation on GPUs.

Built upon the industry-leading intelligence-per-parameter of our Gemma 4 family and cutting-edge Gemini Diffusion research, DiffusionGemma integrates a novel diffusion head designed to maximize generation speed. While autoregressive Gemma 4 models remain the standard for high-quality production outputs, DiffusionGemma is designed for researchers and developers exploring speed-critical, interactive local workflows such as in-line editing, rapid iteration, and generating non-linear text structures.

Unlocking new value for developers

Developers building real-time interactive AI applications often struggle with the latency bottlenecks of local inference. DiffusionGemma addresses these challenges directly, with some key trade-offs:

Blazing fast inference: By shifting the decode bottleneck from memory-bandwidth to compute, DiffusionGemma generates up to 4x faster token output on dedicated GPUs. (1000+ tokens per second on a single NVIDIA H100, 700+ tokens per second on NVIDIA GeForce RTX 5090).¹
Accessible hardware footprint: Operating as a 26B total Mixture of Experts (MoE) model that activates only 3.8B parameters during inference, DiffusionGemma fits comfortably within 18GB VRAM limits of high-end dedicated consumer GPUs when quantized.
Bi-directional attention: Generating 256 tokens in parallel with each forward pass allows every token to attend to all others. This provides significant advantages for non-linear domains such as in-line editing, code infilling, amino acid sequences or mathematical graphs.
Intelligent self-correction: The model iteratively refines its own output, allowing it to evaluate the entire text block at once to fix mistakes in real-time.
Experimental status & production recommendations: Because it prioritizes speed and parallel layout generation, DiffusionGemma’s overall output quality is lower than standard Gemma 4. For applications that demand maximum quality, we recommend deploying standard Gemma 4.

You can improve DiffusionGemma's performance on specific tasks through fine-tuning. In the example below, Unsloth fine-tuned DiffusionGemma to play Sudoku — a task autoregressive models struggle with because each token depends on future tokens. DiffusionGemma's bi-directional attention makes this much easier.

Fine-tuned DiffusionGemma solving Sudoku.

Why diffusion for text?

While the AI research community has explored diffusion-based text generation for years, applying it to large models has remained a challenge. DiffusionGemma changes this by shifting how models use hardware.

The trade-off with traditional models

Most language models act like a typewriter, generating one token at a time from left to right. In the cloud, this is efficient because servers can batch thousands of user requests together to share the hardware load. But when run locally for a single user, this word-by-word process leaves your dedicated GPU or TPU underutilized — it spends most of its time simply waiting for the next "keystroke."

DiffusionGemma reverses this inefficiency. Instead of predicting words sequentially, it drafts an entire 256-token paragraph simultaneously. By giving the computer's processor a larger chunk of work at once, DiffusionGemma utilizes your hardware to its full potential. It upgrades your model inference from a single, sequential typewriter to a massive printing press that stamps the entire block of text simultaneously.

controls
loop
muted
autoplay
playsinline
width="100%"
style="border-radius: 8px; display: block; margin-bottom: 0; padding-bottom: 0px;"
aria-label="DiffusionGemma text-to-3D SVG demo by Hugging Face. Step-by-step generation, slowed down for visualization.">

Your browser does not support the video tag.

DiffusionGemma text-to-3D SVG demo by Hugging Face. Step-by-step generation.

This means DiffusionGemma's speedup is designed for local and low-concurrency inference. In high-QPS cloud serving, autoregressive models can be deployed to saturate compute efficiently, so DiffusionGemma's parallel decoding offers diminishing returns and can result in higher serving costs. The throughput advantage is strongest at low-to-medium batch sizes on a single accelerator.

How text diffusion works

Similar to AI image generators that start with visual static and iteratively refine it into a clear picture, DiffusionGemma applies this to text:

The canvas: The model starts with a canvas of random placeholder tokens.
Iterative refinement: The model makes multiple passes, locking in correct tokens and using them as context clues to refine the rest.
Final polish: The text converges into high-quality output.

controls
loop
muted
autoplay
playsinline
width="100%"
style="border-radius: 8px; display: block; margin-bottom: 0; padding-bottom: 0px;"
aria-label="DiffusionGemma Process">

Your browser does not support the video tag.

Because the model can process the whole paragraph while generating, it unlocks new patterns of model behavior, like perfectly closing complex markdown formatting or generating and rendering code in near real-time.

Get started today

Download the weights: Access the experimental model weights (released under a permissive Apache 2.0 license) right now on Hugging Face.
Integrate & learn: Learn more in our DiffusionGemma developer guide. Or deep dive into A Visual Guide to DiffusionGemma to understand the mechanics under the hood.
Use your favorite development tools: Serve the model efficiently using MLX, vLLM (with integration supported by Red Hat), and Hugging Face Transformers. For rapid experimentation, we are releasing a fine-tuning tutorial using Hackable Diffusion, a modular JAX toolbox designed for composability. You can also explore fine-tuning with Unsloth and NVIDIA NeMo. Additionally, official support for llama.cpp is arriving soon.
Experience optimized performance: We worked with NVIDIA to optimize across their hardware stack, ensuring compatibility with consumer setups (quantized for GeForce RTX 5090 and 4090 GPUs) alongside high performance on enterprise systems (Hopper and Blackwell using advanced NVFP4 kernels), including NVIDIA DGX Spark and DGX Station for local deskside deployment, and RTX PRO for AI professionals. Native support for NVFP4 (4-bit floating-point) accelerates compute throughput, allowing the model to run at faster speeds with near-lossless accuracy.
Try your way: Run on your desktop dedicated GPU or in the cloud through Gemini Enterprise Agent Platform Model Garden or NVIDIA NIM.

The (no longer) missing multi-agent pattern: triggering dynamic workflows from an agent

Remigiusz Samborski — Tue, 14 Jul 2026 09:57:26 +0000

When building multi-agent systems, rigid state graphs quickly fall apart in the face of dynamic user inputs. Imagine building a smart assistant: a user hands you a checklist of three household chores today, but tomorrow it might be a list of ten software debugging tasks. Because the number of tasks, their sequence, and their execution details are entirely runtime-dependent, you cannot hardcode this path at design time. Forcing dynamic lists of work into a static graph-based workflow can lead to fragile, over-engineered code. You need a workflow that adapts dynamically at runtime.

The Google Agent Development Kit (ADK) provides a flexible programming model to define dynamic workflows. With the release of ADK 2.4.0, triggering these workflows has become even more seamless: you can register a Workflow directly in an agent's tools list, allowing the coordinator agent to execute it automatically as a first-class tool.

In this article, you learn how to configure and trigger a dynamic workflow directly from a coordinator agent. This guide uses a task list coordination example, but you can adjust this pattern to other dynamic orchestration needs.

The architecture of a dynamic workflow

Static workflows define the execution path at design time. Dynamic workflows, however, allow agents to invoke tools, spawn other nodes, and schedule sub-agents conditionally at runtime.

The system consists of three main components:

Root agent (root_agent): Gathers the list of tasks from the user, requests final approval, and directly calls the tasks_workflow tool.
The workflow (tasks_workflow): A Workflow that iterates over the approved tasks.
Sub-agent (task_explainer): An Agent tasked with generating a step-by-step execution plan for each task.

Here is the architectural diagram of the solution:

Technical implementation

Let's break down how to implement this solution using the Google ADK library in Python. The complete code resides in the devrel-demos repository with core logic in the agent.py file.

1. Initialize the environment and model

First, import the required ADK modules and set up the Gemini model. This example uses gemini-3.5-flash with Gemini Enterprise Agent Platform APIs:

import os

import google.auth
from google.adk import Agent, Context, Event, Workflow
from google.adk.apps import App
from google.adk.models import Gemini
from google.adk.workflow import node
from google.genai import types

# ==============================================================================
# Initialize the environment
# ==============================================================================
_, project_id = google.auth.default()
if project_id:
    os.environ["GOOGLE_CLOUD_PROJECT"] = project_id
os.environ["GOOGLE_CLOUD_LOCATION"] = "global"
os.environ["GOOGLE_GENAI_USE_VERTEXAI"] = "True"

# ==============================================================================
# Model Definition
# ==============================================================================
model = Gemini(
    model="gemini-3.5-flash",
    retry_options=types.HttpRetryOptions(attempts=3),
)

2. Define the sub-agent

The sub-agent task_explainer takes a task description and writes a step-by-step execution plan:

task_explainer = Agent(
    name="task_explainer",
    model=model,
    instruction="""
    You are a task execution planner subagent.
    Given a task description, write a short, step-by-step execution plan
    explaining how you would perform the task. Be concise and clear.
    """,
)

3. Implement the dynamic workflow node

To support dynamic execution, define two functions decorated with @node. First node accepts the parent context ctx and a list of task strings. This is the main node that iterates over the list of tasks and explains them:

@node(rerun_on_resume=True)
async def task_workflow_node(ctx: Context, node_input: list[str]):
    """Workflow that iterates over the list of tasks and explains them."""
    for task in node_input:
        # Yield progress update
        yield Event(message=f"⏳ Starting task: {task}...")  # type: ignore

        # Dynamically trigger subagent
        explanation = await ctx.run_node(task_explainer, node_input=task)
        explanation_content = getattr(explanation, "text", None) or str(explanation)

        # Mark as done
        yield Event(
            message=(
                f"✅ Task Done: {task}\n\n"
                f"**Execution Explanation:**\n{explanation_content}"
            )  # type: ignore
        )

The second node is just returning a message that all tasks were completed. It’s used here to demonstrate a sequential workflow execution:

@node
async def task_workflow_end(ctx: Context):
    yield Event(message="🎉🚀 All tasks executed successfully! ✨")  # type: ignore

4. Define the workflow

Next, define the Workflow object. A Workflow consists of nodes and directed edges between them. Since ADK 2.4.0, a Workflow can be registered directly as a first-class tool for an agent. To do so, make sure to define the name, description, and input_schema so the parent agent knows how to call it. Whereas edges describes the order of workflow steps execution:

tasks_workflow = Workflow(
    name="tasks_workflow",
    description="Iterates over the list of tasks and explains them.",
    input_schema=list[str],
    edges=[
        ("START", task_workflow_node, task_workflow_end),
    ],
)

5. Define the root coordinator agent

Finally, the root_agent coordinator manages user interaction. The agent collects the list of tasks, asks for confirmation, and, once approved, executes the tasks_workflow directly. Notice how we pass tasks_workflow directly to the tools array:

root_agent = Agent(
    name="root_agent",
    model=model,
    instruction="""
    You are a task coordinator agent.
    Your goal is to gather a list of tasks that the user wants to execute.
    Talk to the user to gather the list of tasks.
    Once you have a list of tasks, present them clearly to the user and ask
    for their final approval to execute them.
    Do NOT execute anything until the user explicitly approves.
    Once the user approves the list of tasks, call the tool `tasks_workflow` with
    the list of tasks.
    """,
    tools=[tasks_workflow],
)

Testing the flow locally

You can run and test this agent locally using the agents-cli playground.

If you haven't already installed agents-cli and its skills, run the setup command:

   uvx google-agents-cli setup

Clone and enter the demo directory:

   npx -y giget@latest gh+git:google/adk-samples/python/agents/workflow-dynamic workflow-dynamic 
   cd workflow-dynamic

Install required packages::

   agents-cli install

Start the playground:

   agents-cli playground

Interact with the Agent:
- Open http://localhost:8080 in your browser.
- Select app from the dropdown list at the top.
- Type a list of tasks in the chat box. For example:
```
 1. Empty the trash.
 2. Feed the dog.
 3. Do the laundry.
```

The coordinator agent lists the tasks and asks for your approval.
Once you reply with "Yes" or "Approved", the tasks_workflow tool fires.
The playground console streams live updates as tasks_workflow iterates through each task and returns plans generated by the task_explainer sub-agent.

Screencast demo

The following screencast demonstrates the working solution:

Summary

Dynamic workflows in Google ADK allow agents to perform complex, runtime-determined orchestrations. By leveraging Workflow and the @node decorator, you can build adaptable multi-agent applications that respond to dynamic requirements.

Continue exploring:

Thanks for reading

If you found this article helpful, please consider sharing it with your friends on socials.

I'm always eager to share my learnings or chat with fellow developers and AI enthusiasts, so feel free to follow me on LinkedIn, X or Bluesky.

How your sample data impact vector tests in PostgreSQL and AlloyDB.

Gleb Otochkin — Tue, 14 Jul 2026 04:44:34 +0000

Introduction

If you are using vector data in PostgreSQL on Cloud SQL or AlloyDB, you probably use some benchmark queries or functions to check your vector search performance. From time to time, I see people performing speed benchmarks or quality testing using generated, fully synthetic data. The main goal, after all, is to test, for example, performance with a particular data type and get some comparable numbers. Does it really matter what data I have in my vector column?

It really depends, and things can indeed go very wrong when you try to evaluate the index’s performance. I use synthetic data all the time for my tests. But it depends on what I am testing. In some cases, real vs. synthetic data might have a significant impact on the results. Let me show you how it can change the outcome of some tests for the vector data type in PostgreSQL.

Two datasets

Some tests can be done using fully synthetic data. For example, if you test inserts, updates, or deletes for vectors, then synthetic data works for you. In such cases, I usually create a fully synthetic dataset of totally random, normalized number arrays. Here is an example of a simple function and how to generate the dataset.

-- Create a function 
CREATE OR REPLACE FUNCTION generate_random_vector(dimensions integer)
RETURNS vector
LANGUAGE sql
AS $$
    SELECT array_agg(random()*2-1)::vector
    FROM generate_series(1, dimensions);
$$;
-- Creating the test table with vector data type 768 dimensions
CREATE TABLE tvectr768(
id BIGINT PRIMARY KEY,
d VECTOR(768)
);
-- Populate the table with 1M or fows
INSERT INTO tvectr768 (id, d)
SELECT
    i AS id,
    -- This function is now called for each row
    generate_random_vector(768) AS d
FROM
    generate_series(1, 1000000) AS i;

In the end, we have a table with 1 million vectors. Each vector dimension value is between -1 and 1. So, the vector is normalized and shows more or less the same behaviour for the DML operations as normally generated embedding for a piece of content.

But when I test recall quality or performance for vector search, I use one of the publicly available datasets with vectors created based on real data. You can find multiple datasets for embeddings on Hugging Face or other sources. For example, you can check the Cohere Labs datasets here: https://huggingface.co/CohereLabs/datasets.

Here are my 1M rows with the same dimensions and structure, but all the vectors in those rows are based on real data.

pgdata=# \d tvreal768
               Table "public.tvreal768"
 Column | Type | Collation | Nullable | Default
--------+-------------+-----------+----------+---------
 id | bigint | | |
 d | vector(768) | | |

pgdata=#

Both tables have the same size and structure.

pgdata=# SELECT
pgdata-# relname AS table_name,
pgdata-# pg_size_pretty(pg_table_size(relid)) AS table_size
pgdata-# FROM
pgdata-# pg_catalog.pg_statio_user_tables
pgdata-# WHERE
pgdata-# relname IN ('tvectr768', 'tvreal768');
 table_name | table_size
------------+------------
 tvectr768 | 4008 MB
 tvreal768 | 4008 MB

If you go a bit deeper, you can see that both tables are about 57 MB in heap size, plus 3950 MB in TOAST where the actual vector data is stored. It makes perfect sense, since the d column with vector(768) is larger than the default 2k threshold and is stored entirely in the TOAST segment.

pgdata-# relname AS table_name,
pgdata-# pg_size_pretty(pg_relation_size(oid)) AS heap_size,
pgdata-# pg_size_pretty(pg_table_size(oid) - pg_relation_size(oid)) AS toast_size
pgdata-# FROM pg_class
pgdata-# WHERE relname = ANY ('{"tvectr768" ,"tvreal768"}')
pgdata-# AND relkind = 'r';
 table_name | heap_size | toast_size
------------+-----------+------------
 tvectr768 | 57 MB | 3950 MB
 tvreal768 | 57 MB | 3950 MB

Let us do some performance tests and compare the results.

Building Vector Index

For my tests, I was using Postgres 18 on a Debian VM in Google Cloud, and AlloyDB Omni for ScaNN index tests on a VM of the same size. We are mostly interested in the difference between “real” and synthetic vector values, but this varies depending on the index. The first test is to build an IVFFLAT index on our vectors.

Here is an example for the IVFFLAT index on synthetic vector data.

drop index if exists tvectr768_d_idx;
CREATE INDEX ON tvectr768 USING ivfflat (d vector_cosine_ops) WITH (lists=1000);

You can see I was using default parameters, specifying only the number of lists. According to my tests, it takes about 271,068 ms to build the index on the synthetic tvectr768 table. And when it is built, the size of the index is roughly equal to the size of all the vectors (3912 MB), which makes total sense.

When we run the same for the tvreal768 table with real vectors, we get similar results: 271,788 ms. So far, there is no difference. And it is probably expected if we think about how the IVFFLAT index is being built with splitting to buckets according to the number of lists and then simply moving each vector to one or another bucket.

What about the HNSW index? Here is an example of a query used to build the HNSW index.

drop index if exists tvectr768_d_idx;
CREATE INDEX ON tvectr768 USING hnsw (d vector_cosine_ops);

And here we start to see the difference in performance. The HNSW is a graph-based index and it is much harder to find node connections for a totally random array of numbers. You can play with different build parameters for the index and see how it can impact the results.

For the building with default parameters it took on average 6601789 ms for synthetic data and 4174196 ms for the “real” vectors. That’s 1.5 faster for the real data and it is significant.

So, why is it happening? How does the randomness in the numbers in the vector impact the performance? It probably deserves a separate article but I will try to give a short explanation. The HNSW builds its graph incrementally. When it adds another vector to the index it has to search for the right place in the graph. It means to find the closest neighbors to connect the new vector to. HNSW relies on the assumption that your data contains some underlying structure and it means clusters, patterns, and dense neighborhoods. The embedding vectors have but the random vector most likely not. Because of that the build process has to evaluate more candidates to find neighbors. That process is mathematically expensive for distances like cosine distance and takes time. That’s a short explanation but I hope it helps to understand to some extent the reasons behind the difference in built time.

With the ScaNN index we have another case of striking difference between building time for index with fully synthetic vs “real” dataset. I was using the basic recommended parameters for the ScaNN index according to the guide for AlloyDB Omni.

BEGIN;
SET LOCAL scann.num_leaves_to_search = 1;
SET LOCAL scann.pre_reordering_num_neighbors=50;
drop index if exists tvreal768_d_idx;
CREATE INDEX tvreal768_d_idx ON tvreal768 USING scann (d cosine) WITH (num_leaves = 1000);
END;

It took 237094 ms to build the index on the synthetic data vs only 62673 ms on the “real” dataset. And the size of indexes was quite different because AlloyDB ScaNN was using internal index optimization for the real dataset. We have 1562 MB for the synthetic data index vs 275 MB for the “real” one.

So, when you start to evaluate performance in building indexes then you probably should use proper data or you can get misleading results. I would recommend using vectors built on your actual data.

Vector Search Performance

Now that we have our ANN indexes built, we can evaluate how quickly you can find the top 5 similar vectors using the HNSW index. I am using a procedure that takes 100 samples from the table and uses some of those samples as predicates to find the 5 most similar vectors. I repeated this 11 times, discarding the first execution. This gives me the throughput in Queries Per Second (QPS) and the average execution time per query, along with the max and min times for all executions. You can check the procedure benchmark_vector_search in the Appendix chapter and the end of the article or download it from GitHub.

Here is a sample output from the procedure.

NOTICE: ------------------------------------------------------------------------
NOTICE: Benchmark finished successfully.
NOTICE: Total queries executed: 1000 (excluding warmup)
NOTICE: Total execution time: 2.145 seconds (excluding warmup)
NOTICE: Throughput (overall): 466.1 QPS (excluding warmup)
NOTICE: ------------------------------------------------------------------------
NOTICE: Latency Stats (excluding warmup):
NOTICE: Average: 2.125 ms
NOTICE: Minimum: 1.389 ms
NOTICE: Maximum: 3.888 ms
NOTICE: ------------------------------------------------------------------------

When we run our tests, it shows 4.173 ms on average for synthetic data vs. 2.102 ms for our “real” vectors using HNSW index. Interestingly enough, for AlloyDB ScaNN, the difference is not so big — only 5.958 ms vs. 5.161 ms if we use 1,000 lists. But if we use an index with only 100 lists, we can see a significant difference in performance, where the response time for synthetic data is 7.239 ms vs. 4.249 ms for the “real” ones.

The reasons behind the difference in performance have the same nature but slightly different consequences. Since the random vector lacks clusters and dense neighborhoods it goes through more steps to find the closest neighbours. Instead, for example going through 32 nodes to find the closest neighbour it has to traverse 256 or more and even in such a case the quality might be still low.

So, if you are testing HNSW, which is widely used in the community, the 2x difference is big enough and fully justifies the effort of getting a real dataset.

Vector Search Quality

We already established that synthetic data can mislead you about build time or vector search speed for your vector indexes. What about quality?

Usually, when we talk about vector search quality, we use the term “recall,” which represents the percentage of exact matches returned by an ANN index compared to the list of hits returned by a KNN exact search. For example, we do a KNN search returning the top 10 similar vectors. Then, we run exactly the same query with an ANN index and compare how many of the 10 vectors returned by the ANN search match the KNN results. If it is 9 out of 10, then it is 90% recall.

In my procedure evaluate_vector_recall, I use 100 random samples from the dataset and then iterate on those samples to get the recall for each of them, averaging the results at the end. I tested it with the top 10 similar vectors (k_param=>10). The procedure is provided in the Appendix and on GitHub.

Here is a sample output of the procedure.

pgdata=# call evaluate_vector_recall('tvreal768',768,k_param=>10);
NOTICE: Starting vector similarity search recall evaluation...
NOTICE: Target table: tvreal768, Expected dimensions: 768
NOTICE: Parameters - Vector Column: d, ID Column: id, K: 10, Sample Size: 100
NOTICE: Selecting 100 random vectors for sampling from tvreal768...
NOTICE: ------------------------------------------------------------------------
NOTICE: Recall Evaluation Finished.
NOTICE: Total queries evaluated: 100
NOTICE: Average Recall@10: %91.80
NOTICE: Minimum Recall@10: %0.00
NOTICE: Maximum Recall@10: %100.00
NOTICE: ------------------------------------------------------------------------
CALL

According to my test results, the recall for synthetic data is quite low. On average for the 100 samples, I am getting only 3.8% recall using HNSW, while for “real” data, the recall is 91.8%. This means our search on synthetic data is not only slow but also hugely inaccurate. When we try it using the AlloyDB ScaNN index, it shows 16.4% recall for synthetic data vs. 91.4% for the “real” data. Only IVFFLAT didn’t show itself good with the real dataset giving only about 51.9% recall on average. But the quality with synthetic data was still much worse than that — only 10.6%

Of course, your test results can and most likely will be different, but the trend is clear. Even if ScaNN shows slightly better results for a synthetic vector search, it is still quite misleading and inaccurate.

You also can opt-in to use the evaluate_query_recall procedure coming with the AlloyDB Omni and it gives you the option to measure recall. Read more in the official guide on how to use the procedure.

Conclusion

Here is my short summary for all the tests and results

Synthetic vectors can be used for pure performance DML tests where the vectors are not used as predicates and are only used to fill up space. For example, for inserts, updates, or deletes of rows filtered by non-vector column data.
Synthetic vector data shows incorrect results for index build times and can mislead testers by giving inaccurate results. So far, in most of my tests, synthetic data required more time to build the index compared to realistic vector data.
An ANN vector search executed against a synthetic dataset can be 1.5 times slower than for a similar dataset with realistic vectors.
Recall quality for an ANN vector search cannot be measured against synthetic vectors. In my tests, the recall quality ranged from 3.8% to 16.4%, depending on the index type and index parameters. The real dataset showed more than 90% recall for most of the tests.
Get a real dataset and use it for all your performance and quality testing for ANN indexes.

Appendix

Here are some procedures I used for testing. I don’t pretend they are perfect in any way but should be clear enough for everyone who tries to use it. I used some hardcoded values to make it simpler to read. Both procedures are available on GitHub.

Here is the procedure to check response time for vector search. It is using cosine distance for measurement and takes the first 100 vectors from the table as a sample to be used later.

CREATE OR REPLACE PROCEDURE benchmark_vector_search(
    n_repetitions integer,
    table_name_param text,
    vector_dimensions integer
)
LANGUAGE plpgsql
AS $$
DECLARE
    -- Array to hold the 100 vectors sampled for the benchmark run
    sample_vectors vector[];
    -- Variable to hold the current vector being searched for
    current_vector vector;
    -- Variables for timing
    overall_start_time timestamptz;
    overall_end_time timestamptz;
    repetition_start_time timestamptz;
    q_start timestamptz;
    q_end timestamptz;
    q_diff double precision; -- in milliseconds

    -- Metrics tracked across the entire benchmark
    global_min_latency double precision := 1e9;
    global_max_latency double precision := 0;
    global_sum_latency double precision := 0;
    overall_total_queries integer := 0;

    -- Variable for dimension validation
    actual_dimensions integer;
    actual_sample_size integer;

    -- Loop counter
    i int;
BEGIN
    RAISE NOTICE 'Starting vector similarity search benchmark...';
    RAISE NOTICE 'Target table: %, Repetitions: %, Expected dimensions: %', table_name_param, n_repetitions, vector_dimensions;

    -- Validate that the vector column "d" exists and dimensions match
    BEGIN
        EXECUTE format('SELECT vector_dims(d) FROM %I WHERE d IS NOT NULL LIMIT 1', table_name_param)
        INTO actual_dimensions;

        IF actual_dimensions IS NULL THEN
            RAISE EXCEPTION 'Could not find any non-NULL vectors in table %. The table might be empty or column "d" contains only NULLs.', table_name_param;
        END IF;

        IF actual_dimensions != vector_dimensions THEN
            RAISE EXCEPTION 'Vector dimension mismatch. Expected dimension %, but found dimension % in table %.', vector_dimensions, actual_dimensions, table_name_param;
        END IF;
    EXCEPTION
        WHEN undefined_table THEN
            RAISE EXCEPTION 'Table "%" does not exist.', table_name_param;
        WHEN undefined_column THEN
            RAISE EXCEPTION 'Table "%" does not have a column named "d".', table_name_param;
    END;

    RAISE NOTICE 'Dimension validation successful.';

    -- Fetch 100 random vectors to use as search queries
    RAISE NOTICE 'Selecting 100 random vectors for sampling from %...', table_name_param;
    EXECUTE format('SELECT array_agg(d) FROM (SELECT d FROM %I WHERE d IS NOT NULL ORDER BY random() LIMIT 100) AS random_sample', table_name_param)
    INTO sample_vectors;

    IF sample_vectors IS NULL OR COALESCE(array_length(sample_vectors, 1), 0) = 0 THEN
        RAISE EXCEPTION 'Could not retrieve any sample vectors. The table % might be empty or all vectors are NULL.', table_name_param;
    END IF;

    actual_sample_size := array_length(sample_vectors, 1);
    IF actual_sample_size < 100 THEN
        RAISE WARNING 'Could not retrieve 100 sample vectors. Using % available sample vectors instead.', actual_sample_size;
    END IF;

    RAISE NOTICE 'Starting main benchmark loop...';
    overall_start_time := clock_timestamp();

    -- The main outer loop that repeats the entire test (warmup + N repetitions)
    FOR i IN 0..n_repetitions LOOP
        repetition_start_time := clock_timestamp();

        -- Reset overall_start_time to start of repetition 1 to exclude warmup duration from QPS/Totals
        IF i = 1 THEN
            overall_start_time := clock_timestamp();
        END IF;

        DECLARE
            rep_min_latency double precision := 1e9;
            rep_max_latency double precision := 0;
            rep_sum_latency double precision := 0;
            rep_queries integer := 0;
            rep_duration double precision;
        BEGIN
            -- The inner loop that iterates through each of the sampled vectors
            FOREACH current_vector IN ARRAY sample_vectors
            LOOP
                q_start := clock_timestamp();
                -- Perform the core operation (limiting to top 5)
                EXECUTE format('SELECT 1 FROM %I ORDER BY d <=> $1 LIMIT 5', table_name_param)
                USING current_vector;
                q_end := clock_timestamp();

                q_diff := extract(epoch from (q_end - q_start)) * 1000.0; -- milliseconds

                -- Accumulate local statistics
                IF q_diff < rep_min_latency THEN rep_min_latency := q_diff; END IF;
                IF q_diff > rep_max_latency THEN rep_max_latency := q_diff; END IF;
                rep_sum_latency := rep_sum_latency + q_diff;
                rep_queries := rep_queries + 1;
            END LOOP;

            -- Calculate total time for this repetition
            rep_duration := extract(epoch from (clock_timestamp() - repetition_start_time));

            IF i = 0 THEN
                -- Warmup iteration: report it but do not add to global statistics
                RAISE NOTICE 'Warmup Repetition: Avg Latency = % ms (Min: % ms, Max: % ms) | QPS: %', 
                             round((rep_sum_latency / rep_queries)::numeric, 3), 
                             round(rep_min_latency::numeric, 3), 
                             round(rep_max_latency::numeric, 3),
                             round((rep_queries / rep_duration)::numeric, 1);
            ELSE
                -- Accumulate global statistics
                IF rep_min_latency < global_min_latency THEN global_min_latency := rep_min_latency; END IF;
                IF rep_max_latency > global_max_latency THEN global_max_latency := rep_max_latency; END IF;
                global_sum_latency := global_sum_latency + rep_sum_latency;
                overall_total_queries := overall_total_queries + rep_queries;

                RAISE NOTICE 'Repetition %/%: Avg Latency = % ms (Min: % ms, Max: % ms) | QPS: %', 
                             i, n_repetitions, 
                             round((rep_sum_latency / rep_queries)::numeric, 3), 
                             round(rep_min_latency::numeric, 3), 
                             round(rep_max_latency::numeric, 3),
                             round((rep_queries / rep_duration)::numeric, 1);
            END IF;
        END;
    END LOOP;

    overall_end_time := clock_timestamp();

    -- Log overall summary metrics
    DECLARE
        total_benchmark_time double precision;
        overall_qps double precision;
    BEGIN
        total_benchmark_time := extract(epoch from (overall_end_time - overall_start_time));
        overall_qps := overall_total_queries / total_benchmark_time;

        RAISE NOTICE '------------------------------------------------------------------------';
        RAISE NOTICE 'Benchmark finished successfully.';
        RAISE NOTICE 'Total queries executed: % (excluding warmup)', overall_total_queries;
        RAISE NOTICE 'Total execution time: % seconds (excluding warmup)', round(total_benchmark_time::numeric, 3);
        RAISE NOTICE 'Throughput (overall): % QPS (excluding warmup)', round(overall_qps::numeric, 1);
        RAISE NOTICE '------------------------------------------------------------------------';
        RAISE NOTICE 'Latency Stats (excluding warmup):';
        RAISE NOTICE ' Average: % ms', round((global_sum_latency / overall_total_queries)::numeric, 3);
        RAISE NOTICE ' Minimum: % ms', round(global_min_latency::numeric, 3);
        RAISE NOTICE ' Maximum: % ms', round(global_max_latency::numeric, 3);
        RAISE NOTICE '------------------------------------------------------------------------';
    END;
END;
$$;

And here is the procedure where I measure recall quality. It takes recall from each sample and then calculates an average recall quality for the entire execution.

CREATE OR REPLACE PROCEDURE evaluate_vector_recall(
    table_name_param text,
    vector_dimensions integer,
    vector_col_param text DEFAULT 'd',
    id_col_param text DEFAULT 'id',
    k_param integer DEFAULT 5,
    sample_size_param integer DEFAULT 100
)
LANGUAGE plpgsql
AS $$
DECLARE
    -- Array to hold the vectors sampled for the recall evaluation
    sample_vectors vector[];
    -- Variable to hold the current vector being searched for
    current_vector vector;
    -- Arrays to hold the result IDs from exact and approximate searches
    exact_ids text[];
    approx_ids text[];
    -- Metrics variables
    overlap_count integer;
    vector_recall double precision;
    sum_recall double precision := 0.0;
    min_recall double precision := 1.0;
    max_recall double precision := 0.0;
    actual_dimensions integer;
    actual_sample_size integer;
    total_queries integer := 0;
BEGIN
    RAISE NOTICE 'Starting vector similarity search recall evaluation...';
    RAISE NOTICE 'Target table: %, Expected dimensions: %', table_name_param, vector_dimensions;
    RAISE NOTICE 'Parameters - Vector Column: %, ID Column: %, K: %, Sample Size: %', 
                 vector_col_param, id_col_param, k_param, sample_size_param;

    -- Validate vector column exists and dimension matches
    BEGIN
        EXECUTE format('SELECT vector_dims(%I) FROM %I WHERE %I IS NOT NULL LIMIT 1', 
                       vector_col_param, table_name_param, vector_col_param)
        INTO actual_dimensions;

        IF actual_dimensions IS NULL THEN
            RAISE EXCEPTION 'Could not find any non-NULL vectors in column % of table %. The table might be empty or contains only NULLs.', 
                            vector_col_param, table_name_param;
        END IF;

        IF actual_dimensions != vector_dimensions THEN
            RAISE EXCEPTION 'Vector dimension mismatch. Expected dimension %, but found dimension % in table %.', 
                            vector_dimensions, actual_dimensions, table_name_param;
        END IF;
    EXCEPTION
        WHEN undefined_table THEN
            RAISE EXCEPTION 'Table "%" does not exist.', table_name_param;
        WHEN undefined_column THEN
            RAISE EXCEPTION 'Column "%" does not exist in table "%".', vector_col_param, table_name_param;
    END;

    -- Validate ID column exists
    BEGIN
        EXECUTE format('SELECT %I FROM %I LIMIT 1', id_col_param, table_name_param);
    EXCEPTION
        WHEN undefined_column THEN
            RAISE EXCEPTION 'ID column "%" does not exist in table "%". Cannot measure recall.', 
                            id_col_param, table_name_param;
    END;

    -- Select random sample vectors (ignoring nulls)
    RAISE NOTICE 'Selecting % random vectors for sampling from %...', sample_size_param, table_name_param;
    EXECUTE format('SELECT array_agg(%I) FROM (SELECT %I FROM %I WHERE %I IS NOT NULL ORDER BY random() LIMIT $1) AS random_sample', 
                   vector_col_param, vector_col_param, table_name_param, vector_col_param)
    INTO sample_vectors
    USING sample_size_param;

    IF sample_vectors IS NULL OR COALESCE(array_length(sample_vectors, 1), 0) = 0 THEN
        RAISE EXCEPTION 'Could not retrieve any sample vectors. The table % might be empty or all vectors are NULL.', table_name_param;
    END IF;

    actual_sample_size := array_length(sample_vectors, 1);
    IF actual_sample_size < sample_size_param THEN
        RAISE WARNING 'Could not retrieve % sample vectors. Using % available sample vectors instead.', 
                      sample_size_param, actual_sample_size;
    END IF;

    -- Iterate through sampled vectors to calculate recall
    FOREACH current_vector IN ARRAY sample_vectors
    LOOP
        -- 1. Find exact nearest neighbors (ground truth) by forcing sequential scan
        SET LOCAL enable_indexscan = off;
        SET LOCAL enable_bitmapscan = off;
        EXECUTE format('SELECT array_agg(%I::text) FROM (SELECT %I FROM %I ORDER BY %I <=> $1 LIMIT $2) AS exact_search', 
                       id_col_param, id_col_param, table_name_param, vector_col_param)
        INTO exact_ids
        USING current_vector, k_param;

        -- 2. Find approximate nearest neighbors (allowing index scan)
        SET LOCAL enable_indexscan = on;
        SET LOCAL enable_bitmapscan = on;
        EXECUTE format('SELECT array_agg(%I::text) FROM (SELECT %I FROM %I ORDER BY %I <=> $1 LIMIT $2) AS approx_search', 
                       id_col_param, id_col_param, table_name_param, vector_col_param)
        INTO approx_ids
        USING current_vector, k_param;

        -- 3. Calculate overlap
        IF exact_ids IS NOT NULL AND approx_ids IS NOT NULL THEN
            SELECT COUNT(*) INTO overlap_count
            FROM unnest(approx_ids) a
            JOIN unnest(exact_ids) e ON a = e;

            vector_recall := overlap_count::double precision / k_param;
            sum_recall := sum_recall + vector_recall;

            IF vector_recall < min_recall THEN min_recall := vector_recall; END IF;
            IF vector_recall > max_recall THEN max_recall := vector_recall; END IF;

            total_queries := total_queries + 1;
        END IF;
    END LOOP;

    -- Print recall report
    IF total_queries > 0 THEN
        RAISE NOTICE '------------------------------------------------------------------------';
        RAISE NOTICE 'Recall Evaluation Finished.';
        RAISE NOTICE 'Total queries evaluated: %', total_queries;
        RAISE NOTICE 'Average Recall@%: %%%', k_param, round(((sum_recall / total_queries) * 100.0)::numeric, 2);
        RAISE NOTICE 'Minimum Recall@%: %%%', k_param, round((min_recall * 100.0)::numeric, 2);
        RAISE NOTICE 'Maximum Recall@%: %%%', k_param, round((max_recall * 100.0)::numeric, 2);
        RAISE NOTICE '------------------------------------------------------------------------';
    ELSE
        RAISE WARNING 'No recall queries were successfully evaluated.';
    END IF;
END;
$$;

Context bankruptcy: The case for strategic forgetting for AI Agents

James O'Reilly — Fri, 10 Jul 2026 14:12:20 +0000

Most of us have seen a coding agent fail to complete a task we know it can do. We just don't understand the inconsistency in quality and lazily chalk it up to the "non-deterministic" nature of AI. What you might not realize is that the agent isn't failing because of intelligence, it's failing because its context is cluttered with noise.

To fix this, we need to shift from context maximizing to deterministic pruning. Here is what you will get out of this deep dive to help you build those boundaries:

Why feeding an agent your entire repository causes agent reasoning failures.
How to navigate brownfield codebases by isolating subsystems for agents.
How to dynamically mask dead code before launching an agent turn.
The essentials for a reliable pruning harness.
Why unconstrained context bloats PRs and burns out reviewers.

In computer architecture, thrashing occurs when an executing process demands more memory than the caches can hold. The processor stops executing useful instructions and spends all its resources swapping pages of memory in and out of RAM.

Coding agents have a similar bottleneck inside their prompt windows. With brownfield development, it might be tempting to dump the whole legacy codebase into context and prompt "refactor this to Next.js" (Read my article How to automate modernization with Antigravity and multi-agent orchestration to learn why this is a bad idea and what to do instead). However, if you do dump the whole codebase into context the agent is more likely to confuse dead code and old library usage as current intent.

You've reached context bankruptcy when the context actively degrades reasoning accuracy.

The visibility trap and why more context breaks reasoning

Some developers treat complete repository ingestion as a headline feature of the large context windows of frontier models. They assume comprehensive visibility equals deep understanding. It doesn't.

In clean greenfield projects, broad context ingestion works but in a multi-million-line legacy codebase, broad context ingestion adversely impacts an agent's ability to reason.

Most of us don't work on greenfield apps and many work inside messy poorly documented legacy codebases they inherited. They typically contain gems like folders named "v1-alpha", temporary helper scripts that are no longer usable or reflect current code, and orphaned feature flags. When an agent sweeps this data into context via naive RAG sweeps or massive context windows, it treats outdated patterns as current engineering truth.

The rule driving this failure is Hyrum's Law applied to AI context windows: with sufficient ingestion breadth, every observable historical implementation detail will eventually be depended upon by an autonomous model.

Give an agent access to 1,000 files and it will reason over your hackiest workarounds. It anchors on deprecated helper scripts and replicates tech debt into new modules.

Selective ignorance and how to enforce the boundary

When I review a legacy monolith I'm not familiar with, I don't read every file.

I practice selective ignorance and deliberately ignore most of the repository when building a mental model around the module I want to modify. I do this by treating the surrounding subsystems as if they were black boxes bounded by strict contracts.

The agent execution environments should model this behavior.

Addy Osmani recently documented context rot (the measurable performance dip models experienced as prompt windows fill) and agentic engine optimization (AEO) (formatting codebase documentation). Our industry remains obsessed with ingestion pipelines and larger token limits. Nobody is building harness infrastructure designed to force strategic forgetting.

To protect agent reasoning we must shift our engineering effort from context maximization to deterministic pruning.

If the agent sees the whole repository, you aren't scaling engineering velocity. You're scaling cognitive debt.

Pruning harnesses versus context bankruptcy

I treat context budget allocation as an architectural constraint because strategic forgetting requires replacing broad ingestion with deterministic pruning.

The contrast between unbound ingestion and strategic forgetting is significant.

Architectural Dimension	Unbound Ingestion (Context Bankruptcy)	Strategic Forgetting (Pruning Harness)
Ingestion Strategy	Global vector RAG sweeps or broad context dumping across `*/`	Dynamic AST pruning scoped strictly to active dependency graphs
Legacy Conflict Resolution	Ingests competing API wrappers; model hallucinates hybrid syntax	Hides deprecated subsystems; enforces single active contract
Prompt Capacity	85%+ context budget consumed by historical boilerplate and dead code	<15% context budget consumed; working memory preserved for execution
Reasoning Stability	High susceptibility to context rot; attention allocation dilutes over noise	High attention concentration; deterministic diff generation
Verification Overhead	High cognitive load; engineers scrutinize massive diffs for side effects	Minimal cognitive load; diffs match expected five-line boundary

Architectural context pruning is not an optimization step. It is a baseline reliability prerequisite. If an autonomous agent can read deprecated internal modules, it will eventually depend on them.

Models are probabilistic which makes them unreliable at deterministic access controls. Simply refining a prompt to instruct the model to ignore sections of a large codebase will fail under complex reasoning loads. This is because models will attend to tokens inside their prompt windows regardless if those tokens are no longer relevant to the project.

To guarantee selective ignorance, implement a muted repo pattern which dynamically manipulates repository visibility before launching an agent turn. Here's how it works…

1. Map active dependency graphs

Run a static Abstract Syntax Tree (AST) parse starting from the target entry file. Generate a strict allowlist containing only immediate upstream imports and downstream consumers.

2. Dynamically create ignore masks

Write an ephemeral .antigravityignore, .geminiignore, .claudesignore or .cursorignore file before the agent turns. Mask out archive/, deprecated helpers, and unrelated domain packages.

3. Use interfaces as substitutes for implementation

Replace complex external database wrappers and legacy integrations with clean interfaces or OpenAPI stubs. Force the model to code against these interfaces.

4. Launch scoped agent turns

Execute the agent prompt inside the pruned sandbox. This enables the model to work with focused attention free of historical distraction.

Essential implementation components

Building a deterministic pruning harness relies on three core components.

1. Runtime CLI file gating

Modern agentic IDEs maintain persistent workspace indexes so I avoid editing .antigravityignore, .geminiignore, .claudesignore or .cursorignore dynamically per agent turn because overwriting ignore manifests trigger file-watcher invalidation events. When that happens the machine rebuilds codebase indexes in a race condition against the model's first token.

To avoid editing the ignored files each agent turn, one option is passing file allowlist flags directly into your terminal command when launching the agent (agy --add-dir src/auth/dir). Or, if building a custom harness, pass allowed file arrays into your tool execution APIs in memory.

# .claudesignore .cursorignore .geminiignore .antigravityignore
# Force strategic forgetting in brownfield repositories

**/node_modules/
**/dist/
**/build/

# Gated Legacy Systems - Block the agent from historical noise
/legacy/v1-alpha/
/deprecated-soap-wrappers/
**/*.deprecated.ts

# Large static assets that trigger context thrashing
**/*.json
**/*.csv
package-lock.json
pnpm-lock.yaml

# Block the agent from analyzing un-verifiable dark matter code
/e2e/stale-tests-2022/

2. Hybrid semantic dependency mapping

Do not rely on naive vector embeddings to select codebase context. Vector similarity retrieves semantically similar code which can pick up unwanted legacy code.

Pure static AST tree-shaking would likely fail in brownfield monoliths because legacy systems lie at compile time. I'm thinking about systems that run on Java reflection, dependency injection containers, and runtime module loaders. For example, a shallow AST transversal would miss dynamically injected resources leading to dependency pruning causing runtime exceptions.

Instead, combine shallow AST parsing with recent observability outputs or runtime error logs to discover dynamic runtime dependencies before gating context windows. If runtime telemetry proves verify.ts calls legacy-sql-pool.js via DI reflection, include legacy-sql-pool.js in the allowlist. If static analysis and runtime traces both show zero execution paths to deprecated-auth.ts, keep it out of the allowlist.

3. Differential verification gating

Brownfield architecture is typically handled by isolating complexity behind interfaces. For example, modifying a billing service doesn't require you to read connection pool source code.

We can apply this thinking to agent prompt windows. By replacing deep internal library code with lightweight interface definitions, the model receives the correct contract specifications without ingesting implementation noise.

I do want to point out however, that in legacy systems interfaces may lie. It's the runtime side effects that are the real source of truth. If you do decide to stub code to save tokens during generation, be sure to enforce a differential verification gate. That way, success can be measured by passing tests against the legacy runtime, not the contract stubs.

How Antigravity implements pruning

Since I work at Google on Antigravity, I wanted to share my knowledge of how Antigravity implements isolation natively:

Subagent context isolation: Antigravity separates exploration from execution. The main agent has the ability to dynamically generate subagents which will have their own isolated context buffers and instructions from the main agent. The main agent may decide to delegate token-heavy or codebase-wide operations to subagents and keep the primary execution memory clean.
Planning mode checkpoints: Enforce explicit planning artifacts (/plan) so reviewers verify implementation design decisions and verification strategy before code generation.

Vigilance fatigue

Unconstrained context ingestion doesn't just degrade model reasoning, it also has a toll on people. I know when I review lengthy and broad, machine-generated diffs it triggers vigilance fatigue.

Reviewing code submitted by one of my colleagues is different from reviewing AI-generated code because I have less trust that basic architectural boundaries have been honored. I end up scrutinizing every line of code to verify the edit represents intentional business logic and not accidental side effects caused by historical noise.

As reviews grow in size and number, my attention struggles. It becomes increasingly difficult to avoid rubber-stamping bloated pull requests. Strategic forgetting helps protect reviewers by limiting the agent's reach.

Tuesday morning checklist

Most engineering organizations measure AI maturity by counting deployed subagents or tracking token consumption volume. In my opinion, both are vanity indicators.

True agentic scaling requires shifting focus from ingestion maxing to isolation discipline. Audit your agent workflows against three deterministic pruning heuristics:

Enforce small diff boundaries: If a localized bug fix generates PRs touching more than two files, halt execution. Your agent isn't being thorough, it's probably distracted by unrelated legacy code..
Treat ignore manifests as dynamic build artifacts: Don't maintain .antigravityignore files manually. Compile ignore manifests dynamically before agent turns combining AST import traversal with runtime trace telemetry (observability/error logs) so dynamic dependency injection paths stay unmasked.
Sandbox dependencies behind contract stubs: If an agent can read implementation source code for external SDKs or shared database wrappers, hide it. Use interface definitions or OpenAPI contract stubs instead.

Your agent headcount matters less than your isolation boundaries.

Additional resources

Here are a few other agentic brownfield development resources:

Article: How to automate modernization with Antigravity and multi-agent orchestration
Codelab: Automating legacy modernization at scale using agentic pipelines and Antigravity

Help others find this post.

Share this post with your friends on socials.
Follow me on LinkedIn or X for more content like this.

Thanks for reading!

The Antigravity Loop: From Chat to Autonomous Engineering

Romin Irani — Fri, 10 Jul 2026 07:18:37 +0000

How to go from pair-programming with AI to fully hands-off autonomous engineering and when each mode actually shines

Infographic generated by NotebookLM

Introduction

Here’s a scenario most developers know: you’re building a feature, and you ask an AI assistant to help. You type a prompt, read the response, type another prompt, read, type, read. Twenty exchanges later, the feature works. Your fingers are tired, but you’re happy.

Now imagine a different scenario: you write a single, detailed brief, like handing a spec to a senior engineer and walk away. You come back 30 minutes later to find the feature fully implemented, tested, deployed, and documented. Your fingers barely moved.

Both of these are real ways to work with Google Antigravity. The first is Chat Mode , which is conversational, interactive, real-time. The second is Goal Mode , which is autonomous, hands-off, mission-driven.

Most developers live exclusively in the first. This post will show you when, why, and how to use the second mode i.e. the Goal mode and to get there with the right kind of requirements. This post is not about which mode is better than the other, rather it is an exploration of which modes are best suited to which scenarios.

What Exactly Are These Modes?

Before diving into examples, let’s be precise about what each mode means in Antigravity:

Chat Mode (The Default)

You type a message. The agent responds. You type again. The conversation proceeds turn by turn. The agent might edit files, run commands, or search the web, but it waits for your input after each step. You see every change as it happens and can redirect immediately.

Think of it like: Pair programming with a colleague sitting next to you. You’re both looking at the screen, talking through every decision.

Planning Mode (The Middle Ground)

When you ask for something architecturally significant, Antigravity automatically shifts into planning mode. It researches your codebase, creates a detailed implementation_plan.md artifact, and presents it with a "Proceed" button. Nothing changes in your code until you approve. After approval, it executes the plan and creates a walkthrough artifact, summarizing what it did.

Think of it like: Hiring a contractor. They survey the site, give you a detailed quote and plan, and only start work after you sign off.

Goal Mode (/goal)

You prefix your prompt with /goal. The agent enters a persistent execution loop: research → plan → execute → verify → fix → repeat. It doesn't stop to ask you questions. It handles errors on its own. It may spawn sub-agents for parallel work. It only reports back when it's done (or when it's genuinely stuck and needs human input).

Think of it like: Assigning a ticket to a senior engineer. You write the requirements, set the acceptance criteria, and check back when you get the “PR ready for review” notification.

The Spectrum of Autonomy

These modes aren’t a binary switch, they’re a dial:

For each of the above modes, let us look at Human control v/s Agent autonomy, as shown below:

Another way to understand these modes is to understand what the roles of a human v/s Agent are i.e. who is in control during a specific mode and what is each mode best suited for.

Example 1: Chat Mode — Quick Fixes and Exploration

When to use: The task is trivial, you want to learn something, or you’re not sure what you want yet.

Scenario A: Fix a Bug

Fix the typo in README.md — "recieve" should be "receive"

What happens: The agent makes the single edit and shows you the diff. Done in a few seconds (hopefully). No plan, no artifact, no ceremony.

Scenario B: Understand Your Code

Explain how the authentication middleware works in server.js. 
Walk me through the flow step by step.

What happens: The agent reads the file, locates the middleware, and gives you a clear explanation with references to the relevant functions. It doesn’t change anything — it’s pure exploration. This is something Goal Mode may not be good at, since there is no “deliverable” to verify.

Scenario C: Brainstorm Ideas

What are some ways I could improve the onboarding flow in this app? 
The current sign-up takes 4 steps.

What happens: The agent analyzes your codebase, understands the current flow, and proposes improvements with rationale. This is inherently interactive, you want to react, ask follow-ups, and refine. Chat mode is perfect.

Why Chat Mode Is Right Here

These tasks share a common trait: you can’t pre-specify the outcome. You don’t know what the agent will say about your code. You don’t know which brainstormed ideas will resonate. You need to see intermediate results before deciding what’s next.

Rule of thumb: If the next step depends on seeing this step’s output, use chat.

Example 2: Guided Chat — Building Features Interactively

When to use: You know the feature you want, but the implementation details should be driven by conversation.

Real-World Example: Adding Dark Mode

Prompt 1: "Add a dark mode toggle to the header. Use CSS custom 
           properties for theming. Save the preference to 
           localStorage so it persists."

[Agent implements the toggle, CSS variables, localStorage logic]

Prompt 2: "That works, but the transition is jarring. Add a 300ms 
           ease on all color properties."

[Agent adds smooth transition CSS]

Prompt 3: "The icons in the sidebar aren't switching colors. They're 
           using hardcoded hex values."

[Agent finds and replaces the hardcoded colors with CSS variables]

Total interaction: 3 prompts, ~5 minutes of your attention. Each prompt built on seeing the result of the previous one.

Why Guided Chat Is Right Here

You could have written all three requirements upfront as a goal. But you didn’t know about the jarring transition or the hardcoded icon colors until you saw the first implementation. The iterative nature of guided chat lets you discover requirements as you go.

This is the most common mode for day-to-day feature development. You have a general direction, but the details emerge through interaction.

Example 3: Planning Mode — Architectural Changes

When to use: The change is significant enough that you want to review the approach before any code changes happen.

Scenario: Adding Firebase Authentication

Add Google Sign-In to the app using Firebase Authentication.
Only authenticated users should see the main content. 
Show a login screen with a Google sign-in button for unauthenticated users.

What happens automatically:

Research phase: The agent audits your codebase. It finds your existing HTML structure, identifies where the login gate should go, checks if any Firebase SDKs are already loaded, and reviews your current routing.
Plan creation: The agent creates an implementation_plan.md covering:

Which Firebase SDKs to add
Where to insert the auth state listener
How to gate the main content behind onAuthStateChanged
Security considerations (Firestore rules, protected routes)
Proposed file changes with estimated line numbers

3. Review checkpoint: The plan appears as an artifact with a “ Proceed ” button. You read exactly what’s going to change before a single line of code is modified.

4. Execution: After you click “ Proceed ,” the agent executes all steps, verifies the login flow works, and creates a walkthrough artifact summarizing what changed.

The critical difference from Goal Mode: the human review checkpoint at step 3. Nothing changes in your code until you approve.

Why Planning Mode Is Right Here

Authentication is a cross-cutting concern. It touches your HTML structure, JavaScript logic, security rules, and potentially your deployment config. If the agent had started editing without a plan, a wrong assumption about your routing could cascade into a broken app. The plan gives you a chance to catch issues before they become problems.

How Planning Mode Gets Triggered

You don’t explicitly ask for it, though you could. Antigravity decides based on the scope of your request and this is what I have typically observed:

Simple fixes → direct execution
New features → may or may not plan (depends on complexity)
Architectural changes, migrations, multi-file refactors → almost always plans

If you want a plan for something the agent would normally just do, say: “Create a plan for this before implementing.”

Example 4: Goal Mode — The Power Move

When to use: The task is well-defined, you’ve pre-answered every decision, and you want to walk away.

The Transition Point: Chat vs. Goal

Let’s compare two approaches to the same task: migrating a REST API integration from fetch to a typed SDK with error handling.

Approach A: Chat Mode (interactive, ~30 minutes)

Exchange 1: "I want to replace raw fetch calls with the 
              official SDK. Where are all the API calls?"
Exchange 2: [Reviews list] "Start with the user endpoints."
Exchange 3: [Reviews changes] "The error handling isn't matching 
              our pattern. Use the AppError class."
Exchange 4: [Reviews fix] "Good. Now do the products endpoints."
Exchange 5: [Reviews changes] "You missed the pagination helper."
Exchange 6: [Reviews fix] "Now the orders endpoints."
Exchange 7: [Reviews changes] "The types are wrong on the 
              response object."
Exchange 8: [Reviews fix] "Looks good. Run the tests."

Total time: ~30 minutes of continuous attention across 8 exchanges.

Approach B: Goal Mode (autonomous, ~5 minutes of your time)

**/goal**

Replace all raw fetch() API calls with the official TypeScript SDK.

## Current State
- API calls are in src/api/*.ts (users.ts, products.ts, orders.ts)
- Raw fetch with manual JSON parsing
- Error handling is inconsistent across files
- Types are defined in src/types/api.ts

## Requirements
1. Install @acme/sdk@^3.0 via npm
2. Replace every fetch() call with the equivalent SDK method
3. Use the existing AppError class (src/utils/errors.ts) for 
   all error handling
4. Ensure all response types match src/types/api.ts
5. Handle pagination using SDK's built-in paginator
6. Remove unused fetch utility functions from src/utils/http.ts

## Constraints
- Don't change any component code that calls these API functions
- Keep the same function signatures (callers shouldn't need to change)
- Don't modify existing types — adapt SDK responses to match them

## Verification
- npm run typecheck passes with zero errors
- npm run test passes (all existing tests should still work)
- grep 'fetch(' src/api/ → zero results
- grep 'AppError' src/api/ → at least one result per file

Total time: ~5 minutes to write the prompt. Walk away.

What the agent does autonomously:

1. Research → Reads all files in src/api/, catalogs every fetch call
2. Plan → Maps each fetch call to its SDK equivalent
3. Execute → Installs SDK, rewrites all three files
4. Verify → Runs typecheck → finds 2 type mismatches → fixes them
5. Re-verify → Runs tests → one test fails due to mock changes → 
                fixes the mock → all tests pass
6. Final grep → Confirms zero remaining fetch() calls
7. Report → Creates walkthrough summarizing all changes

The key difference: in Goal Mode, the type mismatches and failing test would have been caught and fixed automatically during the verify-fix loop. In Chat Mode, those same issues required two more exchanges of your time.

Example 5: Goal Mode — Multi-Component Feature

Here’s a more complex goal prompt:

**/goal**

Add a real-time admin dashboard to the web application.

## Requirements

### Navigation
- Add a "Dashboard" link in the sidebar, visible only to admin users
- Create a new route /admin/dashboard
- Include three tabs: "Users", "Activity", "Revenue"

### Users Tab
- Total registered users (count)
- New users this week (count with trend arrow)
- User growth chart (last 12 weeks, inline SVG bar chart)
- Top 10 most active users (sorted by login count)

### Activity Tab
- Actions per day chart (last 30 days, SVG line chart)
- Most common actions (table with percentages)
- Error rate (percentage with color indicator)

### Revenue Tab
- Monthly revenue chart (last 6 months, SVG bar chart)
- Average order value
- Top selling products (table)

### Design
- Use the existing design system (Tailwind CSS classes)
- Match the existing card component style
- Dark mode compatible
- Responsive — usable on tablet and desktop
- Animate chart elements on render

### Data
- Query existing Firestore collections: users, events, orders
- Use real-time onSnapshot listeners for live updates
- Admin check: user.role === 'admin'

### Constraints
- No external charting libraries (pure SVG)
- Admin-only: gate with role check, redirect non-admins
- Don't modify existing routes or components

### Verification
- Dashboard only accessible when user.role === 'admin'
- All three tabs render without console errors
- Charts display correctly with sample data
- Responsive at 768px viewport width
- npm run build succeeds

What makes this a good goal prompt:

Every decision is pre-made (no “should I use Chart.js?” ambiguity)
Data sources are specified (which collections, which fields)
Visual style is pinned to existing conventions
Verification is concrete and testable
Constraints prevent scope creep

Anatomy of a Great Goal Prompt

An effective /goal prompt should ideally have these sections:

**/goal**  

[One-line summary of what you want]

## Current State
What exists today. Tech stack, file locations, relevant architecture.

## Requirements
Numbered list of specific, concrete deliverables.

## Constraints  
What NOT to do. Boundaries. Style rules. "Don't touch X."

## Verification
How the agent knows it's done. Tests to run, greps to check, 
behavior to validate.

The Decision Pre-Answer Rule

For every place where you’d normally say “yes, do that” or “no, use the other approach” in a chat conversation, pre-answer it in the goal prompt.

What to Include in Verification

Verification criteria are what separate a sub-optimal goal prompt from a good one. Think of them as acceptance tests:

Without verification criteria, the agent has no way to self-correct. It can’t enter the fix-verify loop because there’s no “verify” step defined.

Spec-Driven Development: The Bigger Idea

If the structure of a goal prompt i.e. current state, requirements, constraints, verification looks familiar, it should. It’s a specification. And what we’re really doing with /goal is something that we as software engineers have aspired to for decades now: writing a spec that executes itself.

The Old Way vs. The New Way

Traditional software development has always involved specifications, but there was a gap between the spec and the code:

In the traditional flow, the spec is a communication artifact , it tells a human what to build, and the human translates it into code. The translation step is where most bugs are born: misunderstandings, missed edge cases, things the spec assumed were obvious.

In spec-driven development with Antigravity, the spec is an execution artifact. It doesn’t just describe what to build, it directly drives the building. The “translation step” still exists (the agent interprets your spec), but the feedback loop is immediate: if the agent misinterprets something, the verification step catches it, and the agent self-corrects.

What Makes a Spec Executable?

Not every spec works as a goal prompt. The difference between a traditional spec and an executable spec is verifiability. Compare:

The left column is what humans interpret. The right column is what agents can verify. When every line in your spec has a corresponding check, you’ve written an executable specification.

The Spec as the Single Source of Truth

Here’s where it gets powerful. In traditional development, the spec, the code, and the tests are three separate artifacts that can drift apart. The spec says one thing, the code does another, and the tests check a third.

With a goal prompt:

The spec is the prompt and it defines requirements, constraints, and verification.
The code is generated from the spec by the agent, not by manual translation.
The tests are embedded in the spec as verification criteria that run automatically.

There’s one artifact instead of three. And when you need to change behavior, you update the spec and re-run it. You don’t separately update the requirements doc, then the code, then the tests.

Leveling Up: Composable Specs

Once you’re comfortable with single goal prompts, you can compose them into multi-phase specifications. This is a possibility and you should try it.

Phase 1 Spec: Authentication
  → Verification: users can sign in, auth state persists, 
    protected routes redirect

Phase 2 Spec: Data Layer (depends on Phase 1)
  → Verification: CRUD operations work, security rules enforce 
    auth, real-time updates sync

Phase 3 Spec: UI Dashboard (depends on Phase 2)
  → Verification: charts render, admin gate works, 
    responsive layout, no console errors

Each phase is a self-contained, verifiable spec. Phase 2 doesn’t start until Phase 1’s verification passes. This is dependency-ordered, verified, incremental development and each phase can run autonomously.

The Implication for Teams

Spec-driven development changes how teams coordinate. Instead of:

Product manager writes a PRD
Engineer reads the PRD and writes code
QA reads the PRD and writes tests
Everyone argues about what the PRD actually meant

You get:

Product manager and engineer co-write an executable spec
The spec runs and produces code, tests, and verification in one pass
Review shifts from “does this code match the spec?” to “is this spec correct?”

The bottleneck moves from implementation to specification quality. And that’s a much better bottleneck to have, because it’s a thinking bottleneck, not a typing bottleneck.

The Slash Commands You Should Know

Beyond /goal, Antigravity offers several slash commands that sit at different points on the autonomy spectrum:

/grill-me — The Bridge from Chat to Goal

This is arguably the most important slash command to understand, because it solves the hardest problem in autonomous execution: how do you know what you don’t know?

When you sit down to write a /goal prompt, you need to pre-answer every decision the agent would otherwise ask you about. But for complex tasks, you don't know what all those decisions are. You don't know what you haven't considered. That's where /grill-me comes in.

/grill-me I want to add multi-tenancy to my SaaS app

The agent reads your codebase, understands the current architecture, and then interviews you with a series of targeted questions — not generic ones, but questions specific to your code and your situation:

Agent: I've reviewed your app. Here are the key decisions we need 
       to make before I can build this:

1. DATA ISOLATION: Your Firestore is currently a single database.
   Should each tenant get:
   a) Separate Firestore databases (strongest isolation, higher cost)
   b) Separate top-level collections per tenant (moderate isolation)  
   c) A tenantId field on every document (simplest, weakest isolation)

2. URL STRATEGY: Currently your app runs on app.example.com.
   Should tenants get:
   a) Subdomains (acme.app.example.com)
   b) Path-based routing (app.example.com/acme)
   c) Shared URL with tenant selected after login

3. AUTH BOUNDARY: Your Firebase Auth is project-wide. Should:
   a) Users be scoped to a single tenant
   b) Users be able to belong to multiple tenants
   c) Admin users have cross-tenant access

4. DATA ON DELETE: When a tenant is removed, should their data be:
   a) Hard deleted immediately
   b) Soft deleted with a 30-day recovery window
   c) Archived to Cloud Storage

5. EXISTING USERS: You have 340 users in production. How should 
   they be assigned to tenants during migration?

You answer each question. The agent follows up on ambiguous answers. By the end of the interview — typically 5–10 minutes — you’ve surfaced every decision that would have been a blocking question during an autonomous run.

From Interview to Executable Spec

Here’s the key: your answers from /grill-me become your goal prompt. The interview output maps directly to the spec structure:

Without /grill-me, you'd discover these decisions the hard way — either by writing an incomplete goal prompt that the agent guesses at (badly), or by having a long chat session where you gradually realize what you missed. /grill-me front-loads all of that discovery into a structured interview.

Think of it this way: Chat is exploration. /grill-me is structured discovery. /goal is execution. The best specs come from running /grill-me first.

/learn — Persist Patterns

/learn

After a productive chat session, use /learn to capture successful patterns. The agent creates a persistent rule or skill so future sessions (including autonomous runs) benefit from what you discovered interactively. For example, after figuring out your project's error handling pattern through chat, /learn saves it so the agent follows the same pattern in future /goal runs.

/browser — Web Automation

/browser Go to https://ai.google.dev and find the current pricing 
for Gemini 2.5 Flash. Summarize it in a table.

The agent launches a browser, navigates pages, reads content, clicks links, fills forms, and takes screenshots. Useful for:

Verifying deployed web apps look correct
Scraping documentation into structured formats
Testing user flows end-to-end
Filling out forms and capturing results

/schedule — Recurring Tasks

/schedule Run the test suite every morning at 9am and report any failures

Sets up cron-based agent execution. The agent runs autonomously on a schedule without any intervention. Useful for:

Health checks on deployed services
Periodic report generation
Automated data syncs

The Self-Correction Loop: How Autonomous Runs Actually Work

When you use /goal, the agent enters a persistent loop:

This isn’t just a flowchart, it’s the difference between chat and goal mode.

Here’s a concrete example:

The “Remove Deprecated Feature” Scenario

Imagine you ask the agent to remove a feature. Let’s say, an old notification system that’s been replaced. In Chat Mode , you’d say:

Remove the notification bell feature from the app.

The agent removes the HTML, the JS functions, and the CSS. But let’s say that it misses two stale references:

initNotifications() is still called in the app's startup() function
notificationCount is still referenced in the user profile component

These cause runtime errors. You catch them by testing, report them back, and the agent fixes them one at a time across two more exchanges. Three total interactions to complete what should have been one task.

In Goal Mode with proper verification:

/goal
Remove the deprecated notification bell feature.

## Requirements
- Remove notification bell HTML from the header
- Remove all notification JS functions
- Remove notification CSS styles
- Remove notification-related state variables

## Verification
- grep -ri 'notification' src/ → zero results (excluding 
  this prompt and git history)
- npm run build succeeds
- No console errors on page load
- App loads normally for both regular and admin users

The verify step catches the stale references. The fix step removes them. The re-verify step confirms a clean build. The two extra chat exchanges become zero — the loop handles them automatically.

What Self-Correction Looks Like

During an autonomous run, the agent:

Runs a command → command fails → reads the error → fixes the code → retries
Deploys → deployment fails → checks the error log → fixes the config → redeploys
Greps for leftover code → finds stale references → removes them → re-greps
Runs the test suite → 2 tests fail → reads the assertion errors → fixes the code → re-runs tests

This is the core advantage of autonomous execution — it doesn’t just run your code, it runs your tests and fixes its own mistakes.

When Autonomy Fails: Anti-Patterns to Avoid

Goal Mode isn’t magic. Here are real failure modes and how to avoid them. The suggestions given are with a best intention.

Anti-Pattern 1: The Vague Goal

❌ Bad:

/goal Make the app better

Why it fails: “Better” is not a verification criterion. The agent will make changes, but it has no way to know when to stop or whether its changes are improvements.

✅ Good:

/goal Add loading spinners to all async buttons. Show a spinner 
icon and "Working..." text while operations run. Disable buttons 
during processing to prevent double-clicks.

## Verification
- All async buttons show spinners during their operations
- Buttons are disabled while processing
- Spinners disappear after completion or error
- No console errors

Anti-Pattern 2: The Under-Constrained Goal

❌ Bad:

/goal Add charts to the dashboard

Why it fails: Should it use Chart.js, D3, or inline SVG? What data should the charts show? What colors? This forces the agent to make design decisions that you’ll likely want to override.

✅ Good: Pre-answer every design decision — specify the chart approach (inline SVG, no external libraries), data sources (which collections/arrays), visual style (match existing design system), and include concrete verification criteria.

Anti-Pattern 3: The Goal That Needs Discussion

❌ Bad:

/goal Redesign the entire UI to be more modern

Why it fails: “Modern” is subjective. The agent will make choices you disagree with, but since it’s running autonomously, it’ll make all of them before you see any of them. Use chat or /grill-me first to align on the direction.

✅ Better approach:

1. Start with chat: "What would a more modern UI look like for this app?"
2. Discuss options, agree on direction
3. Then use /goal with specific design tokens, colors, and patterns

Anti-Pattern 4: Missing Verification

❌ Bad:

/goal 

Remove the notification feature from the app

## Requirements
- Remove notification HTML
- Remove notification JS functions
- Remove notification variables

Why it fails: No verification step. The agent removes what you listed, but doesn’t check for stale references, the very type of bug that’s easiest to catch with a simple grep.

✅ Good:

## Verification  
- grep -ri 'notification' src/ → zero results
- npm run build succeeds
- No console errors on page load

Anti-Pattern 5: The Goal That’s Too Large

❌ Bad:

/goal 

Build a complete e-commerce platform with user auth,
product catalog, shopping cart, checkout, payment processing, 
order management, admin dashboard, and email notifications

Why it fails: Too many interacting components. If the auth system has a subtle bug, it cascades into everything else. The agent can’t isolate failures when 8 subsystems are being built simultaneously.

✅ Better: Break it into phases:

Phase 1: /goal Add user authentication with Google Sign-In
Phase 2: /goal Add product catalog with Firestore backend
Phase 3: /goal Add shopping cart with real-time sync
Phase 4: /goal Add checkout and payment processing

Each phase can be verified independently before moving to the next. You might want to even use /grill-me before coming up with the /goal at each of the phases.

When to Use Which Mode: The Decision Matrix

The Litmus Test

If you can write down every decision the agent would need to make, use /goal . If you'd need to see intermediate results before deciding, use _ **_chat** .

The Hybrid Approach

In practice, the best workflow is often:

For example:

You chat to understand your codebase’s auth patterns
Use /grill-me to surface edge cases you haven't considered ("what about expired tokens? rate limiting? session management?")
Chat a bit more to decide on the approach
Write the spec as a goal prompt, let /goal execute it autonomously while you focus on something else, and then
Review the walkthrough and diff when it's done.

Practical Tips for Better Autonomous Runs

1. Start with Chat, Graduate to Goal

Your first time building a feature? Use chat to understand the patterns. The second time you build something similar? Write a goal prompt based on what you learned.

2. Use /grill-me Before Writing Complex Goals

Not sure if you’ve thought of everything? The agent interviews you with targeted questions to surface decisions you haven’t considered. Then use the answers to write a comprehensive goal prompt.

3. Include File Paths in Goal Prompts

Don’t make the agent guess where things are:

❌ "Update the main app file"
✅ "Update src/App.tsx and src/components/Header.tsx"

4. Name Your Data Structures

If the agent needs to work with existing code, tell it the variable names:

❌ "Use the product list"
✅ "Use the productCatalog[] array from src/data/products.ts"

5. Specify the Deploy Target

If deployment is part of the goal, be explicit:

❌ "Deploy it"
✅ "Deploy to Firebase Hosting project my-project-id"

6. Use /learn After a Chat Session

After a productive chat session, /learn persists successful patterns so future goal runs benefit from what you discovered interactively.

7. Set Permissions for Autonomous Runs

For autonomous runs, pre-configure permissions so the agent doesn’t block waiting for approval:

Tool Execution Policy : always-proceed (the agent runs commands without asking)
Trusted Workspaces : Add your project directory so file operations proceed automatically

⚠️ Only use always-proceed in trusted workspaces where you're comfortable with the agent running commands autonomously.

The Bigger Picture: How Developer Roles Are Shifting

The distinction between chat and autonomous execution isn’t just a UX feature, it reflects a fundamental shift in what it means to “write code.”

In the chat era , the developer is a typist-thinker hybrid. You think about what to build, type the code, think about what broke, type the fix. Your value is split between knowing what to do and doing it.

In the autonomous era , the developer is a specification writer and reviewer. You think about what to build, write a precise spec, and review the output. Your value shifts entirely to judgment, knowing what to build, how to verify it, and how to catch subtle errors in AI-generated code.

This isn’t a loss. It’s a liberation. The mental model shifts from:

Think → Type → Debug → Type → Test → Type → Deploy → Type

To:

Think → Specify → Review → Deploy

The “typing” — the mechanical act of translating intent into code — is the part that gets automated. The thinking, specifying, and reviewing are the parts that remain uniquely human. And those are, arguably, the most intellectually rewarding parts. I hope we have consensus there though some would like to debate what is actually rewarding to them and I will respect that.

Summary

The transition from chat to autonomous execution isn’t about trust — it’s about specification clarity. When you can write down exactly what you want, including constraints and verification criteria, you’ve written a goal prompt. When you can’t yet, chat your way there first.

Start small. Try a /goal on your next well-understood task. See what happens. Then gradually increase the scope as you build confidence in your prompt engineering.

The dial goes from “fix this typo” to “build this entire feature.” Your job is to figure out, for each task, where to set it.

A quick table summary to end this article:

The future of autonomous software maintenance: a dependency update agent

Karl Weinmeister — Thu, 09 Jul 2026 21:14:10 +0000

Most AI tools focus on writing new code, but up to 80% of the cost of software comes from maintenance. What if an intelligent agent could handle that burden for you?

In this article, I’ll walk through an autonomous agent called dependency-director that handles one of the most common maintenance scenarios: dependency updates. It goes beyond merging dependency updates that are passing tests; it upgrades your code to match changes in the dependency. This provides a sneak peek into the future of automated engineering workflows.

Note: dependency-director is an experimental proof of concept and is not intended for production environments. Although it uses security guardrails like sandboxing and command filters, running LLM-generated code dynamically always involves security trade-offs. If you experiment with the code on GitHub, please do so in an isolated testing environment, start with the --dry-run flag, and use highly restricted API tokens.

Loop engineering for software updates

A continuous triage loop is at the center of the process. The agent scans repositories and maps every open pull request to a state and triggers an action.

When a dependency update breaks a test suite, the agent automatically clones the repository and updates the code to align with the updated dependency.

Dependency Director runs on the Google Antigravity SDK, with Gemini taking care of the reasoning. You can configure the agent like this (full version in main.py):

config = LocalAgentConfig(
    model="gemini-3.5-flash",
    system_instructions=system_instructions,
    policies=policies,
    tools=agent_tools, # 12 GitHub API tools, plus a sandboxed shell
    workspaces=[project_root, workspace_tmp],
    capabilities=types.CapabilitiesConfig(
        enable_subagents=False,
        disabled_tools=[types.BuiltinTools.RUN_COMMAND],
    ),
)

Two lines do most of the security work. disabled_tools=[types.BuiltinTools.RUN_COMMAND] turns off the SDK’s built-in shell, so the only way the agent can run a command is through my sandboxed wrapper. And workspaces pins file operations to the project directory and a per-repo temp workspace, so the agent can’t wander through the filesystem.

Guardrails live in the tools, not the prompt

A common mistake in agent design is writing rules into the system prompt and hoping the model follows them. All important constraints are enforced in the tool functions themselves.

For example, the author of the pull request must be one of the allowed bots. The defaults are dependabot[bot] and renovate[bot].

def _check_bot_author(author: str, bots: list[BotConfig]) -> BotConfig:
    allowed = {b.author for b in bots}
    if author not in allowed:
        raise PermissionError(
            f"Security Block: Only pull requests authored by {allowed} "
            f"can be processed. This PR was authored by '{author}'."
        )
    return next(b for b in bots if b.author == author)

There’s also a --dry-run parameter, so that you can simulate the behavior locally, without updating the pull request.

async def merge_bot_pr(owner: str, repo: str, pr_number: int) -> str:
    author = await client.get_pr_author(owner, repo, pr_number)
    _check_bot_author(author, bots)
    if dry_run:
        return f"[DRY-RUN] Would have merged PR #{pr_number} in {owner}/{repo}."

All fixes are held up as an open PR for your review by default, unless you use --automerge.

Patching a red pull request

When a PR has a conflict, the agent follows a procedure in its system instructions located in instructions.py. It uses the code-review-and-quality skill from Addy Osmani to go beyond just making the test pass, and ensure a code review and quality standards are enforced:

RED: Retrieve logs via 'get_pr_workflow_run_logs'. Clone into a subdirectory,
then check out the PR branch:
  git fetch origin pull/<pr_number>/head:pr-<pr_number> && git checkout pr-<pr_number>
Otherwise install deps, test, fix, verify, and push to the remote branch.
Max 3 fix attempts per RED PR before skipping.
Run 'code-review-and-quality' self-review before committing.

The agent is also very clear about what counts as a fix. It’s told to consider what’s changed in the API documentation, and not just chase a green checkmark:

- Fix root causes (types, signatures, API changes) using changelogs.
- NEVER suppress errors (type: ignore, noqa, Any) unless upstream bugs
  leave no alternative (require comment).

Running untrusted code in a sandbox

To restrict filesystem and network operations, Dependency Director uses sandbox-runtime. It’s an open-source OS-level sandbox. Every shell command the agent runs is wrapped in it:

process = await asyncio.create_subprocess_exec(
    "srt", "--settings", active_config_path, "-c", command_line,
    cwd=target_cwd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, env=env,
)

You can configure the settings file where the sandbox is configured. The default settings allow network access to package registry domains such as PyPI, npm, crates.io. The agent is blocked from reading the home directory and writing to the .env environment variable file and .git/hooks. Here’s the bundled srt-settings.json, trimmed to a few representative entries:

{
  "network": {
    "allowedDomains": ["github.com", "pypi.org", "registry.npmjs.org"],
    "deniedDomains": ["*.ngrok.io", "*.webhook.site", "*.requestbin.com"]
  },
  "filesystem": {
    "denyRead": ["~"],
    "allowWrite": ["/tmp"],
    "denyWrite": [".env", ".git/hooks"],
    "allowGitConfig": false
  }
}

Trying it out yourself

Solid test coverage is essential for updating dependencies. Tests give you the confidence to know that your code still functions. When you use Dependency Director, they’re absolutely required so that the agent can safely patch your code to work with the updated dependencies. For tips on effective tests, see my blog post on five essential testing patterns.

Using an AI agent does consume tokens, of course. I performed a trial run on a repo with 6 open pull requests using gemini-3.5-flash. It used about 200k tokens. At the current published rate, that’s about $0.30 USD for the run, or roughly 6 cents per PR.

The code to try out dependency-director is on GitHub for you to try. Start with --dry-run to see how it works for you!

What maintenance work would you hand to an agent first? Tell me on X, LinkedIn, or Bluesky.

Agent Factory Recap: 100X engineering with AI agents in Google Antigravity 2.0

Shir Meir Lador — Tue, 07 Jul 2026 17:28:25 +0000

In this episode of the Agent Factory, I sat down with Rody Davis, one of Google's top agentic engineers. We dive into the massive shift from traditional IDEs to agent-first platforms, the reality of code reviews in an AI-driven world, and how to use "skills" to perform at a 100X level.

This post guides you through the key ideas from our conversation. Use it to quickly recap topics or dive deeper into specific segments with links and timestamps.

Google Antigravity 2.0 - What is it?

Antigravity 2.0 has evolved from a simple agentic IDE into a full-scale agent-first platform. It now consists of four core pillars: a standalone desktop Agent Manager for orchestration, a robust CLI for server-side work, an SDK for custom Python-based workflows, and a specialized IDE. This unbundled approach allows developers to compose their own environment, managing multiple folders and complex project structures without being forced into a single-workspace layout.

Rody Davis on 100X Engineering

We explored the strategies elite engineers use to scale their impact and reduce the "cognitive toil" of daily development.

Scaling Impact and Reducing Toil

Timestamp: 01:55

Rody explains that AI isn't just about writing code; it's about accelerating the entire lifecycle. He uses agents to write richer test suites and prototype multiple versions of an app before committing to a framework. By offloading "toil", like building marketing sites, he can focus on high-level architecture and problem-solving.

Skills as "Context Cheat Sheets"

Timestamp: 03:05

A core philosophy in Rody's workflow is the use of "Skills." He views skills as a way to compress context for the model. "It's literally a cheat sheet for the agent," Rody notes. By providing the agent with specific design systems or API documentation, the model becomes significantly faster and more accurate, avoiding the latency of searching through massive, unorganized docs.

Customizations, Skills, and MCP Servers

Timestamp: 04:17

Rody walks us through the customizations tab in Antigravity 2.0, showing how to extend an agent's capabilities:

Android CLI: Building and deploying mobile apps directly from the command line.
Modern Web Guidance: Grounding the agent in the latest CSS and accessibility standards.
MCP Servers: Using the Model Context Protocol to enable features like hot reloading for Flutter and Dart.

The Bonsai Approach to Code Review

Timestamp: 05:27

Rody compares maintaining a codebase to being a Bonsai artist: constantly pruning to keep things simple. He advocates for flat architectures where state, UI, and data are strictly separated. This makes it easier for a human to "steer" the agent; if the agent starts putting files in the wrong place, the architectural violation is immediately obvious.

Do you review 100% of agent-generated code?

Timestamp: 07:11

Rody's answer depends on the task. For a marketing site, he focuses on the visual output rather than the code. However, for backend logic, he cares deeply about API contracts and schemas. He recommends writing the first example yourself so the agent can simply "copy the pattern" for the rest of the codebase.

Building Extensions to Solve Daily Friction

Timestamp: 09:05

To solve the problem of managing files across multiple Git projects, Rody used Antigravity to build a custom macOS Finder extension in Swift. This tool allows him to filter files by time boxes (today, last week, etc.), demonstrating how agents can build specialized utilities that reduce daily friction.

Do AI engineers still write code by hand?

Timestamp: 10:22

"Oh yeah," Rody says. He still loves the syntax of languages like Go and the challenge of controlling computers. He believes it's vital to understand the building blocks deeply so that when you face a problem two years down the road, you know exactly which "old project" to reach back for.

Powering Personal Websites with Gemma 4

Timestamp: 11:42

Rody showcases his personal website, which uses Gemma 4 and Embedding Gemma to provide dynamic content recommendations offline. By vectorizing post summaries at compile time, the site can suggest related content via a local vector database without needing a live backend server.

The Factory Floor

The Factory Floor is our segment for getting hands-on. Here, we moved from high-level concepts to practical code with live demos.

Multi-Agent Parallelism in Action

Timestamp: 14:02

In this demo, Rody uses a single stream-of-thought voice prompt to build a full-stack application. We watched as Antigravity:

Spun up parallel sub-agents, including a dedicated DevOps and QA engineer. (see 19:48)
Built a multilingual note-taking app using Vite, Go, and SQLite.
Orchestrated the entire stack via Docker Compose.
Localized the app into five different languages simultaneously.

Unbundling the IDE Ecosystem

Timestamp: 15:35

We discussed why Google separated the IDE from the Agent Manager. Rody highlights that this unlocks different workflows: the CLI is perfect for SSH sessions on a Raspberry Pi, while the Agent Manager handles general knowledge work and orchestration across multiple folders.

Turning Documentation into Reusable Skills

Timestamp: 25:41

Rody shares his process for turning documentation into skills. He wrote a Go CLI that parses websites into markdown, allowing him to install hundreds of skills for the sites he visits frequently. This ensures the agent always has access to the specific version of the docs he is using.

Rapid Fire: Future Tech Predictions

Timestamp: 27:35

We put Rody on the spot with some controversial takes:

Vibe Coding: Rody believes a non-technical founder will launch a company using only vibe coding by 2026, but the real test will be maintaining it in years 2 through 5.
Production Failures: Rody agrees that vibe coding will cause significant production failures, leading to a new hot job for software engineers: consulting to solve those failures.
Codebase Health: Rody argues that poor codebase health, not context windows, is the biggest bottleneck in AI speed.

Grounding Yourself in a Changing Landscape

Timestamp: 31:10

Rody advises engineers to focus on why they were hired: to solve problems and engineer things that didn't exist before. He suggests using AI to provide better communication handoffs between colleagues, making artifacts so easy to approve that they are "ready to sign off" the moment they are handed over.

Conclusion

The era of agentic engineering is here, but as Rody Davis demonstrated, it requires more architectural discipline, not less. By treating your codebase like a Bonsai tree and your agents like an orchestra, you can move past the "toil" and focus on building the frameworks of the future.

Your turn to build

Are you ready to build anything? We've officially launched the #NapkinChallenge. Take a handwritten sketch of an app idea, use Antigravity 2.0 to build it, and share your creation on social media.

Try Antigravity 2.0: antigravity.google
Join the Challenge: Napkin Challenge Details
Rody's personal website, github repo and skills

Connect with us

Rody Davis → X, LinkedIn
Shir Meir Lador → X, LinkedIn

Master Local Fine-Tuning with "gemma-trainer"

bebechien — Tue, 07 Jul 2026 01:44:15 +0000

Remember back in May when I introduced the gemma-skills repository? It's been rewarding to see how many of you have used my previous post to streamline your workflows. (And hey, even if we aren't swimming in GitHub stars yet, I think we're off to a great start!😉)

But as I built more custom applications, I kept hitting the same roadblock: how to take a great base model and adapt it to my specific needs.

Fine-tuning a model usually requires wading through complex setups and confusing guides. To make this process straightforward and quick, we created our newest skill: gemma-trainer

What is `gemma-trainer`?

gemma-trainer is your blueprint for training and adapting Gemma models on your local hardware. It handles the "how-to" so you can focus on your specific project goals, whether you are teaching a model a new domain or aligning its behavior to your preferences.

Why You'll Use It

Faster, Lighter Training: We recommend using Unsloth for single-GPU training, making it fast and using less memory so it runs easily on personal hardware.
Three Key Methods: It guides you through Supervised Fine-Tuning (SFT) to teach new info, Direct Preference Optimization (DPO) to align with preferences, and Reward Modeling (RM) to rate responses.
Teach Models to See and Hear: It includes clear instructions for training models with images and audio (multimodal learning) alongside text.
Run Anywhere: Quickly convert your models to lightweight formats (like GGUF) and run them on mobile or smart devices (IoT) using LiteRT-LM.
Up-to-Date Best Practices: The skill is continuously updated with the latest optimized settings and training techniques, ensuring you're always using the best methods.

Practical Use Case

To see this in action, recall how we turned Gemma 4 into an expert translator for Classical Korean literature in my previous post. With gemma-trainer, you don't need to manually piece together a pipeline. You can simply ask your agent:

"Fine-tune Gemma 4 E2B on the dataset bebechien/HongGildongJeon."

With the gemma-trainer skill, your agent will partner with you to:

Verify your data: Use the validation script to ensure your training data matches template requirements.
Set up parameters: Select the best LoRA settings to teach the model linguistic nuances without running out of video memory (VRAM).
Run the training: Launch the training session using optimized, resource-efficient defaults.
Evaluate and iterate: Review the model's performance and adjust settings to get the exact results you need.

Here is an example showing the agent starting a fine-tuning run on a Gemma 4 12B model for audio tasks:

Once configured, the agent kicks off the training process using your designated dataset:

Even if you make a mistake, the agent has your back. For instance, when I accidentally requested training a Gemma 4 31B model (which is a text-and-vision model and has no audio capability), it suggested using Gemma 4 E2B or 12B for audio tuning instead:

Once training is complete, the agent presents the results and outlines the next steps:

You can also ask your agent to write a custom evaluation script based on your specific requirements. In this case, I asked the agent to create a script that checks transcription similarity:

Finally, you will receive a comprehensive report summarizing the training performance, making it clear where you can make improvements in the next run:

Let's try!

gemma-trainer is a living, structured document. Drop it into your agent's skills directory, and your AI assistant will immediately know how to guide you through the process.

Check out the repository, add the skill to your toolbox, and let's build something amazing!

Thanks for reading and happy training!

DEV Community: Google AI

Gemini 3.6 Flash & 3.5 Flash-Lite: Developer guide

New models

Quickstart

What's new in Gemini 3.6 Flash

What's new in Gemini 3.5 Flash-Lite

Choosing the right Flash or Flash-Lite model

Updated Antigravity agent

API changes and parameter updates

1. Sampling parameter deprecation (temperature, top_p, top_k)

2. Prefilled model turn validation {:#prefilled-model-turn-validation}

⚠️ Avoid

✅ Recommended Migration (Interactions API)

Migration checklist

Migrate to gemini-3.6-flash

Migrate to gemini-3.5-flash-lite

Next steps

Google Cloud Labs: Accelerate AI with Cloud Run

Moving Beyond the Prototype

The Coffee Shop Journey: A Hands-On Experience

Production-Grade AI on Cloud Run

Ready to Build for Scale? Join us in North America

What is an "agentic harness," actually?

What's in the video

DiffusionGemma: The Developer Guide

The Architecture

Showcase: Solving Sudoku with Parallel Denoising

Why Sudoku is Interesting for Diffusion

Block Autoregressive Denoising

Serving DiffusionGemma

Getting Started Today

DiffusionGemma: 4x faster text generation

Our newest open experimental model delivers up to 4x faster inference on dedicated GPUs and opens the door to exploring speed-critical, interactive local workflows.

Unlocking new value for developers

Why diffusion for text?

The trade-off with traditional models

How text diffusion works

Get started today

The (no longer) missing multi-agent pattern: triggering dynamic workflows from an agent

The architecture of a dynamic workflow

Technical implementation

1. Initialize the environment and model

2. Define the sub-agent

3. Implement the dynamic workflow node

4. Define the workflow

5. Define the root coordinator agent

Testing the flow locally

Screencast demo

Summary

Thanks for reading

How your sample data impact vector tests in PostgreSQL and AlloyDB.

Introduction

Two datasets

Building Vector Index

Vector Search Performance

Vector Search Quality

Conclusion

Appendix

Context bankruptcy: The case for strategic forgetting for AI Agents

The visibility trap and why more context breaks reasoning

Selective ignorance and how to enforce the boundary

Pruning harnesses versus context bankruptcy

Essential implementation components

How Antigravity implements pruning

Vigilance fatigue

Tuesday morning checklist

Additional resources

Help others find this post.

The Antigravity Loop: From Chat to Autonomous Engineering

Introduction

What Exactly Are These Modes?

Chat Mode (The Default)

Planning Mode (The Middle Ground)

Goal Mode (/goal)

The Spectrum of Autonomy

Example 1: Chat Mode — Quick Fixes and Exploration

Scenario A: Fix a Bug

Scenario B: Understand Your Code

Scenario C: Brainstorm Ideas

Why Chat Mode Is Right Here

1. Sampling parameter deprecation (`temperature`, `top_p`, `top_k`)