← Back to articles

Agent Operation Modes

Path: Computer Tech/AI/ML/Google Antigravity/Agent Operation Modes.mdUpdated: 2/3/2026

Agent Operation Modes

When setting up Google Antigravity, one of the first decisions you make is how you want to use the Antigravity Agent. This choice determines the balance between agent autonomy and human oversight, affecting everything from how code gets executed to what the agent can do in your browser.

The setup screen presents four operation modes, each with corresponding Terminal Execution Policy and Review Policy settings.

The Four Operation Modes

Agent-Driven Development

Philosophy: Maximum autonomy—let the agent take the lead

Best for:

  • Exploratory prototyping
  • Well-defined tasks with clear success criteria
  • Developers comfortable delegating entire workflows
  • Teams that want to maximize velocity

How it works: The agent operates with minimal human intervention, planning and executing multi-step workflows from start to finish. You describe what you want built, and the agent handles the implementation details autonomously.

Typical workflow:

  1. You: "Build a REST API for user authentication with JWT tokens"
  2. Agent: Plans architecture, creates files, writes code, sets up tests, runs validation
  3. You: Review final Artifacts when agent signals completion

Trade-offs:

  • ✅ Fastest development cycle
  • ✅ Best for leveraging agent's full capabilities
  • ⚠️ Requires trust in agent's judgment
  • ⚠️ Less visibility into intermediate steps

Agent-Assisted Development (RECOMMENDED)

Philosophy: Collaborative partnership—human and agent work together

Best for:

  • Most production development scenarios
  • Teams learning to work with agentic AI
  • Projects requiring domain expertise
  • Balancing speed with control

How it works: The agent handles implementation while you provide direction, review intermediate outputs, and guide decisions. This mode strikes a balance between leveraging agent capabilities and maintaining human oversight.

Typical workflow:

  1. You: "Add user profile editing functionality"
  2. Agent: Proposes approach, requests confirmation on key decisions
  3. You: Approve approach, provide domain-specific guidance
  4. Agent: Implements with periodic check-ins via Artifacts
  5. You: Review and iterate until satisfied

Why it's recommended: Google designates this as the default mode because it:

  • Catches issues early through intermediate reviews
  • Builds trust gradually as you learn the agent's capabilities
  • Maintains quality without sacrificing too much velocity
  • Allows domain expertise to guide technical decisions

Trade-offs:

  • ✅ Best balance of speed and control
  • ✅ Easier to correct course mid-workflow
  • ⚠️ Requires more active participation than agent-driven
  • ⚠️ Slower than full autonomy

Review-Driven Development

Philosophy: Human-led with agent support—developer in full control

Best for:

  • High-stakes production code
  • Learning new codebases or technologies
  • Situations requiring regulatory compliance
  • Developers new to AI-assisted workflows

How it works: You maintain primary control while the agent acts as a highly capable assistant. The agent generates suggestions and implements specific subtasks, but you review and approve before anything executes.

Typical workflow:

  1. You: Write specifications and break down tasks
  2. Agent: Suggests implementations for each subtask
  3. You: Review each suggestion before allowing execution
  4. Agent: Implements approved changes
  5. You: Verify each step before proceeding

Trade-offs:

  • ✅ Maximum oversight and control
  • ✅ Great for learning or critical systems
  • ⚠️ Slower development velocity
  • ⚠️ Underutilizes agent's autonomous capabilities

Custom Configuration

Philosophy: Fine-tuned control—define your own rules

Best for:

  • Teams with specific security requirements
  • Specialized workflows (e.g., embedded systems, regulated industries)
  • Advanced users who know exactly what they need
  • Hybrid approaches not covered by standard modes

How it works: You manually configure Terminal Execution Policy, Review Policy, and browser permissions to match your exact requirements. This might mean full autonomy for certain operations but strict review for others.

Example custom setups:

  • Security-focused: Auto-approve reads, require review for writes/deletions
  • Performance-testing: Allow terminal execution but lock down browser access
  • Multi-stage: Agent-driven for dev environment, review-driven for staging

Trade-offs:

  • ✅ Precisely matches your workflow needs
  • ✅ Flexibility for edge cases
  • ⚠️ Requires understanding of all policy implications
  • ⚠️ Can create inconsistent experiences if misconfigured

Terminal Execution Policy

Controls what the agent can run in your terminal and how much approval is required.

Auto

Behavior: Agent can execute terminal commands automatically

Use cases:

  • Agent-driven or agent-assisted modes
  • Trusted environments (development machines)
  • Repetitive build/test workflows

What the agent can do:

bash
# File operations
ls, cat, mkdir, cp, mv, rm

# Version control
git status, git add, git commit, git push

# Package management
npm install, pip install, cargo build

# Running scripts
npm run dev, python test.py, ./build.sh

Safeguards:

  • Agent logs all commands to Artifacts
  • Destructive operations (rm -rf) typically trigger warnings
  • You can interrupt execution at any time

Manual Review (implied by other modes)

Behavior: Agent proposes commands but waits for your approval

Use cases:

  • Review-driven development
  • Production systems
  • Unfamiliar codebases

Workflow:

  1. Agent: "I need to run npm install axios to add HTTP client"
  2. You: Review command, approve or modify
  3. Agent: Executes approved command

Review Policy

Controls how the agent handles intermediate decisions and outputs.

Agent Decides

Behavior: Agent makes decisions autonomously based on task requirements

Use cases:

  • Agent-driven development
  • Exploratory prototyping
  • Well-scoped tasks with clear objectives

What happens:

  • Agent chooses libraries, frameworks, patterns without asking
  • Makes architectural decisions aligned with best practices
  • Implements edge cases using its judgment
  • Only surfaces major decision points

Example:

Task: "Build a user authentication system"

Agent decides autonomously:

  • Use bcrypt for password hashing (security best practice)
  • Implement rate limiting (prevents abuse)
  • Add password strength validation (UX improvement)
  • Store sessions in Redis (performance choice)

You review the final implementation but don't get asked about each decision along the way.


Request Review (implied by agent-assisted)

Behavior: Agent requests confirmation on significant decisions

Use cases:

  • Agent-assisted development (recommended)
  • When domain expertise matters
  • Projects with established patterns

What happens:

  • Agent proposes approach before implementing
  • Asks about technology choices (libraries, frameworks)
  • Confirms architectural decisions
  • Presents options for ambiguous requirements

Example:

Task: "Build a user authentication system"

Agent asks:

  • "Should I use JWT tokens or session-based auth?"
  • "Do you want OAuth integration (Google, GitHub)?"
  • "What password complexity requirements do you need?"

Then implements based on your guidance

This mode catches misalignments early while still letting the agent handle implementation details.

Browser Permissions

Use the Default Allowlist for the Browser

What it means: Agent can access specific domains and perform certain browser actions without asking

Default allowlist likely includes:

  • Documentation sites (MDN, Stack Overflow, official docs)
  • Package registries (npm, PyPI, crates.io)
  • Repository hosts (GitHub, GitLab)
  • Development tools (localhost, staging domains)

Blocked by default:

  • Social media
  • E-commerce
  • Banking/financial sites
  • Email/personal accounts

Why it matters: The agent can use browser automation (via Gemini 2.5 Computer Use) to:

  • Look up API documentation
  • Search for error messages
  • Find code examples
  • Check package compatibility
  • Test web applications on localhost

Without browser access, the agent is limited to what it "knows" from training data.

Choosing the Right Configuration

Quick Decision Tree

Want maximum speed and full autonomy?Agent-driven + Auto terminal + Agent decides + Default allowlist

Want balanced collaboration? (Most common)Agent-assisted + Auto terminal + Request review + Default allowlist

Need strict oversight?Review-driven + Manual terminal + Request review + Restricted browser

Have specific requirements?Custom configuration + Define policies individually

Considerations by Project Type

Project TypeRecommended ModeReasoning
Side project / LearningAgent-assistedLearn agentic workflows safely
Proof of conceptAgent-drivenMaximize velocity for exploration
Production featureAgent-assistedBalance speed with quality
Critical system / ComplianceReview-drivenMaintain full control
Open source contributionAgent-assistedIterate publicly, maintain standards
Embedded / HardwareCustomSpecific tool/test requirements

Team Workflows

Solo developer: Start with agent-assisted, graduate to agent-driven as trust builds

Pair/mob programming: Use agent-assisted with shared review sessions

Code review culture: Agent-driven for initial implementation, human review before PR

Regulated industry: Review-driven or custom with audit trails enabled

Changing Modes Mid-Project

You're not locked into your initial choice. Antigravity allows switching modes as your needs evolve:

Common progressions:

  1. Review-driven → Agent-assisted

    • After learning the codebase
    • Once you trust the agent's judgment
  2. Agent-assisted → Agent-driven

    • For well-understood task types
    • When deadlines require maximum velocity
  3. Agent-driven → Review-driven

    • When bugs appear in agent-generated code
    • Before major refactors or deployments
  4. Any mode → Custom

    • When standard modes don't quite fit
    • For hybrid workflows (e.g., fast iteration + strict deployment)

The Philosophy Behind Modes

These modes reflect Google's broader vision for agentic development:

Traditional tools:

  • Human writes code
  • AI suggests next line/function
  • Human accepts/rejects

Antigravity's approach:

  • Human describes task
  • Agent plans and executes
  • Human supervises and guides

The operation modes exist because there's no one-size-fits-all level of autonomy. Different projects, teams, and contexts require different balances.

By making this choice explicit upfront, Antigravity encourages intentional thinking about:

  • How much do you trust the agent?
  • How critical is this work?
  • How much oversight can you provide?
  • What's your learning curve tolerance?

Final Recommendations

If unsure, start with Agent-Assisted (Google's recommended default)

  • It's the best way to learn what agents can handle
  • You'll quickly identify tasks suitable for more/less autonomy
  • Provides safety nets while still feeling productive

Experiment across projects:

  • Use agent-driven for throwaway prototypes
  • Use agent-assisted for feature development
  • Use review-driven for critical infrastructure

Watch for these signals:

You should increase autonomy if:

  • You're frequently approving agent suggestions unchanged
  • The agent consistently makes good decisions
  • Review overhead is slowing you down

You should decrease autonomy if:

  • Agent frequently misunderstands requirements
  • You're catching errors in late-stage reviews
  • Domain expertise is critical to decisions

The goal isn't to find the "perfect" mode—it's to match the mode to the context and adjust as you learn what works.

Links

Google Antigravity Overview

  • URL: Internal link
  • Summary: Main article covering Antigravity's architecture, four key tenets, and overall vision for agent-first development.
  • Related: Google Antigravity - Overview

Gemini 3 Agentic Capabilities

VentureBeat: Agent-First Architecture