Book TOC · Previous · Chapter 2 of 8 · Next

Chapter 2: Enterprise Coding Agents, Secure Sandboxes & Antigravity Customization

Official Exam Guide Subsections Consolidated: 2.1, 2.2

Chapter Consolidation Telemetry: Synthesizes 50 architectural scenarios across 2 Exam Subsections and 5 Official Considerations into consolidated takeaway pillars, paired with 2 Reference Architecture Mermaid Diagrams and 14 Curated Visual Illustrations.

Chapter Focus: Private MCP bridges, GKE Sandbox (gVisor) + NetworkPolicy isolation, TDD refactoring loops, and Antigravity Skills, Hooks, Plugins, Subagents & CLI.

Subsection 2.1: Using Coding Agents Effectively: MCP Servers, Secure Sandboxes, and Code Optimization

Part II: Using Coding Agents for Application Development (~17% of Exam) · 3 Official Considerations · 29 Scenarios Consolidated

Domain Overview and Reference Architecture

Why Autonomous Coding Agents Demand Zero-Trust Tooling, Sandboxes & AST Verification

Section 2 of the exam (~17% weight) tests a rapidly maturing discipline: architecting and operating autonomous coding agents such as Google Antigravity and Claude Code on Google Cloud. Unlike a passive autocomplete plugin that suggests a single line of code, an agentic coding assistant can autonomously read repositories, query internal databases via Model Context Protocol (MCP) servers, execute shell commands, run test suites, and refactor multi-file architectures.

That autonomy introduces three high-stakes architectural challenges:

1. Connecting Coding Agents to Private Enterprise Context (2.1a): How do you let Claude Code or Antigravity inspect production BigQuery schemas, internal OpenAPI specs, or Git repositories without exposing endpoints to the public internet, distributing static Service Account JSON keys onto developer laptops, or overflowing the model's context window with 50MB of raw database dumps?
2. Containing the Blast Radius of Autonomous Code Execution (2.1b): When a coding agent writes and executes untrusted code or enters an autonomous test-fix loop, what stops a hallucinated command or a malicious dependency (npm install / pip install prompt injection) from exfiltrating credentials over the network, modifying the host kernel, or exhausting compute quotas?
3. Verifying Refactoring, Optimization, and Security Patching (2.1c): How do you ensure a coding agent actually fixes an $O(N^2)$ latency bottleneck, an N+1 ORM query, or a SQL injection vulnerability—without breaking existing API contracts or introducing subtle regressions?

Core Foundational Primitives & Mental Models (Subsection 2.1)

Official Exam Considerations & Consolidated Takeaways (Subsection 2.1)

Consideration 2.1a: Configuring coding agents with model context protocol (mcp) servers, custom skills, and access to tools (e.g., antigravity and claude code on google cloud)

When integrating Antigravity and Claude Code on Google Cloud with enterprise tools via Model Context Protocol (MCP):

• Private Network Connectivity: Host enterprise MCP servers inside your VPC (on private GKE or Cloud Run) and expose them via an Internal Application Load Balancer and Private Service Connect (PSC) so coding agent traffic never traverses the public internet.
• Zero Static Keys (Workload Identity Federation / Short-Lived OAuth): Never place static service account JSON keys in local .mcp.json or settings.json files on developer laptops. Authenticate coding agents using Workload Identity Federation or short-lived OAuth 2.0 tokens via gcloud auth application-default login.
• Least-Privilege Schema Inspection: When a coding agent needs to write SQL or BigQuery queries, grant its MCP server identity roles/bigquery.metadataViewer (or expose table schemas as read-only MCP Resources / INFORMATION_SCHEMA views)—never roles/bigquery.admin or raw access to production customer PII rows!
• Preventing Context Window Overflow: Configure MCP servers to enforce pagination, row limits, and output truncation so a single tool call cannot dump a 100MB log file into the coding agent's active context window.

Takeaway 1: Secure VPC-Internal MCP Server Integration for Claude Code (gke:networking · vpc:private_service_connect · iam:workload_identity_federation)

• Core Concept: Configuring transport and network security for Model Context Protocol (MCP) servers hosted in Google Cloud Virtual Private Cloud (VPC)
• Scenario Trigger & Requirement: The scenario requires connecting a developer coding agent (Claude Code) to a Model Context Protocol (MCP) server running inside a private Google Kubernetes Engine (GKE) environment. Key constraints are: 1) Endpoints must not be exposed to the public internet, and 2) Static service account keys must not be used.
• Winning Architecture & Implementation: Expose the MCP server through an internal Application Load Balancer with Private Service Connect and authenticate requests with short-lived credentials through Workload Identity Federation. This is the recommended Google Cloud architecture. An internal Application Load Balancer combined with Private Service Connect enables secure, private connectivity directly within your Virtual Private Cloud (VPC) network without routing traffic over the public internet.
• Exam Traps to Reject: External load balancers use public internet endpoints, and long-lived API keys violate credential best practices. Public load balancers expose services to the internet, and static JSON keys violate key management security policies.

Takeaway 2: MCP Tool Schema Definition for BigQuery Data Inspection (bigquery · vertex_ai:agents)

• Core Concept: Defining custom MCP tools using JSON Schema for agent-driven schema discovery
• Scenario Trigger & Requirement: Configuring a Model Context Protocol (MCP) server tool for a coding agent to interact with BigQuery. The goal is to provide a robust tool interface that guides the agent to generate accurate, valid arguments without hallucinating parameter names.
• Winning Architecture & Implementation: Define the tool in the MCP server specification with an inputSchema object that uses standard JSON Schema to specify property types, required fields, and explicit parameter descriptions. Model Context Protocol (MCP) uses JSON Schema to expose tool signatures to coding agents. Providing a complete inputSchema with property types (for example, strings), required keys (projectId, datasetId, tableId), and descriptive field explanations allows the agent to inspect the schema and construct well-formed function calls.
• Exam Traps to Reject: Hardcoding environment parameters eliminates tool reusability and fails to solve proper parameter schema definition. Unstructured instructions and regex parsing fail to provide deterministic parameter validation and break MCP tool calling contracts.

Takeaway 3: Context Window Management via MCP Tool Response Truncation (cloud_logging · vertex_ai:agents · cloud_functions)

• Core Concept: Managing large payload responses from MCP servers to prevent token context exhaustion
• Scenario Trigger & Requirement: The core problem is token context exhaustion caused by an MCP tool returning an unbounded, massive payload (thousands of raw log lines) to an LLM-based coding agent. The goal is to identify the best architectural practice in MCP tool design to provide necessary debugging information without overflowing context limits.
• Winning Architecture & Implementation: Update the MCP server tool implementation to perform server-side filtering, return concise error summaries, and support pagination. When integrating coding agents with external data sources through Model Context Protocol (MCP) tools, large raw outputs (such as thousands of log entries) can rapidly exceed the context window or degrade model reasoning quality.
• Exam Traps to Reject: Base64 encoding increases token usage and obscures text from direct reasoning by the model. Model temperature controls randomness in generation, not context window limits or payload capacity.

Takeaway 4: Least Privilege IAM Scoping for Coding Agent Execution Tools (iam:roles · cloud_run:deployments)

• Core Concept: Enforcing fine-grained IAM permissions for tools invoked by coding agents
• Scenario Trigger & Requirement: The scenario requires configuring an automated coding agent (like Antigravity or custom deployment tools) to manage Cloud Run deployments across multiple environments. The primary constraints are adhering to the principle of least privilege and preventing unauthorized access to unrelated resources.
• Winning Architecture & Implementation: Create a custom IAM role containing only the required Cloud Run permissions and bind this role to the agent service account on the specific Cloud Run resources. Creating a custom Identity and Access Management (IAM) role that contains only the granular permissions required for the task (such as run.services.update) adheres strictly to the principle of least privilege.
• Exam Traps to Reject: Audit logging monitors actions after the fact and does not enforce least privilege or prevent unauthorized access. The Editor role provides overly broad access across the entire project or folder.

Consolidated Golden Rules (Consideration 2.1a):

• Always keep internal developer tools and MCP servers on private networks by utilizing Internal Load Balancing and Private Service Connect.
• Never distribute static service account JSON keys for agent or developer authentication; enforce Workload Identity Federation or short-lived OAuth credentials.
• Model Context Protocol (MCP) servers act as bridges to private enterprise APIs and must follow standard zero-trust security postures.
• Model Context Protocol (MCP) tools require strict JSON Schema definitions in the inputSchema property.
• Explicit parameter descriptions and type constraints prevent agent hallucinations during tool invocation.
• Proper schema validation ensures predictable and structured interactions between coding agents and cloud resources like BigQuery.

Consideration 2.1b: Using coding agents in secure sandboxes (e.g., google kubernetes engine [gke], cloud workstations, and antigravity)

Google Cloud provides three complementary sandboxing layers for coding agents:

• Antigravity Built-in Terminal Sandbox: Restricts file-system writes to the active workspace and scratch directories and blocks unauthorized network egress by default, requiring explicit human approval (BypassSandbox) or pre-tool hooks for sensitive operations.
• Cloud Workstations (Managed Developer Environments): Runs the entire IDE and coding agent inside a Google Cloud VPC—eliminating local source code storage on developer laptops, enforcing VPC Service Controls (VPC-SC), disabling public IP addresses, and routing internet package fetches only through audited Cloud NAT / Secure Web Proxy allowlists.
• Google Kubernetes Engine (GKE) with GKE Sandbox (gVisor): When an autonomous agent executes untrusted or dynamically generated code at scale (e.g., automated PR verification or benchmark sandboxes), run pods on GKE Sandbox (gVisor) to isolate the host Linux kernel in user space, combined with Kubernetes NetworkPolicies (default deny egress), ResourceQuotas/LimitRanges, and non-root security contexts.

Takeaway 1: Restricting External Egress for Untrusted Agent-Generated Code in GKE Sandbox (gke:security · gke:sandbox · gke:network_policy)

• Core Concept: Network isolation and gVisor kernel sandboxing for dynamic agent code execution
• Scenario Trigger & Requirement: The scenario requires securing the dynamic execution of untrusted, agent-generated Python scripts on Google Kubernetes Engine (GKE).
• Winning Architecture & Implementation: Enable GKE Sandbox on the cluster node pool and apply a Kubernetes NetworkPolicy with a default-deny egress rule to the agent pods. GKE Sandbox provides kernel-level defense-in-depth by running containers inside gVisor, a user-space kernel that intercepts and inspects system calls.
• Exam Traps to Reject: Privileged containers weaken isolation, and Cloud NAT facilitates outbound internet communication instead of blocking it. Cloud Armor and IAP manage incoming traffic and user authentication rather than container sandboxing and egress control.

Takeaway 2: Securing Developer Workspaces with Cloud Workstations and VPC Service Controls (cloud_workstations · vpc_service_controls · networking:vpc)

• Core Concept: Cloud Workstations perimeter security and VPC-SC integration
• Scenario Trigger & Requirement: The scenario requires creating a secure sandbox environment for AI coding agents that run in developer workspaces. The key requirement is preventing sensitive intellectual property and source code from leaving the corporate network perimeter (mitigating data exfiltration risk), while preventing unauthorized software package downloads.
• Winning Architecture & Implementation: Deploy Cloud Workstations in a private Virtual Private Cloud (VPC) network enclosed by a VPC Service Controls perimeter, disable public IP addresses, and restrict external egress. Cloud Workstations provides managed, customizable development environments that integrate directly with Google Cloud networking and security features.
• Exam Traps to Reject: Cloud Armor protects incoming traffic at load balancers, not outbound workstation connections. Host-level firewalls can be bypassed locally and do not provide centralized cloud perimeter enforcement.

Takeaway 3: Resource Quotas and Blast Radius Control for Agentic Loops in Antigravity (gke · gke:workloads · kubernetes_engine:sandboxes)

• Core Concept: Preventing denial of service and runaway loops via sandbox resource limits
• Scenario Trigger & Requirement: A multi-tenant environment on Google Kubernetes Engine (GKE) where autonomous AI coding agents execute arbitrary code (unit tests). An agent generated an infinite recursive loop, leading to memory exhaustion that crashed neighboring tenant workloads (the 'blast radius' problem).
• Winning Architecture & Implementation: Define explicit CPU and memory resource requests and limits, along with process limits (pidsLimit), on each sandbox container specification. Configuring explicit CPU and memory resource limits alongside process limits (pidsLimit) in the container specification establishes strict control boundaries using Linux control groups (cgroups).
• Exam Traps to Reject: Cluster autoscaling adds compute capacity but does not prevent an unconstrained process from crashing its local node. Increasing neighbor limits fails to restrict the offending sandbox container from exhausting shared host memory.

Consolidated Golden Rules (Consideration 2.1b):

• Use GKE Sandbox (gVisor) when running untrusted or multi-tenant code workloads to enforce kernel-level isolation.
• Enforce Kubernetes NetworkPolicy with default-deny rules to prevent unauthorized pod egress and data exfiltration.
• Distinguish between host-level security (Shielded Nodes) and container-level sandboxing (GKE Sandbox).
• Use Cloud Workstations without public IP addresses inside a VPC Service Controls perimeter to protect against data exfiltration.
• IAM manages access permissions for cloud services, but network perimeter controls are required to block unauthorized network egress.
• Cloud Armor protects inbound traffic at load balancers, whereas VPC Service Controls defines security perimeters around cloud services and VPC networks.

Consideration 2.1c: Using coding agents to refactor source code, optimize execution runtimes, and patch application-layer vulnerabilities

To use coding agents effectively for brownfield codebases:

• AST-Guided & Context-Aware Vulnerability Patching: Rather than feeding raw grep lines to an LLM, feed Static Application Security Testing (SAST) findings alongside the Abstract Syntax Tree (AST) call graph so the agent remediates root causes (e.g., replacing string-concatenated SQL with parameterized prepared statements) and verifies the fix by running exploit regression tests in the sandbox.
• Data-Driven Runtime Optimization: Pair the coding agent with Cloud Profiler flamegraphs, database EXPLAIN ANALYZE query plans, or async I/O traces so it targets actual bottlenecks (e.g., replacing synchronous blocking HTTP loops with asyncio.gather, or fixing ORM N+1 queries with select_related / JOINs).
• The Architect–Builder Model Split: In Google Antigravity, use a high-reasoning model (Gemini Pro) as the Architect to analyze multi-file dependencies and produce the refactoring plan, and delegate deterministic file edits and test runs to a faster, cost-effective model (Gemini Flash) acting as the Builder.

Takeaway 1: Refactoring Blocking I/O to Asynchronous Execution (cloud_run · gemini_code_assist)

• Core Concept: Migrating synchronous blocking network calls to non-blocking asynchronous patterns to eliminate thread starvation and enhance service concurrency.
• Scenario Trigger & Requirement: The scenario requires refactoring a legacy microservice on Cloud Run where blocking sequential network requests degrade performance during peak traffic.
• Winning Architecture & Implementation: Provide the agent with the existing interface definitions and unit tests, and instruct the agent to implement asynchronous non-blocking calls with explicit timeouts while preserving function contracts. When directing a coding agent to refactor synchronous blocking input/output (I/O) to asynchronous patterns, providing interface specifications and test suites gives the agent clear boundaries.
• Exam Traps to Reject: Spawning raw threads causes resource exhaustion, and deleting tests removes critical quality safeguards. Rewriting the entire application into a new language is unnecessary, disruptive, and risky.

Takeaway 2: Remediating SQL Injection via Contextual AST Analysis (cloud_code · vertex_ai:code_assist)

• Core Concept: Patching application-layer injection vulnerabilities by transforming raw dynamic SQL concatenation into parameterized queries using code-aware agents.
• Scenario Trigger & Requirement: Legacy code containing SQL injection vulnerabilities caused by dynamic string interpolation. The goal is to safely direct an automated coding agent to refactor these queries to parameterized queries while preserving business logic and avoiding architectural breakage.
• Winning Architecture & Implementation: Provide the coding agent with the static application security testing (SAST) findings and database schema definitions, directing the agent to replace dynamic string concatenations with parameterized statements. Supplying the coding agent with the specific static application security testing (SAST) reports identifies exact line numbers, call paths, and vulnerable variables.
• Exam Traps to Reject: Catching and suppressing database exceptions masks errors without preventing malicious SQL execution. Regex-based input sanitization is prone to bypasses and does not solve the root cause of dynamic query concatenation.

Takeaway 3: Optimizing Algorithmic Time Complexity via Profiling Data (cloud_profiler · gemini_code_assist · compute_engine)

• Core Concept: Using CPU profiling flame graphs and benchmark metrics as agent input to rewrite inefficient nested algorithms into optimal data structures.
• Scenario Trigger & Requirement: A data processing pipeline failing service level agreements (SLAs) due to an O(N^2) quadratic time complexity algorithm. Cloud Profiler provides precise diagnostic evidence (flame graphs highlighting nested loop hotspot lines).
• Winning Architecture & Implementation: Prompt the coding agent with the hotspot line numbers, function code, unit tests, and a requirement to replace nested scans with hash map lookups. Providing the coding agent with the exact hotspot line numbers identified by Cloud Profiler, the relevant source code, existing unit tests, and specific algorithmic requirements (such as using hash sets or dictionaries for O(1) lookups) gives the model the exact context required to optimize time complexity to O(N) while maintaining correctness and edge-case behavior.
• Exam Traps to Reject: Scaling hardware resources does not fix quadratic algorithmic complexity and increases operational costs. Multi-threading does not fix algorithmic bottlenecks, and suppressing test failures risks breaking application logic.

Takeaway 4: Eliminating N+1 ORM Query Performance Bottlenecks (cloud_code:gemini · gke · cloud_sql)

• Core Concept: Optimizing runtime database roundtrips by refactoring object-relational mapping logic from iterative fetches to batched eager loading.
• Scenario Trigger & Requirement: An e-commerce backend suffering from the classic N+1 query problem where an ORM performs iterative database round trips inside a loop. Requires directing an AI coding agent to refactor this data access logic to optimize runtime latency and CPU usage while preventing unintended memory inflation and preserving the return data models.
• Winning Architecture & Implementation: Provide the coding agent with the entity relationships and query traces, instructing the agent to refactor the iterative fetches into batched eager loading joins while preserving existing output models. The described issue is a classic N+1 query problem, where an application fetches a list of parent entities and subsequently issues individual database queries for each child record inside an iteration.
• Exam Traps to Reject: Wrapping iterative queries in parallel threads still generates N+1 queries and risks exhausting database connection pools. Global eager loading causes severe overfetching and excessive memory inflation across unrelated endpoints.

Consolidated Golden Rules (Consideration 2.1c):

• Refactoring blocking I/O to asynchronous calls resolves thread starvation and enhances concurrency.
• Always provide coding agents with existing interface definitions and unit tests to preserve contracts and prevent regressions.
• Specify non-functional requirements such as explicit timeouts and cancellation propagation during refactoring prompts.
• Dynamic string concatenation in SQL queries creates critical SQL injection vulnerabilities.
• Parameterized statements and prepared queries separate code from data, neutralizing injection risks.
• Coding agents perform best when supplied with SAST vulnerability diagnostics alongside relevant database schema definitions.

Multi-Constraint Production Architecture Scenarios (Subsection 2.1)

Head-to-Head Architectural Trade-Off Clinic (Subsection 2.1)

Rapid Pattern-Trigger Cheat Sheet (Subsection 2.1)

Curated Official Google Cloud Documentation (Subsection 2.1)

• Google Cloud Vertex AI Agents Overview — Provides architectural details on building and connecting AI agents with enterprise tools, APIs, and contextual data sources.
• Gemini Code Assist Documentation — Covers how generative AI coding assistants integrate with developer environments and developer tooling.
• Google Cloud Developer Tools Overview — Provides an overview of development and productivity tools available on Google Cloud.
• Model Context Protocol Documentation — Documentation outlining the standard architecture of the Model Context Protocol (MCP) for connecting AI assistants to data sources and developer tools.
• Anthropic's Claude on Google Cloud models — Describes Claude models on Google Cloud, including their coding and agentic development capabilities.
• Cloud Workstations Overview — Explains managed developer workspaces and integrating developer tooling inside Google Cloud.
• Security best practices for Cloud Workstations — Details how to configure private gateways, VPC Service Controls, and IAM roles to create a sandboxed development environment.
• GKE Sandbox overview — Provides detailed information about running untrusted workloads in secure, isolated containers using GKE Sandbox.
• Google Kubernetes Engine (GKE) overview — Explains the capabilities, architecture, and orchestration features of Google Kubernetes Engine.
• Gemini Code Assist Overview — Provides details on AI-assisted development capabilities including code generation, transformation, and refactoring.
• Security Best Practices for Generative AI Applications — Explains risk containment patterns including runtime sandboxing, principle of least privilege, and protecting infrastructure from unverified generated code.
• Google Cloud MCP servers overview — Explains how MCP standardizes AI applications connecting to tools, data sources, and Google Cloud services.

Subsection 2.2: Customizing Coding Agents for Enterprise Workflows: Antigravity Skills, Hooks, Plugins, Subagents, and Agents CLI

Part II: Using Coding Agents for Application Development (~17% of Exam) · 2 Official Considerations · 21 Scenarios Consolidated

Domain Overview and Reference Architecture

The Enterprise Customization Hierarchy: Rules vs. Skills vs. Hooks vs. Subagents vs. Plugins

Out-of-the-box coding agents know general Python, Go, and TypeScript, but they know nothing about your company's internal deployment runbooks, architectural conventions, or compliance gates. Yet when enterprises try to customize their coding agents, they routinely confuse the five customization primitives in Google Antigravity (2.2a) and the operational lifecycle managed by Agents CLI (2.2b):

1. Why Putting Everything in Rules Fails: Workspace Rules are always loaded into the system prompt to establish coding style and conventions. If a team dumps 40 specialized deployment runbooks into Rules, the agent burns tens of thousands of context tokens on every turn (Context Bloat). Conversely, if a team puts a critical security gate ("Never run git push --force or terraform destroy" ) into Rules, an adversarial prompt injection in a README or issue description can trick the LLM into ignoring the rule!
2. The Solution — Progressive Disclosure (Skills) & Deterministic Interception (Hooks):
3. Agent Skills (SKILL.md): Use Progressive Disclosure—at startup, Antigravity reads only the compact YAML frontmatter (name and description) of each skill. Only when the user's task matches a skill's description does the agent read the full SKILL.md instructions, helper scripts/, and references/!
4. Extension Hooks (Pre-Tool / Post-Tool): Deterministic code/scripts executed by the Antigravity runtime outside the LLM before or after a tool call. A Pre-Tool Execution Hook inspects the exact CLI arguments and blocks git push origin main with a non-zero exit code—100% immune to prompt injection!

Core Foundational Primitives & Mental Models (Subsection 2.2)

Official Exam Considerations & Consolidated Takeaways (Subsection 2.2)

Consideration 2.2a: Creating skills, plugins, extensions hooks, rules, and subagents using antigravity

Master the exact responsibility of each customization primitive in Google Antigravity:

• Workspace Rules: Always-active markdown instructions defining repository coding standards, naming conventions, and preferred libraries. Use for ubiquitous style guidance, never for high-stakes security blocking or voluminous runbooks.
• Agent Skills (SKILL.md): Folders containing a SKILL.md file with YAML frontmatter (name, description) plus optional scripts/, examples/, and references/. Follows 3-stage Progressive Disclosure: (1) scan metadata at startup for near-zero token cost, (2) load SKILL.md instructions only when triggered, and (3) execute bundled scripts or load reference docs only as needed.
• Extension Hooks (Pre-Tool / Post-Tool): Deterministic lifecycle interceptors. Use a Pre-Tool Execution Hook to inspect tool arguments and deterministically block forbidden commands (git push to production, rm -rf, exposing secrets). Use a Post-Tool Execution Hook to automatically run code formatters (gofmt, prettier) or security linters after every file edit.
• Subagents: Specialized worker agents invoked in an isolated conversation context with a strictly scoped tool manifest (for example, a test-runner subagent granted test execution and read-only source access, but denied file-write tools so it cannot "pass" a failing test by deleting the assertion!).
• Plugins: Namespaced, versioned bundles that package Skills, Subagents, Rules, Hooks, and MCP server configurations into a single installable unit for enterprise-wide distribution across engineering teams.

Takeaway 1: Enterprise Security Gate via Pre-Tool Execution Hooks (cloud_functions · cloud_dlp · vertex_ai:agents)

• Core Concept: Execution Hooks and Interceptors
• Scenario Trigger & Requirement: A scenario where an enterprise coding agent in Antigravity needs to interact with critical infrastructure (a database). The core challenge is preventing data leaks (credit card numbers) and insecure queries (unparameterized SQL) by inspecting and validating payloads deterministically before the tool call executes.
• Winning Architecture & Implementation: Implement a pre-tool execution hook to intercept tool arguments, inspect and redact sensitive data, and block non-compliant commands before execution. A pre-tool execution hook acts as a deterministic security gate that intercepts function call arguments before the tool executes.
• Exam Traps to Reject: Post-tool hooks run after tool execution, failing to prevent sensitive payloads from reaching external systems. Prompt instructions are non-deterministic and cannot guarantee strict compliance with security rules.

Takeaway 2: Enforcing Enterprise Architecture Guidelines via Workspace Rules (vertex_ai:agents · cloud_run)

• Core Concept: Agent Rules and Workspace Context
• Scenario Trigger & Requirement: The scenario requires enforcing specific enterprise coding standards (Cloud Run structure, structured JSON logging, dependency restrictions) within a repository using an Antigravity coding agent. The key requirements are automating these guardrails across the repository and avoiding modifications to the base foundation model prompts.
• Winning Architecture & Implementation: Define a repository-level workspace rules configuration file in the codebase root to enforce coding standards, logging formats, and dependency restrictions. Workspace and repository-level rules files (such as .agentrules or project instruction configurations) provide deterministic, version-controlled guidelines that the coding agent reads into context for every interaction within that workspace.
• Exam Traps to Reject: Manual prompt appending introduces human error and does not provide automated repository-wide governance. Global foundational model adjustments lack repository-level granularity and affect unrelated workloads.

Takeaway 3: Integrating Proprietary Internal APIs as Custom Skills (vertex_ai:agent_builder · vertex_ai:extensions)

• Core Concept: Custom Skill Authoring
• Scenario Trigger & Requirement: Integrating an undocumented, proprietary internal deployment orchestration service into an Antigravity coding agent. The core requirement is enabling safe, deterministic, and autonomous invocation by defining custom skills.
• Winning Architecture & Implementation: Define an OpenAPI specification that details endpoint paths, parameter schemas, and descriptions, and register the specification as an Antigravity tool definition. Creating a structured OpenAPI specification provides clear endpoint paths, typed parameter schemas, and semantic descriptions.
• Exam Traps to Reject: Unstructured prompts lack deterministic parameter definitions and strict execution contracts. Shell scripts without schemas fail to provide structured tool definitions and input validation.

Takeaway 4: Multi-Agent Delegation for Security and Code Quality (vertex_ai:agents · cloud_code)

• Core Concept: Subagents and Role Specialization
• Scenario Trigger & Requirement: Two common problems in single-agent architectures: context bloat and conflicting goals when combining diverse tasks (feature generation, security audits, and cost optimization). The goal is to identify the proper agentic pattern to isolate contexts while enabling delegation.
• Winning Architecture & Implementation: Configure specialized subagents with isolated context boundaries and dedicated toolsets, coordinated by the primary supervisor agent. Configuring specialized subagents allows each agent to operate within an isolated context window with dedicated system instructions and tools.
• Exam Traps to Reject: Static scripts eliminate the dynamic reasoning and automated remediation capabilities of AI agents. Combining all tasks into a single prompt exacerbates context bloat and introduces conflicting goals.

Consolidated Golden Rules (Consideration 2.2a):

• Use pre-tool execution hooks as deterministic gates to validate and sanitize arguments before calling external APIs.
• Do not rely solely on system prompt instructions for critical security policies and data sanitization.
• Post-execution hooks and audit logs are reactive and cannot prevent sensitive tool payloads from reaching external systems.
• Use repository-level workspace rule configuration files to enforce enterprise coding standards and library restrictions automatically.
• Workspace rules provide version-controlled, deterministic context without modifying foundation model system prompts.
• Avoid manual prompt copying or destructive post-processing hooks for agent governance.

Consideration 2.2b: Augmenting antigravity with agents cli to build, scale, govern, and optimize deployed agents

The Agents CLI in Agent Platform bridges local agentic development in Antigravity/Claude Code with enterprise production operations:

• Scaffolding & Skill Installation: Developers run Agents CLI setup commands to install official Google Cloud agent development skills, scaffold ADK project templates, and register capabilities with Skill Registry and Agent Registry.
• Automated Evaluation & Profiling in CI/CD: Agents CLI executes headless evaluation suites (evalset), compares trajectory metrics against golden baselines, and profiles token consumption and tool-invocation latency across deployed agent versions.
• Fleet Governance & Scaling: Platform engineering teams use Agents CLI to enforce organization-wide guardrail policies, promote agent artifacts across dev → staging → prod environments, and configure horizontal autoscaling parameters on Agent Runtime.

Takeaway 1: Automated Multi-Environment Build and Packaging (artifact_registry · cloud_build)

• Core Concept: Using the Agents CLI within CI/CD pipelines to build and package Antigravity agent extensions consistently across staging and production.
• Scenario Trigger & Requirement: The scenario requires automating the validation, compilation, and immutable packaging of coding agent extensions and tool bindings within a CI/CD pipeline for consumption by Antigravity across multiple environments.
• Winning Architecture & Implementation: Use the Agents CLI to validate and package tool bindings into versioned container or OCI artifacts, and publish them to Artifact Registry through your automated pipeline. Using the Agents command-line interface (CLI) directly within automated CI/CD pipelines ensures that all agent extensions, schemas, and tool bindings are systematically validated, compiled, and bundled into immutable, versioned artifacts.
• Exam Traps to Reject: Deploying uncompiled configurations directly to runtime services bypasses build validation and artifact management. Manual exports from local clients bypass CI/CD automation and lack automated validation.

Takeaway 2: Fleet-Wide Policy and Guardrail Governance (cloud_ai:agents · cloud_ai:antigravity)

• Core Concept: Deploying governance policies and behavioral constraints to Antigravity agents via centralized Agents CLI manifests.
• Scenario Trigger & Requirement: The question requires establishing centralized governance, prompt data redaction, and domain access controls across a distributed fleet of Antigravity coding agents. The primary requirement is uniform fleet-wide enforcement across both local and remote environments.
• Winning Architecture & Implementation: Publish a signed enterprise policy bundle and deploy it across instances with the Agents CLI policy enforcement command. Centralized policy bundles managed through the Agents CLI allow enterprise administrators to distribute and enforce security, data redaction, and access guardrails across all managed Antigravity agent instances uniformly.
• Exam Traps to Reject: Git hooks do not govern real-time agent execution or prompt contexts. Manual client configuration is error-prone and does not scale across enterprise developer teams.

Takeaway 3: Horizontal Auto-Scaling for Remote Backend Agents (compute_engine:vm · kubernetes_engine:autoscaling)

• Core Concept: Scaling remote backend agent runtimes orchestrated via the Agents CLI based on developer concurrency.
• Scenario Trigger & Requirement: An enterprise environment with 2,000 concurrent developers running resource-heavy operations (indexing and code generation) in Antigravity. Bottlenecks occur during peak hours on the remote backend execution agents orchestrated via the Agents CLI.
• Winning Architecture & Implementation: Define maximum replica thresholds and target concurrency in the Agents CLI deployment specification, and enable cluster autoscaling on the underlying worker node pool. Configuring horizontal autoscaling requires defining maximum replica counts and target concurrency metrics in the agent deployment manifest.
• Exam Traps to Reject: Vertical scaling of a single container does not address high-concurrency bottlenecks and reaches compute boundaries quickly. Throttling developer requests creates high latency and diminishes developer productivity during interactive sessions.

Consolidated Golden Rules (Consideration 2.2b):

• Always use the Agents CLI inside CI/CD pipelines to validate and build agent extensions automatically.
• Store packaged agent extensions as immutable, versioned artifacts in Artifact Registry.
• Avoid manual configuration exports and runtime client-side compilations to ensure environment parity.
• Use declarative policy bundles with the Agents CLI to govern Antigravity coding agent behavior across distributed environments.
• Avoid relying on manual client configuration or client-side hooks for strict enterprise compliance.
• Centralized policy distribution ensures consistent data redaction and tool constraints across all developer instances.

Multi-Constraint Production Architecture Scenarios (Subsection 2.2)

Head-to-Head Architectural Trade-Off Clinic (Subsection 2.2)

Rapid Pattern-Trigger Cheat Sheet (Subsection 2.2)

Curated Official Google Cloud Documentation (Subsection 2.2)

• Overview of Generative AI Agents — Provides an overview of building, extending, and orchestrating generative AI agents using specialized tools and extensions.
• Data Agent Kit overview — Overview of the Antigravity CLI plugin and extension components for coding agents on Google Cloud.
• Vertex AI Agent Builder Overview — Provides guidance on building, governing, and constraining enterprise generative AI agents.
• Overview of Agent Architecture in Vertex AI — Describes multi-agent patterns, delegation strategies, and specialized subagents for complex software and reasoning tasks.
• Install the coding agent plugin — Explains installing a plugin that adds reusable tooling to coding agents, including Antigravity CLI.
• Gemini Code Assist overview — Provides architectural background on developer tooling, context awareness, and AI assistance within software engineering environments.
• Sensitive Data Protection (Cloud DLP) — Explains deterministic discovery, inspection, and redaction of sensitive data such as credit card numbers.
• Vertex AI Extensions Overview — Describes building and registering tools, extensions, and custom skills using OpenAPI specs in Google Cloud AI ecosystems.
• Multi-agent orchestration patterns — Covers design patterns for multi-agent architectures, context isolation, and supervisor coordination.
• Artifact Registry Overview — Documentation on managing and storing build artifacts and container images securely in Google Cloud.
• Cloud Build Overview — Google Cloud continuous integration and automated deployment best practices.
• Google Cloud Architecture Framework: Security, privacy, and compliance — Provides architectural principles for implementing centralized policy controls and compliance guardrails.

Book TOC · Previous · Chapter 2 of 8 · Next