In my Agent Protocols — MCP, A2A, A2UI, AG-UI and Agent to UI Protocol (A2UI) with Agent Development Kit (ADK) posts, I introduced A2UI — Google’s declarative generative UI protocol that lets AI agents return rich, interactive user interfaces across web, mobile, and desktop using JSON messages (createSurface, updateComponents, updateDataModel, and deleteSurface).

While standard JSON is an ideal wire protocol for client renderers (Lit, Angular, React, Flutter), having an LLM generate deeply nested wire JSON token-by-token is verbose, token-heavy, and adds latency. Recently, the A2UI team introduced Swappable Inference Formats and made A2UI Express the new default format in the A2UI Agent SDKs — cutting output tokens by ~3x–4x, shrinking system prompts by more than half, and speeding up UI generation without requiring any changes to client renderers.

In this post, I’ll briefly introduce A2UI Express and walk through how to use it, based on the interactive explorer sample in my genai-beyond-basics repository.

What is A2UI Express?

The key insight behind Swappable Inference Formats is decoupling the inference format (what the LLM writes) from the wire format (the standard A2UI JSON that client renderers consume):

Using the official A2UI Python Agent SDK (a2ui-agent-sdk, along with @a2ui/agent in TypeScript and a2ui_agent in Dart), you can swap the inference format factory on the server while keeping the wire protocol 100% identical:

• Direct JSON (DirectJsonFormatFactory): The original <a2ui-json> format where the LLM generates full A2UI Wire JSON directly.
• A2UI Express (ExpressFormatFactory, Default): A compact, Python-like positional DSL enclosed in <a2ui>...</a2ui> tags (root = Card(main_col), _ for omitted optional arguments, $/path = value for data-model bindings, and ?required(...) for validation checks). It cuts system prompt size by ~52–55%, reduces output tokens by ~3x–5.5x, and generates valid UIs reliably even with model thinking turned off (thinking_budget=0).
• Atom (AtomFormatFactory, Experimental): A Lisp S-expression DSL ((Card (Column :id "main_col" ...))).
• Elemental (ElementalFormatFactory, Experimental): An HTML Custom Elements DSL (<ui-card id="root"><ui-column id="main_col">...).

A2UI Express & Swappable Inference Formats Explorer

To see how this works in practice and compare the formats side-by-side, I built an interactive A2UI Express & Swappable Inference Formats Explorer using a2ui-agent-sdk, google-genai, FastAPI, and the official @a2ui/lit v0.9 Web Component renderer.

You can run the explorer locally with a single uv command:

uv run --with a2ui-agent-sdk --with google-genai --with fastapi --with uvicorn python app.py

Open http://127.0.0.1:8080 in your browser. At the top of the page, you can switch between 3 built-in UI examples (Restaurant Reservation Form, Login Form with Validation, and Notification Permission Card), toggle which format to compare against Direct JSON (A2UI Express, Atom, or Elemental), or enter a custom prompt and click ⚡ Generate Live with gemini-3.8-flash (thinking_budget=0):

Notice the summary metrics for the Restaurant Reservation Form example: A2UI Express uses 4.0x fewer output tokens (262 vs. 1,054 tokens), runs 4.0x faster, and shrinks the system prompt footprint by 55% (6,059 vs. 13,424 input tokens) by replacing full JSON Schemas with compact function signatures.

Let’s look at each part of the explorer and the code under the hood.

Python Agent SDK Code (a2ui-agent-sdk)

On the server, we configure A2uiGenerator with our component catalog (BasicCatalog(ProtocolVersion.V0_9)), optional few-shot examples, and our chosen inference_format_factory:

from a2ui.core.basic_catalog import BasicCatalog
from a2ui.core.schema import ProtocolVersion
from a2ui.inference_formats import ExpressFormatFactory  # or DirectJsonFormatFactory
from a2ui.processor import A2uiGenerator, CatalogConfig
​
catalog = BasicCatalog(ProtocolVersion.V0_9)
generator = A2uiGenerator(
    [CatalogConfig(catalog)],
    examples=[example_models],
    inference_format_factory=ExpressFormatFactory(),  # Default (or AtomFormatFactory / ElementalFormatFactory)
)
​
processor = generator.create_processor(
    {"v0.9": {"supportedCatalogIds": [catalog.catalog_id]}}
)

As shown in the explorer, the Python SDK setup is virtually identical between Direct JSON on the left and A2UI Express on the right — the only difference is passing DirectJsonFormatFactory() vs. ExpressFormatFactory():

What the LLM Generates (<a2ui-json> vs. <a2ui>)

Next, we inject processor.prompt_snippet into Gemini's system_instruction and ask the model to generate the UI with thinking_budget=0:

from google import genai
from google.genai import types
​
client = genai.Client()
​
response = client.models.generate_content(
    model="gemini-3.8-flash",
    contents="Create a reservation form for Xi'an Famous Foods with Name, Guests, Time, and Confirm button.",
    config=types.GenerateContentConfig(
        system_instruction=f"You are an A2UI assistant.\n\n{processor.prompt_snippet}",
        thinking_config=types.ThinkingConfig(thinking_budget=0),
    ),
)

In the next section of the explorer, we can compare what the LLM actually has to generate token-by-token:

On the left, Direct JSON requires 168 lines (3,796 characters / 1,054 tokens) of deeply nested JSON keys ("id", "component", "path"). On the right, A2UI Express expresses the exact same reservation form—including surface initialization, data-model bindings ($/reservation/...), layout hierarchy, a required validation check (?required(...)), and button event actions—in just 20 lines (945 characters / 262 tokens):

<a2ui>
surface("booking", sendDataModel=true)
$/reservation/name = "Alice"
$/reservation/guests = "3"
$/reservation/time = "7:30 PM"
$/reservation/notes = "No peanuts"
root = Card(main_col)
main_col = Column([title, subtitle, divider, name_field, row_fields, notes_field, actions])
title = Text("Confirm Reservation", "h2")
subtitle = Text("Xi'an Famous Foods • Friday Evening", "caption")
divider = Divider()
name_field = TextField("Guest Name", $/reservation/name, [?required("Guest name is required")])
row_fields = Row([guests_field, time_field])
guests_field = TextField("Party Size", $/reservation/guests)
time_field = TextField("Time", $/reservation/time)
notes_field = TextField("Dietary Notes", $/reservation/notes)
actions = Row([confirm_btn, cancel_btn], "end")
confirm_btn = Button(Text("Confirm Booking"), "primary", Event("confirm", {reservation: $/reservation}))
cancel_btn = Button(Text("Cancel"), _, Event("cancel", {}))
</a2ui>

What the Renderer Gets (Validated A2UI v0.9 Wire JSON)

Once the model responds, the server calls processor.parse_response(response.text) and converts the parsed A2uiPart models into standard wire message dictionaries via to_message_dicts():

from a2ui.inference_formats import to_message_dicts
from a2ui.parser import A2uiPart
​
parts = processor.parse_response(response.text)
wire_messages = [
    msg
    for part in parts
    if isinstance(part, A2uiPart)
    for msg in to_message_dicts(part.a2ui)
]

Comparing the output of processor.parse_response() across both columns in the explorer:

While the left column validates the <a2ui-json> payload and the right column compiles the <a2ui> Express DSL, both produce the exact same 166-line (3,766-character) A2UI v0.9 Wire JSON (createSurface, updateComponents, and updateDataModel).

Rendered UI (@a2ui/lit v0.9)

Finally, the server sends wire_messages to the browser, where @a2ui/web_core's MessageProcessor and @a2ui/lit's <a2ui-surface> Web Component render the interactive UI:

import '@a2ui/lit/v0_9'; // Registers <a2ui-surface>
import { basicCatalog } from '@a2ui/lit/v0_9';
import { MessageProcessor } from '@a2ui/web_core/v0_9';
​
const surfaceEl = document.querySelector('a2ui-surface');
​
const processor = new MessageProcessor([basicCatalog], (action) => {
  console.log('User triggered A2UI action:', action);
});
​
processor.onSurfaceCreated((surface) => {
  surfaceEl.surface = surface;
});
​
processor.processMessages(wireMessages);

Client renderers never see <a2ui> Express, Atom, or Elemental syntax—they only consume standard A2UI v0.9 Wire JSON. When you edit the form fields and click Confirm Booking in the explorer, the <a2ui-surface> component automatically dispatches the confirm action event along with the bound $/reservation data model context:

Wrapping up

Decoupling the LLM inference format from the wire protocol is a great example of optimizing for both sides of an agentic system: A2UI Express gives the LLM a compact, token-efficient DSL to generate UIs up to 4x faster, while compiling down to the exact same validated A2UI JSON that client renderers already speak.

For more details, check out the following resources:

• Blog: Fast, reliable A2UI, with swappable inference formats
• Docs: Swappable Inference Formats
• Spec: A2UI Express Technical Specification
• Sample: A2UI Express & Swappable Inference Formats Explorer
• Presentation: Agent to UI Protocol (A2UI)

Originally published at https://atamel.dev.

A2UI Express and Swappable Inference Formats was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my Agent Protocols — MCP, A2A, A2UI, AG-UI post back in March, I provided a high-level overview of the main agent protocols for tool use (MCP), agent-to-agent communication (A2A), and agent-to-UI interactions (AG-UI and A2UI).

Recently, I had a chance to explore two newer protocols focused on agentic commerce and payments: the Universal Commerce Protocol (UCP) and the Agent Payments Protocol (AP2). Traditional e-commerce and payment flows assume a human is directly browsing a website and clicking “Buy” on a trusted checkout screen. When an AI agent shops and pays on your behalf, both the commerce workflow and the cryptographic proof of user authorization need a standard language.

In this post, I’ll share an update on the agent protocol landscape by introducing UCP and AP2, explaining how they work together, and walking through the new Python and ADK samples I added to my genai-beyond-basics repository.

TLDR

With UCP and AP2 added to the mix, here’s how the six agent protocols in my repository fit together:

• Model Context Protocol (MCP): An open protocol, from Anthropic, that standardizes how models and agents access external tools and resources
• Agent2Agent Protocol (A2A): An open protocol, from Google, that standardizes how agents running on diverse frameworks and platforms communicate
• Agent-User Interaction Protocol (AG-UI): An open protocol, from CopilotKit, that standardizes how agents communicate with user interfaces
• Agent to UI Protocol (A2UI): A generative UI protocol, from Google, that enables AI agents to generate rich, interactive user interfaces across web, mobile, and desktop
• Universal Commerce Protocol (UCP): An open standard, co-developed by Google, Shopify, and industry partners, that standardizes merchant discovery, capability negotiation, and checkout sessions for agentic commerce
• Agent Payments Protocol (AP2): An open protocol, from Google, that secures agent-initiated payments using cryptographically signed mandates and verifiable credentials

Let’s look into UCP and AP2 in more detail.

Universal Commerce Protocol (UCP)

Universal Commerce Protocol (UCP) is an open standard, co-developed by Google, Shopify, and industry partners (including Target, Walmart, Wayfair, Etsy, and Stripe), that defines functional primitives for agentic commerce. It allows AI agents, consumer platforms, businesses (who remain the Merchant of Record), credential providers, and payment service providers to interoperate without bespoke one-off integrations.

Architecture, Discovery, and Capability Negotiation

UCP is structured around four layers:

• Services: Domain groupings such as dev.ucp.shopping, dev.ucp.common, and dev.ucp.lodging.
• Capabilities: Versioned features (“verbs”) within a service, such as dev.ucp.shopping.checkout, dev.ucp.shopping.cart, and dev.ucp.shopping.catalog.search.
• Extensions: Optional schemas that augment a parent capability via extends (e.g., dev.ucp.shopping.fulfillment, dev.ucp.shopping.discount, and dev.ucp.common.payment.ap2_mandate).
• Transports: Transport-agnostic bindings supporting REST (OpenAPI 3.1), MCP (OpenRPC), A2A (Agent Card), and Embedded (OpenRPC).

Every UCP merchant publishes an unauthenticated JSON profile at GET /.well-known/ucp advertising its protocol version, capabilities, payment handlers (com.google.pay, dev.shopify.shop_pay), and JWK signing keys (ES256 as the mandatory baseline, plus optional Ed25519 for Web Bot Auth interop). Permissionless request authentication across HTTP transports uses HTTP Message Signatures (RFC 9421) resolved directly against the public keys in each party's profile. When an agent calls a merchant, UCP uses a server-selects negotiation model:

The merchant computes the intersection between its declared capabilities and the agent’s profile, selects the latest mutually supported YYYY-MM-DD version, and prunes any orphaned extensions whose parent capability isn't active.

Once a checkout session starts, dev.ucp.shopping.checkout progresses through six explicit states so an AI agent always knows whether it can finish the purchase autonomously or must hand off to the user:

• incomplete: Missing required details (such as buyer email or shipping method).
• requires_escalation: Requires direct buyer input via a continue_url handoff (e.g., custom configuration or 3DS challenge).
• ready_for_complete: All line items, totals, and fulfillment details are finalized; ready for payment submission.
• complete_in_progress: Checkout completion is currently executing (new PUT updates are rejected while in progress).
• completed: Payment processed and OrderConfirmation (order.id, order.permalink_url) generated.
• canceled: Checkout session was canceled (POST /checkout-sessions/{id}/cancel) or expired.

ℹ️ Note: All monetary amounts in UCP (and AP2) are expressed in minor currency units (cents) — for example, 2500 for $25.00, and negative integers like -400 for a -$4.00 discount.

UCP Samples: Python SDK & Google ADK

In my UCP samples folder, I created two samples using the official UCP Python SDK (ucp-sdk):

1. UCP Hello World (Python SDK & FastAPI): A self-contained FastAPI merchant server (server.py) and client script (client.py) that validates payloads against BusinessSchema and Checkout models from ucp_sdk. Because client.py mounts server.py in-process via httpx.ASGITransport by default, you can run the entire 4-step UCP lifecycle in a single command:

uv run --with ucp-sdk --with fastapi --with httpx python client.py

=== 1. UCP Discovery (GET /.well-known/ucp) ===
Protocol Version:  2026-08-25
Services:          ['dev.ucp.shopping']
Capabilities:      ['dev.ucp.shopping.checkout', 'dev.ucp.shopping.fulfillment', 'dev.ucp.shopping.discount']
Payment Handlers:  ['com.google.pay', 'dev.shopify.shop_pay']
Signing Key (kid): merchant_key_2026
 
=== 2. Create Checkout Session (POST /checkout-sessions) ===
Checkout ID:       chk_9c35e04f
Checkout Status:   incomplete
Negotiated Caps:   ['dev.ucp.shopping.checkout', 'dev.ucp.shopping.fulfillment', 'dev.ucp.shopping.discount']
  - 1x Red Roses Bouquet (sku_roses): $25.00
  - 1x Ceramic Vase (sku_vase): $15.00
 
=== 3. Update Checkout: Fulfillment & Discount (PUT /checkout-sessions/chk_9c35e04f) ===
Checkout Status:   ready_for_complete
Totals Breakdown:
  - Subtotal                : $40.00
  - 10% Promo (SAVE10)      : -$4.00
  - Shipping (Express Delivery): $5.00
  - Total                   : $41.00
 
=== 4. Complete Checkout (POST /checkout-sessions/chk_9c35e04f/complete) ===
Checkout Status:   completed
Order Created:     Order #ORD_EF9FCC12 (id=ord_ef9fcc12)
Order Permalink:   https://flowershop.example.com/orders/ord_ef9fcc12

2. UCP Shopping Agent with Google ADK: An interactive Agent Development Kit (ADK) agent (shopping_agent/agent.py) equipped with UCP discovery and checkout tools:

root_agent = Agent(
    name="ucp_shopping_agent",
    model="gemini-2.5-flash",
    description="AI Shopping Agent that discovers merchants and completes purchases using the Universal Commerce Protocol (UCP).",
    instruction=...,
    tools=[
        discover_merchant,
        create_checkout_session,
        update_checkout_session,
        complete_checkout_session,
    ],
)

Start server.py in one terminal and adk web in another, and you can ask the agent what the merchant supports and have it negotiate extensions, apply promo codes, and complete an order conversationally.

Agent Payments Protocol (AP2)

While UCP standardizes the commerce session, a big question remains: How does a merchant or payment processor know that an AI agent actually has the user’s permission to spend their money — and didn’t hallucinate the item or price?

That’s where the Agent Payments Protocol (AP2) comes in. Originated by Google, AP2 is an open security and authorization protocol that replaces “trusting the LLM’s text summary” with Verifiable Digital Credentials (VDCs) — specifically tamper-evident SD-JWTs (Selective Disclosure JWTs) and KB-SD-JWT (Key-Binding SD-JWT) delegation chains.

Trust Boundary, Mandates (v0.2), and Delegation Chains

A key rule in the AP2 v0.2 specification is the strict separation between Agentic (LLM-driven) and Non-Agentic (deterministic) roles:

• The Shopping Agent is expected to be agentic.
• The Trusted Surface (where the user approves and signs mandates) MUST be non-agentic.
• Even if a Merchant, Credential Provider, or Payment Processor exposes an agentic interface, all mandate validation and constraint verification MUST execute in deterministic code.

In early AP2 overviews (v0.1), mandates were described conceptually as Intent, Cart, and Payment mandates. In AP2 v0.2 (and the official ap2.sdk Python package), this is formalized into two linked mandate families — Checkout Mandates (securing what is purchased) and Payment Mandates (securing how it is paid) — each with an Open and Closed state, supporting two modes:

1. Human Present (Direct Flow): The user reviews the assembled cart on a Trusted Surface and directly signs the Closed Checkout Mandate (mandate.checkout.1) and Closed Payment Mandate (mandate.payment.1), bound to the merchant-signed UCP checkout_jwt via checkout_hash.
2. Human Not Present (Autonomous Flow): The user pre-authorizes an Open Checkout Mandate (mandate.checkout.open.1) and Open Payment Mandate (mandate.payment.open.1) with deterministic constraints (e.g., allowed merchants, acceptable SKUs, and a maximum budget) and binds the Shopping Agent's public key in the cnf claim. Later, when the condition is met (such as a price drop), the Shopping Agent signs the Closed Mandates with its own private key and chains them onto the user's open mandates (open_sd_jwt~~closed_kb_sd_jwt~):

AP2 supports two trust models for issuing the root Mandate on the Trusted Surface (User Credential Model via OpenID4VP and the browser Digital Credentials API, or Trusted Agent Provider Model signed by the agent provider’s key) and enforces two normative presentation rules on the Shopping Agent: Selective Disclosure Minimization (revealing only the disclosures required to evaluate the Closed Mandate) and Sequential Presentation (preventing concurrent reuse of an Open Mandate across multiple checkouts without a prior rejection receipt).

AP2 Sample: Mandate Delegation & Guardrails in Python

The official google-agentic-commerce/AP2 repository includes full multi-server A2A and MCP scenarios (using Cards or x402 stablecoins), which I documented in my AP2 README.

However, spinning up four separate servers just to see how AP2 mandates work under the hood can be heavy. So I also built a self-contained AP2 Hello World (mandate_demo.py) sample using the official ap2.sdk package that runs an entire Autonomous (Human Not Present) flow in a single script with no API keys required.

Let’s take a quick look at what’s happening under the hood in mandate_demo.py. First, the user (on a Trusted Surface) signs an OpenCheckoutMandate and an OpenPaymentMandate capping the spend at $150.00 (15000 cents), linking to the open checkout mandate hash via PaymentReference, and binding the agent's public key via cnf:

open_checkout_hash = compute_sha256_b64url(open_checkout_token)
 
open_payment_token = client.create(
    payloads=[
        OpenPaymentMandate(
            constraints=[
                AmountRange(currency="USD", min=0, max=15000),
                AllowedPayees(allowed=[merchant]),
                PaymentReference(conditional_transaction_id=open_checkout_hash),
            ],
            cnf={"jwk": agent_pub_dict},
            iat=now,
            exp=now + 3600,
        )
    ],
    issuer_key=user_jwk,
)

When the merchant returns a signed UCP Checkout JWT for $120.00, the Shopping Agent autonomously signs and chains the closed mandates using MandateClient.present(), and the Merchant and Payment Processor deterministically verify the chain (CheckoutMandateChain and PaymentMandateChain):

payment_chain_token = client.present(
    holder_key=agent_jwk,
    mandate_token=open_payment_token,
    payloads=[closed_payment],
    aud="credential-provider",
    nonce="nonce_pay_98765",
)
 
payment_payloads = client.verify(
    token=payment_chain_token,
    key_or_provider=lambda _tok: user_pub_jwk,
    expected_aud="credential-provider",
    expected_nonce="nonce_pay_98765",
)
payment_chain = PaymentMandateChain.parse(payment_payloads)
payment_violations = payment_chain.verify(
    expected_transaction_id=checkout_hash,
    expected_open_checkout_hash=open_checkout_hash,
)

You can run the sample with a single uv command:

uv run --with "ap2 @ git+https://github.com/google-agentic-commerce/AP2.git" python mandate_demo.py

Notice in step 6 how deterministic verification immediately catches and rejects an agent that tries to spend $250.00 against the user's $150.00 open mandate:

=== 1. Generating Keys for User (Trusted Surface), Agent, and Merchant ===
 
=== 2. User Signs Open Mandates on Trusted Surface (SD-JWT) ===
Intent: 'Buy white running shoes (SKU-SHOE-WHITE) from RunFast Store for at most $150.00'
Open Checkout Mandate (SD-JWT): eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0IiwgImtpZCI6I...
Open Payment Mandate  (SD-JWT): eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0IiwgImtpZCI6I...
 
=== 3. Merchant Creates Signed UCP Checkout ($120.00) ===
Merchant Checkout JWT Hash: MBOOU7B8tmrp1fickmNKbaLJ74iQRtvSnO2HQ01ILU0
 
=== 4. Shopping Agent Signs Closed Mandates (KB-SD-JWT Delegation Chain) ===
Agent appended closed KB-SD-JWT hop to both open mandates.
 
=== 5. Deterministic Verification & Receipt Issuance ===
[Merchant] Checkout Mandate Chain verified! Constraints satisfied (0 violations).
[Payment Processor] Payment Mandate Chain verified! Amount $120.00 <= $150.00 max.
[Shopping Agent] Checkout Receipt verified: {'verified': True}
[Shopping Agent] Payment Receipt verified:  {'verified': True}
 
=== 6. Guardrail Demo: Agent Tries to Exceed Budget ($250.00 > $150.00) ===
[Payment Processor] Rejected over-budget payment! Violations: ['Amount 25000 exceeds maximum 15000']

UCP vs. AP2: How They Work Together

Rather than competing, UCP and AP2 are complementary layers in the agentic commerce stack:

• UCP is the commerce layer: It standardizes how agents discover stores (/.well-known/ucp), negotiate capabilities, calculate shipping and discounts, and manage checkout sessions.
• AP2 is the cryptographic trust and payment authorization layer: When UCP’s dev.ucp.common.payment.ap2_mandate extension is negotiated, the session is Security Locked (preventing any downgrade to an unsigned checkout). The merchant signs the canonicalized (RFC 8785 JCS) Checkout payload and embeds a detached JWS at checkout.ap2.merchant_authorization, and on POST /checkout-sessions/{id}/complete, the agent submits cryptographically signed AP2 CheckoutMandate (ap2.checkout_mandate) and PaymentMandate (payment.instruments[*].credential.token) credentials bound to that checkout.

Wrapping up

As AI agents move from answering questions to taking real-world actions like shopping and paying, UCP provides the standardized commerce primitives while AP2 provides the cryptographic guardrails to prove user intent.

Here are some resources to learn more:

• Docs: Universal Commerce Protocol (ucp.dev)
• Docs: Agent Payments Protocol (ap2-protocol.org)
• Docs: UCP and AP2 Integration
• Blog: Under the Hood: Universal Commerce Protocol (UCP)
• Blog: Announcing Agent Payments Protocol (AP2)
• Blog: Developer’s Guide to AI Agent Protocols
• Codelab: Secure Agent Commerce with AP2 and UCP
• Sample: My UCP and AP2 Samples in genai-beyond-basics

Originally published at https://atamel.dev.

Agentic Commerce Protocols — UCP and AP2 was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Back in August, I wrote Where does Antigravity look for Plugins? to explain how plugins bundle skills, rules, subagents, hooks, MCP servers, and sidecars into a single unit. At the time, installing a plugin meant pointing Antigravity to a GitHub repository or a local directory path.

This week, the team launched the Antigravity Plugin Marketplace: a curated catalog of first-party Google plugins and third-party partner plugins built directly into the Antigravity UI and CLI.

Instead of just listing what is in the marketplace, I wanted to share a real workflow that saved me hours this week: using the Google Slides plugin to audit and update my 80+ slide Getting Started with Google Antigravity presentation against the latest documentation.

What is the Antigravity Plugin Marketplace?

The Antigravity Plugin Marketplace makes discovering, installing, and authenticating plugins a one-click experience across both the Antigravity App/IDE and the agy CLI:

• In the Antigravity App / IDE: Open the Agent side panel, click ... at the top right, navigate toCustomizations -> Plugins, and switch to the Marketplace tab.
• In the Antigravity CLI (agy): Run the /plugin slash command and switch to the Discover tab.

Here is what the Marketplace tab looks like under Customizations in the Antigravity UI:

Plugins are organized into curated shelves:

• Google Workspace: Google Docs, Google Sheets, Google Slides, Google Drive, and Google Calendar.
• Build with Google: Gemini API, Chrome DevTools, Android CLI, and Google Cloud Developer.
• Design, Creative & Media: Canva, Figma, and Mobbin.
• Productivity & Project Management: Atlassian Teamwork Graph CLI, Dropbox, and Linear.
• Cloud Hosting & Deployment: Netlify, Railway, and Vercel.
• Developer Tools & Business: Auth0, Base44, Browserbase, Bigin, Databricks, and Intercom.

Better yet, the marketplace handles authentication and configuration in place. For plugins that require an external account-like Google Workspace-you click Sign in directly on the plugin card, complete the OAuth flow in your browser, and Antigravity manages the credentials automatically. You can even connect multiple accounts (for example, work and personal) and switch between them.

Installing the Google Slides Plugin

If you give technical talks about fast-moving AI tools, you know the pain of keeping slide decks up to date. Antigravity ships multiple releases every week, which means screenshots, model names, CLI flags, and feature lists in my Getting Started with Google Antigravity deck start drifting out of date almost immediately.

Previously, auditing a Google Slides presentation meant exporting a PDF or copying slide text manually, asking an LLM what was outdated, and then manually clicking through 80+ slides in the browser to apply the fixes.

With the Google Slides plugin from the Google Workspace shelf, Antigravity gets:

1. A dedicated gslides skill that teaches the agent how to read, design, and mutate presentations safely.
2. A sandboxed gslides CLI separated into gslides readonly (for reading slides, inspecting page elements, and exporting PNG thumbnails) andgslides mutate (for updating text, inserting slides, and replacing images).
3. Managed Google OAuth authentication so it can access your presentation directly via its Google Slides URL.

After installing the Google Slides plugin (and the Google Drive plugin) from the marketplace and signing in with my Google account, I was ready to put it to the test.

Auditing My Antigravity Slides Against the Docs

I pasted the Google Slides link to my presentation into Antigravity and gave it a simple prompt:

Can you check my Getting Started with Google Antigravity slides
(https://docs.google.com/presentation/d/<presentation-id>/edit)
against the latest Antigravity documentation and let me know if
there are any errors, outdated slides, or missing new features?

Antigravity used gslides readonly read to inspect all 81 slides in my deck, cross-referenced every slide against its built-in documentation skills ( antigravity-guide and agy-customizations), and came back with a structured audit report broken down into three categories:

1. Wrong, outdated, or inconsistent slides
2. Missing major features introduced in recent releases
3. Outdated screenshots and sketchnote diagrams

Once I reviewed the report and gave the green light, Antigravity updated the live presentation directly. Here is what it caught and fixed.

First, Antigravity used gslides mutate replace-text and gslides mutate batch to fix factual drift and typos across existing slides without disturbing the slide formatting.

For example, it updated my permission presets slide to include all four current presets ( Request Review, Default, Auto (Preview), and Turbo), refreshed the IDE and subagent lists ( Eclipse support and the image-generator subagent), and updated the Skills and Rules slides with the references/ directory and all four rule trigger types ( always-on, glob, manual, and model-triggered). It even caught a doubled-quote Python syntax typo in an SDK code snippet and noticed that speaker notes on one slide had been accidentally copy-pasted from an earlier slide.

2. Adding Missing Features as New Slides

Next, Antigravity pointed out six major capabilities that had shipped since I first created the deck: Context & Attachments (@ mentions, diff line quoting, and multimedia attachments), Slash Commands (/plan, /grill-me,/goal, /boost, /teamwork, /btw), Teamwork (peer-to-peer subagent teams), Generative UI (inline interactive HTML/JS widgets), the Plugin Marketplace, and Enterprise Identity (BYO GCP project and SSO/WIF).

When I asked it to add slides for them, it inspected the exact typography ( Poppins headings, Roboto body, Roboto Mono code blocks, and #1976D2 accents) of my existing deck, inserted six new slides in the right sections, and ran gslides readonly export-thumbnail to visually verify every new slide for text overflow or alignment issues.

Here is the new Plugin Marketplace slide that Antigravity inserted into the presentation:

The most impressive part of the workflow happened when we got to the image-only slides. During its initial audit, Antigravity noticed that even on slides with no editable text boxes, the embedded screenshots and hand-drawn sketchnotes had outdated details.

I asked:

I like the updates, can you also update the images in the image-only
slides with the suggestions you had?

Antigravity extracted the images from those slides, spawned image-generator subagents in parallel to surgically edit each image while preserving its exact visual style, uploaded the updated images to Google Drive, and swapped them into the presentation.

Across those image-only slides, the subagents updated the dark-mode model selector screenshots to show Gemini 4 Argon Medium, refreshed the permission format table screenshot, updated my Hooks sketchnote diagram from "5 Critical Event Triggers" to "6 Critical Event Triggers" (adding Session Start to the flow), and updated my Plugins sketchnote diagram so Sidecars are included inside the AGY PLUGIN bundle instead of crossed out.

Here is the updated Hooks slide showing all 6 event triggers in the original hand-drawn sketchnote style:

And here is the updated Plugins slide with Sidecars added into the plugin bundle diagram:

Wrapping up

What used to be a tedious multi-hour chore of cross-checking release notes and manually editing slides turned into a single conversation. Having first-party Google Workspace plugins available directly in the Antigravity Plugin Marketplace-combined with documentation skills and image-generator subagents-makes it effortless to connect Antigravity to the docs, spreadsheets, and presentations where your day-to-day work actually lives.

To learn more, check out these resources:

• Blog: Plugin Marketplace in Antigravity
• Docs: Antigravity Plugins
• Presentation: Getting Started with Google Antigravity

Originally published at https://atamel.dev.

Antigravity Plugin Marketplace in Action: Auditing My Talk Slides with the Google Slides Plugin was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my Agent Protocols — MCP, A2A, A2UI, AG-UI post, I provided a high-level overview of the main agent protocols, including the Agent2Agent (A2A) Protocol. When building an A2A server, you need an easy way to test that its agent card is published properly and that it responds to messages as expected.

Traditionally, you either had to write a custom client script using the A2A SDK or clone and run the web-based A2A Inspector. Recently, the A2A project released the official A2A CLI ( a2a) tool, which makes testing A2A agents as simple as running a single terminal command. Even better, it includes a built-in server mode to spin up test agents or wrap existing scripts as A2A servers.

In this post, I’ll introduce A2A CLI and show how to use it with the updated A2A v1.0 samples in my genai-beyond-basics repository.

What is A2A CLI?

A2A CLI ( a2a) is the official command-line client and server tool for the A2A protocol (built on the A2A v1.0 specification):

• Terminal Client (a2a card get, a2a send, a2a task): Discover agent cards, send messages, stream real-time task updates (--stream), and output JSON/JSONL (-o json, -o jsonl) for shell pipelines.
• Built-in Server (a2a server): Spin up a zero-code echo agent (--echo), wrap any script or executable into an A2A agent (--exec), or run a debugging proxy in front of an upstream agent (--proxy).
• AI Coding Assistant Skill (a2a skill): Outputs a bundled SKILL.md that teaches AI coding assistants (like Antigravity, Gemini CLI, or Claude Code) how to discover and delegate tasks to remote A2A agents.

On macOS or Linux, you can install it via Homebrew:

brew tap a2aproject/a2a-cli https://github.com/a2aproject/a2a-cli brew install a2a

Or install it from source using Go:

go install github.com/a2aproject/a2a-cli@latest
mv "$(command -v a2a-cli)" "$(dirname "$(command -v a2a-cli)")/a2a"

Testing Existing A2A Agents with A2A CLI

Let’s first see how A2A CLI simplifies testing the existing A2A servers in my repository (which I also recently updated to the latest A2A v1.0 SDKs).

Echo Agent (Python & C#)

In my echo-agent sample, I have a barebones Echo Agent implemented in both Python ( a2a-sdk) and C# ( A2A .NET SDK) running on port 5209.

Start the Python Echo Agent server:

python __main__.py

Or start the C# Echo Agent server:

cd A2AAgent
dotnet run

Previously, you had to run a2a_client.py (or the C# A2AClient project) or spin up A2A Inspector in the browser just to verify the server. With A2A CLI, you can inspect the agent card directly from your terminal:

a2a card get http://localhost:5209

You should see the agent’s metadata, supported interfaces, and skills:

Name:         Echo Agent
Description:  An agent that will echo every message it receives.
Version:      1.0.0
Interfaces:
  JSONRPC      http://localhost:5209
Streaming:    true
Skills:
  echo                 Echo tool

Next, send a message to the agent:

a2a send -a http://localhost:5209 "Hello from the A2A CLI"

[agent] Echo: Hello from the A2A CLI

ADK Currency Agent

You can also use A2A CLI to test Agent Development Kit (ADK) agents exposed over A2A. In my adk/currency sample, a currency_agent uses a tool ( convert_currency) to fetch live exchange rates from the Frankfurter API and exposes itself as an A2A server via ADK's to_a2a() utility:

root_agent = Agent(
    name="currency_agent",
    model="gemini-3.5-flash",
    description="Agent to convert from one currency to another.",
    instruction=instruction_prompt,
    tools=[convert_currency],
)

# Expose the agent over A2A protocol locally
a2a_app = to_a2a(root_agent, host="localhost", port=int(os.getenv("PORT", "8080")))

Start the ADK A2A server locally:

uvicorn agent:a2a_app --host localhost --port 8080

Instead of needing a second ADK agent (like travel_helper) just to test currency_agent, you can query its agent card and send a conversion request straight from the CLI:

a2a card get http://localhost:8080

Name:         currency_agent
Description:  Agent to convert from one currency to another.
Version:      0.0.1
Interfaces:
  JSONRPC      http://localhost:8080
Streaming:    true
Skills:
  currency_agent       model
  currency_agent-convert_currency convert_currency

Send a currency conversion prompt:

a2a send -a http://localhost:8080 "How much is 1 GBP in EUR?"

Notice how A2A CLI displays the full A2A task lifecycle, including the resulting artifact and the tool call history:

Task:     598a1dce-f628-45cc-bbe0-305a639ffc02
Context:  8e770de5-beb6-4a48-8c43-9e0736b696bf
Status:   completed (2026-10-19T15:29:30Z)
Artifacts:
  [93ef7de9-fb90-4b19-a4e3-aadc07c057ab] 1 British Pounds (GBP) = 1.1876 Euros (EUR)
History:
  [user] How much is 1 GBP in EUR?
  [agent] {"args":{"from_currency":"GBP","to_currency":"EUR"},"id":"call_2821308","name":"convert_currency"}
  [agent] {"id":"call_2821308","name":"convert_currency","response":{"result":1.1876}}
  [agent] 1 British Pounds (GBP) = 1.1876 Euros (EUR)

Beyond Testing: a2a server Mode

While A2A CLI is great as a client, its a2a server command is equally useful for testing and prototyping. You can find all of these examples in the new a2a-cli folder in my repo.

1. Zero-Code Echo Server (--echo)

If you are building an A2A client and just need a quick A2A endpoint to test against, you don’t need to write any Python or C# code at all. Run a2a server --echo:

a2a server --echo --port 8080 --name "Echo Agent" --description "An agent that echoes messages back."

Then test it with a2a send:

a2a send -a http://localhost:8080 "Hello from A2A CLI"

2. Turn Any Script into an A2A Agent (--exec)

With --exec, a2a server wraps any command or script as an A2A-compliant agent. Incoming message text is piped to stdin, and stdout becomes the response artifact.

For example, here’s a plain Python script (word_processor.py) that knows nothing about A2A:

import sys
import time

def main():
    text = sys.stdin.read().strip()
    words = text.split()
    for i, word in enumerate(words, 1):
        print(f"[{i}/{len(words)}] {word.upper()}", flush=True)
        time.sleep(0.3)

if __name__ == "__main__":
    main()

Expose it as a streaming A2A server by passing --exec and splitting chunks on newlines with --chunk=$'\n':

a2a server --exec "python3 -u word_processor.py" \
  --chunk=$'\n' \
  --port 8080 \
  --name "Word Processor Agent" \
  --description "Streams words in uppercase."

Now call it with --stream to watch the ArtifactUpdateEvent chunks arrive in real time:

a2a send -a http://localhost:8080 --stream "hello agent world"

Task:     01a154c9-bf34-7bb0-b949-f632a913ca5e
Context:  01a154c9-bf34-7cb2-b457-904e4dd2ed6e
Status:   submitted
History:
  [user] hello agent world
[status] working
[artifact] [1/3] HELLO
[artifact+] [2/3] AGENT
[artifact+] [3/3] WORLD
[status] completed

3. Debugging Traffic with Proxy Mode (--proxy)

Finally, if you want to inspect traffic between two A2A agents or inject headers, you can put a2a server --proxy in front of any upstream A2A server:

a2a server --proxy -a http://localhost:8080 --port 9090

Any requests sent to http://localhost:9090 will be logged to the terminal and forwarded to the upstream agent on port 8080.

Wrapping up

A2A CLI is a must-have utility in your belt if you’re working with the A2A protocol — whether you’re quickly sanity-checking an agent card, debugging task streams in the terminal, or wrapping a local script into an A2A server.

For more details, check out the following resources:

• Docs: A2A CLI Command Reference
• Sample: A2A Samples (Python, C#, ADK, and A2A CLI)
• Presentation: Agent2Agent (A2A) Protocol

Originally published at https://atamel.dev.

Testing and Serving A2A Agents from the Terminal with A2A CLI was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Coming to work every morning often means facing a wall of unread Google Chat messages from the night before across colleagues in different time zones. Skimming through every space and thread to catch up takes time.

To make my mornings easier, I built an automated Unread Messages Brief directly inside Google Chat-powered by Google Workspace Studio, Gemini, and a Google Apps Script Custom Step (with zero Google Cloud Console setup required). Everything was built with the help of Gemini 4 and Antigravity, which made figuring out the Google Chat read-state API nuances and wiring up the Workspace Studio custom step effortless.

In this post, I’ll share how it works, the design decisions behind it, and how you can set it up for yourself using my google-chat-unread-brief repository.

Why not just use Google Chat’s “Ask Gemini” tab?

At this point, you might be wondering: Can’t you just use the built-in “Ask Gemini” tab in Google Chat?

I had the same question and gave it a try, but ran into two main limitations:

1. Too much noise from background threads: When you ask the built-in Ask Gemini tab to summarize your unread messages, it includes all unread messages across every background thread-even threads you aren’t following. I wanted a brief that filters strictly fortop-level unread messages andmessages from threads I actively follow.
2. No scheduled summaries: There is no way to schedule an automatic daily summary in theAsk Gemini tab so that it’s waiting for you when you start your day.

What does Unread Messages Brief do?

With Google Workspace Studio and a small Google Apps Script custom step, the workflow gives you:

• Daily 7:45 AM Scheduled Brief: Automatically summarizes your unread messages from the last 24 hours (top-level messages and threads you follow,without marking them as read) and posts a clean bulleted brief with clickable space links into your privateUnread Messages Brief space each weekday morning.
• On-Demand Trigger (/briefnow): Type /briefnow in yourUnread Messages Brief space anytime during the day to generate a fresh summary on demand.

Let’s look at how to set it up step by step.

Step 1: Create your private space in Google Chat

First, create a dedicated space in Google Chat where your briefs will be posted:

1. Open Google Chat.
2. Name the space Unread Messages Brief (keep it private with just yourself).

Step 2: Set up & install the Apps Script Custom Step

While Google Workspace Studio has built-in steps for Google Chat and Gemini, we need a custom step in Google Apps Script to query the Google Chat API’s read state ( getSpaceReadState and getThreadReadState) and fetch only the unread top-level messages and followed threads without marking them as read.

ℹ️ Note

Why isn’t there a “Mark all unread messages as read” command? While reading unread state ( spaces.list, messages.list, getSpaceReadState, getThreadReadState) works out of the box with Apps Script's default project, the Google Chat API blocks write calls ( updateSpaceReadState) unless you create, link, and configure a standard Google Cloud project in the Cloud Console. Keeping it read-only avoids any Google Cloud project setup.

Here’s how to set up and install the custom step:

1. Go to script.google.com and click New project (name it Unread Messages Brief).

2. Enable the manifest file:

• Click Project Settings (⚙️ icon on the left sidebar).
• Check the box “Show ‘appsscript.json’ manifest file in editor”.

3. Copy the files from my google-chat-unread-brief repository into the editor:

• Click Editor (< > icon on the left sidebar).
• Open appsscript.json and replace its contents withappsscript.json.
• Open Code.gs and replace its contents with .
• Click Save (💾).

4. Authorize the Script in Apps Script:

• In the top toolbar dropdown (next to Run / Debug), selectonExecuteFetchUnread and click Run.
• Approve the Google OAuth permissions prompt when asked.

5. Install Test Deployment for Workspace Studio:

• Click Deploy (top right) → Test deployments.
• Next to Application(s): Google Workspace Add-on, click Install.
• Click Done.

Let’s take a quick look at what’s happening under the hood in both files.

First, appsscript.json declares the Google Chat Advanced Service ( Chat v1), read-only OAuth scopes, and exposes a custom workflow action ( Fetch Unread Chat Messages) to Google Workspace Studio with two inputs ( excludeSpaceName and maxLookbackHours) and one output ( unreadMessagesText):

"flows": {
  "workflowElements": [
    {
      "id": "fetch_unread_chat_messages",
      "state": "ACTIVE",
      "name": "Fetch Unread Chat Messages",
      "description": "Fetches unread Google Chat messages across your spaces with space links, without marking them as read.",
      "workflowAction": {
        "inputs": [
          {
            "id": "excludeSpaceName",
            "description": "Name or Space ID of your Unread Messages Brief space to exclude from the summary (optional)",
            "cardinality": "SINGLE",
            "dataType": { "basicType": "STRING" }
          },
          {
            "id": "maxLookbackHours",
            "description": "Maximum hours to look back for unread messages (e.g. 24)",
            "cardinality": "SINGLE",
            "dataType": { "basicType": "INTEGER" }
          }
        ],
        "outputs": [
          {
            "id": "unreadMessagesText",
            "description": "Formatted unread messages and space links ready for Gemini summarization",
            "cardinality": "SINGLE",
            "dataType": { "basicType": "STRING" }
          }
        ],
        "onConfigFunction": "onConfigFetchUnread",
        "onExecuteFunction": "onExecuteFetchUnread"
      }
    }
  ]
}

Second, Code.gs implements the configuration UI ( onConfigFetchUnread), the execution handler ( onExecuteFetchUnread), and the core fetchUnreadChatData function. For each active space within the lookback window, it checks your space-level lastReadTime and then inspects each thread's lastReadTime so that only unread top-level messages and replies in threads you follow are included:

// Get the user's space-level read state
const readState = Chat.Users.Spaces.getSpaceReadState(
  `users/me/${space.name}/spaceReadState`
);
const spaceLastReadMs = new Date(readState.lastReadTime).getTime();
const lastActiveMs = new Date(space.lastActiveTime).getTime();

// Skip if the space is already read
if (lastActiveMs <= spaceLastReadMs) continue;

// Fetch candidate messages newer than spaceLastReadTime (within lookback window)
const msgResponse = Chat.Spaces.Messages.list(space.name, {
  filter: `createTime > "${effectiveSinceIso}"`,
  pageSize: 40
});

// Filter to ONLY top-level messages + replies in new or followed threads
for (const m of candidateMessages) {
  const trs = Chat.Users.Spaces.Threads.getThreadReadState(
    `users/me/${m.thread.name}/threadReadState`
  );
  const threadLastReadMs = (trs && trs.lastReadTime)
    ? new Date(trs.lastReadTime).getTime()
    : null;

  const isTopLevel = !m.threadReply;
  const isReplyToNewUnreadThread = newTopLevelThreads.has(m.thread.name);
  const isFollowedThread = threadLastReadMs !== null && threadLastReadMs > spaceLastReadMs;

  if (isTopLevel || isReplyToNewUnreadThread || isFollowedThread) {
    // Format sender, message text, and space link for Gemini
  }
}

Finally, onExecuteFetchUnread packages the formatted messages and space links into the unreadMessagesText output variable using AddOnsResponseService so the next step in the flow can pass it directly to Gemini.

Step 3: Build the on-demand flow in Google Workspace Studio

Next, open Google Workspace Studio (refresh the page if it was already open so your newly installed Unread Messages Brief custom step appears).

💡 Tip

Google Workspace Studio displays each output variable using its description from appsscript.json (for example, unreadMessagesText appears in the picker underFetch Unread Chat Messages →Formatted unread messages and space links ready...).

Create a new flow named Unread Messages Brief with the following steps:

1. Starter (Chat → When I get a chat message):

• Conversation type: Choose Spaces & named group DMs.
• Spaces: Select Unread Messages Brief.
• Enter /briefnow in the "Message has" field and choose "Match text exactly".

2. Step 2 (Chat → Post in a space - Progress Indicator):

3. Step 3 (Custom Step → Fetch Unread Chat Messages):

• Click + Add step → scroll to Unread Messages Brief → select Fetch Unread Chat Messages.
• Set Exclude Space Name or ID to Unread Messages Brief.
• Set Max Lookback Window (Hours) to 24.

4. Step 4 (Ask Gemini - Summarize):

• Add an Ask Gemini step with the following prompt:

Provide a high-level summary of my unread Google Chat messages below, formatted as a bulleted list grouped by Space.
- If the input says NO_UNREAD_MESSAGES, just reply: "🎉 You're all caught up! No unread Google Chat messages."
- Format each Space as a bullet point starting with the Space name in bold (* **Space Name**:) followed by an overall summary whose length is proportional to the discussion (keep it brief for 1–2 messages, and more detailed for longer discussions).
- Focus on the topic and outcome rather than listing who said what. Only mention a person's name (in bold, e.g. **Aaron**) when attribution is genuinely useful—such as a specific announcement, question, or action item—and omit names entirely for general group discussions or quick updates.
- At the end of each Space's bullet item, include a clickable chat icon linked to its exact Link from the input: [💬](https://chat.google.com/room/...).
- Do not add any concluding remarks or trailing blank lines after the last bullet item.

Unread Messages Data:

• On the last line under Unread Messages Data:, click and selectStep 3: Fetch Unread Chat Messages → Formatted unread messages and space links ready....

5. Step 5 (Chat → Post in a space):

6. Click Turn on.

Here’s what the complete on-demand flow looks like:

Step 4: Test the flow & schedule the daily 7:45 AM brief

To test the flow, mark any conversation in Google Chat as unread, head over to your Unread Messages Brief space, and send /briefnow.

Within seconds, you’ll see the progress indicator followed by your ☕ Unread Messages Brief with bold space names, high-level topic summaries, and a clickable 💬 link at the end of each item that jumps straight to that space-while all your unread badges in the sidebar remain intact:

Once your /briefnow flow is working, you can easily create the daily morning schedule by making a copy of the flow (since Google Workspace Studio only allows one Starter per flow):

1. In your My flows list, click next to Unread Messages Brief and select Make a copy.
2. Rename it to Unread Messages Brief - Scheduled.
3. Change the Starter at the top to Schedule → Every weekday at 7:45 AM (and delete the ⏳ progress step in Step 2 so it only posts the finished brief), then clickTurn on.

Wrapping up

In this post, we built an automated Unread Messages Brief for Google Chat that delivers both a scheduled morning summary and an on-demand/briefnow summary without marking your messages as read.

For the full code and step-by-step instructions, check out the repository on GitHub:

• Sample: google-chat-unread-brief

Originally published at https://atamel.dev.

Google Chat Unread Messages Brief with Workspace Studio and Gemini was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Beyond coding projects, I use Antigravity (AGY) all the time for personal tasks and random day-to-day questions-like trip planning, tax research, quick scripts, or brainstorming. Rather than creating a separate project folder for every little topic, I keep a single project called llm-conversations for all my miscellaneous chats and tasks.

However, using a single project for unrelated conversations comes with an annoying problem: context bleed and clutter. By default, every conversation shares the same root folder, so the agent sees files from unrelated chats, litters the root directory with random markdown files and scripts, and leaves behind orphaned files even after you delete a conversation in the UI.

To solve this, I combined Antigravity Rules and Hooks to build a multi-conversation workspace template where every chat gets its own isolated subfolder that stays automatically synced with the Antigravity UI. In this post, I’ll walk through how it works and how you can set it up using my llm-conversations-template repository.

What does the Multi-Conversation Workspace do?

With a workspace rule and a lightweight PreInvocation hook, this setup gives you:

• 1 Conversation = 1 Subfolder: Every new chat automatically works insideconversations/<chat-title>/ (for example, conversations/cyprus-trip/ orconversations/tax-planning/).
• Zero Context Bleed: The agent is scoped strictly to the active conversation’s subfolder for reading, searching, editing, and running commands. The project root stays clean withREADME.md as the only root file.
• UI-Synced Lifecycle: Rename or delete a chat in the Antigravity sidebar and its subfolder is automatically renamed or cleaned up on disk on the next turn.
• Chat Announcements & On-Demand Git Sync: Whenever a subfolder is created, renamed, or deleted, the agent announces it at the top of its response, and changes are only committed/pushed to GitHub when you explicitly ask.

Let’s look at how all the pieces fit together.

Repository Structure

Here is the structure of the workspace in llm-conversations-template:

llm-conversations/
├── .agents/
│   ├── hooks.json                          # Configures the PreInvocation hook
│   ├── rules/
│   │   └── conversation-isolation.md       # Workspace isolation & Git sync rules for the agent
│   └── scripts/
│       └── cleanup-conversations.py        # Syncs folder renames & deletes orphaned folders
├── .conversations.json                     # Local Conversation ID -> subfolder map (git-ignored)
├── .gitignore
├── README.md                               # Project documentation (only file in root)
└── conversations/
└── <conversation-subfolder>/           # Isolated directory per conversation

There are two main components driving this workflow under .agents/: an always_on Workspace Rule and a PreInvocation Hook.

Step 1: Per-conversation isolation with a Workspace Rule

First, .agents/rules/conversation-isolation.md defines an always_on rule that instructs the agent how to manage subfolders and stay isolated inside the current conversation's directory.

Every Antigravity conversation has a unique Conversation ID injected into the agent's context (under<user_information>). The rule instructs the agent to maintain a local mapping between each Conversation ID and its assigned kebab-case subfolder in .conversations.json at the workspace root:

{
  "32392475-06f0-4146-835d-66100755ec3e": "cyprus-trip",
  "903266d9-0539-412e-baad-97f5b1a3c744": "tax-planning"
}

ℹ️ Note

.conversations.json is added to .gitignore because conversation IDs are specific to your local Antigravity installation, even if you back up your conversations/ folder to a private GitHub repository.

Here is the core isolation logic from .agents/rules/conversation-isolation.md:

---
trigger: always_on
description: Per-conversation subfolder isolation and on-demand GitHub sync rules for this workspace.
---

# Per-Conversation Subfolder Isolation Rules

This workspace hosts multiple independent conversations on different topics.
Every conversation MUST stay isolated within its own subfolder inside
`<workspace-root>/conversations/`.

## 1. Subfolder Creation & Naming
- Each conversation has a unique `Conversation ID` (provided in `<user_information>`).
- Maintain a mapping between `Conversation ID` and its subfolder name in
  `.conversations.json` at the workspace root (format: `{"<conversation-id>": "<subfolder-name>"}`).
- When a conversation begins:
  1. Check `.conversations.json` in the workspace root to see if the current
     `Conversation ID` already has an assigned subfolder.
  2. If not, use the suggested subfolder name from the `PreInvocation` hook
     message (if provided), or derive a concise, descriptive `kebab-case`
     subfolder name that matches the conversation topic/name (e.g.,
     `cyprus-trip`, `tax-planning`), create
     `<workspace-root>/conversations/<subfolder-name>`, and record
     `<subfolder-name>` in `.conversations.json`.

## 2. Strict Read/Write Isolation
- **Read Scope**: ONLY read, search (`grep_search`, `find_by_name`), or inspect
  files inside the current conversation's assigned subfolder
  `<workspace-root>/conversations/<subfolder-name>/` (plus `.conversations.json`
  at the workspace root for setup). Do NOT read files in the workspace root or
  in other conversation subfolders unless the user explicitly instructs you to
  access a specific path outside your subfolder.
- **Write & Command Scope**: Create, edit, and save all files inside
  `<workspace-root>/conversations/<subfolder-name>/`, and run shell commands
  with `<workspace-root>/conversations/<subfolder-name>` as the working
  directory (`Cwd`) whenever possible.

The rule also enforces two quality-of-life behaviors:

Visible Folder Announcements: Whenever a conversation subfolder is created, renamed, or deleted, the agent announces it right at the top of its response so you always know what happened on disk:

• 📁 Folder created: conversations/<subfolder-name>/
• 📁 Folder renamed: conversations/<old-name>/ → conversations/<new-name>/
• 🗑️ Folder deleted: conversations/<subfolder-name>/ (conversation deleted)

On-Demand GitHub Sync: The agent never commits or pushes automatically. Whenever you reach a milestone or want to back up your conversations, you can simply say”sync” or “push changes” in chat.

Step 2: Automatic UI syncing with a PreInvocation Hook

A workspace rule alone can isolate new conversations, but what happens when you rename a conversation in the Antigravity sidebar, or delete an old conversation from the UI? The agent inside an active chat doesn’t automatically know what you renamed or deleted in the sidebar unless something checks the Antigravity state on disk.

That’s where .agents/hooks.json comes in. It registers a PreInvocation hook that runs.agents/scripts/cleanup-conversations.py automatically before each agent turn:

At a high level, cleanup-conversations.py keeps the workspace folders in sync with the Antigravity UI in three ways:

• Creating Subfolders: For a new conversation, the hook reads the current conversation title from Antigravity’s local SQLite database (conversation_summaries.db) and suggests a matchingconversations/<kebab-case-name> folder to the agent.
• Renaming Subfolders: If you rename a conversation in the Antigravity sidebar, the hook detects the title change on the next turn, renamesconversations/<old-name>/ → conversations/<new-name>/ on disk, updates.conversations.json, and instructs the agent to announce the rename in chat.
• Deleting Orphaned Subfolders: If you delete a conversation in the Antigravity UI, its directory in~/.gemini/antigravity/brain/<conversation-id> is removed. On the next turn of any conversation, the hook notices that the brain directory no longer exists, deletes the orphanedconversations/<subfolder-name>/ directory from the workspace, cleans up.conversations.json, and instructs the agent to announce the deletion in chat.

Using the template for your own conversations

To set up your own multi-conversation workspace:

1. Create a new private repository on GitHub from thellm-conversations-template template (or clone it and pointorigin to your own private repository).
2. Remove conversations/ from .gitignore in your private repository if you want your conversation folders to be backed up when you ask the agent to sync (it is git-ignored by default in the public template so test conversations aren't committed accidentally).
3. Open the repository folder in Antigravity and start a conversation-your first topic folder will be created automatically under conversations/ and announced at the top of the agent's reply.

Wrapping up

Combining a workspace rule with a PreInvocation hook turns a single Antigravity project into a clean, self-maintaining workspace for all your day-to-day conversations-without context bleed or leftover folder clutter.

For the full configuration and script, check out the template repository on GitHub: llm-conversations-template

Originally published at https://atamel.dev.

Setting Up an Antigravity Workspace for Multiple Conversations was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

By the end of that series, we had decomposed our legacy Windows/.NET Framework monolith into a clean serverless microservices architecture on Google Cloud Run with a C#/.NET Core backend ( Amathus.Reader, Amathus.Converter, and Amathus.Web connected via Cloud Scheduler, Cloud Storage, Pub/Sub, and Firestore) and a cross-platform Flutter mobile frontend ( AmathusClient):

And then, as often happens with side projects, life got busy. After a final commit on November 21, 2020, the repo sat untouched for nearly 6 years.

Recently, I wanted to see how Gemini 4 (running in Antigravity with the google-cloud-developer plugin) would handle bringing this 6-year-old project back to life.

Not only did Gemini 4 upgrade the entire backend and frontend and deploy everything to Google Cloud with a single prompt, it also helped me transform the app with a flurry of new features in just a few hours.

Here is the story of how it went.

Assessing 6 years of tech debt

Before touching any code, I pointed Gemini 4 at the repository and asked it to assess how outdated the stack was.

Prompt:

Here's an app I built a while back with a microservices architecture on the 
backend and a Flutter frontend. Take a look and let me know the versions of 
C#/.NET and Flutter used and how outdated they are.Gemini came back with 
a breakdown of what 6 years in software looks like.

Gemini came back with a breakdown of what 6 years in software looks like.

Gemini’s response:

### 1. Backend: C# / .NET (Amathus)
• Framework Version: .NET Core 3.1 (netcoreapp3.1)
• Configured across all 5 projects: Amathus.Common.csproj, Amathus.Web.csproj,
Amathus.Reader.csproj, Amathus.Converter.csproj, and Amathus.FuncTests.csproj.
• Docker images use mcr.microsoft.com/dotnet/core/sdk:3.1-alpine and
mcr.microsoft.com/dotnet/core/aspnet:3.1.
• C# Language Version: C# 8.0 (the default for netcoreapp3.1, using the older
Program.Main + Startup.cs hosting model in Program.CreateHostBuilder).

#### How outdated is it?
• ~7 major versions behind: .NET Core 3.1 was released in December 2019 and reached
End of Life (EOL) in December 2022 (nearly 4 years ago).
• Current version: .NET 10.0 (LTS) with C# 14 (you currently have .NET 10.0.301,
.NET 9.0.202, and .NET 8.0.403 installed locally).
• Key ecosystem gaps:
• The Docker base image repositories (mcr.microsoft.com/dotnet/core/...) were
deprecated and moved to mcr.microsoft.com/dotnet/sdk and
mcr.microsoft.com/dotnet/aspnet starting in .NET 5.0.
• Key NuGet dependencies in Amathus.Common.csproj are from 2019–2020
(Google.Cloud.Firestore 1.1.0 vs 3.x+, Google.Cloud.Storage.V1 2.5.0 vs 4.x+,
Newtonsoft.Json 12.0.3 vs 13.x or built-in System.Text.Json).

### 2. Frontend: Flutter & Dart (AmathusClient)
• Dart SDK Constraint: >=2.7.0 <3.0.0 in pubspec.yaml
• Flutter Version Era: Flutter 1.20 – 1.22 (late 2020, pre-Flutter 2.0)

#### How outdated is it?
• ~6 years / 2 major versions behind: Dart 2.7–2.10 and Flutter 1.x date back to
2020, before Dart Sound Null Safety (introduced in Dart 2.12 / Flutter 2.0 in
March 2021) and Dart 3 (May 2023).
• Current version: Flutter 3.47.6 and Dart 3.13.5 (installed on your machine).
• Major breaking changes between then and now:
1. No Null Safety: Because the SDK constraint in pubspec.yaml has an upper bound
of <3.0.0, Dart 3+ refuses to compile the code without migrating to sound null
safety (>=3.0.0).
2. Removed Flutter Theme & Widget APIs:
• ThemeData(accentColor: Colors.amber) (removed in Flutter 3.1; replaced by ColorScheme).
• FlatButton (removed in Flutter 3.0; replaced by TextButton).
3. Discontinued / Legacy Packages in pubspec.yaml:
• admob_flutter: ^1.0.1 — discontinued in favor of google_mobile_ads.
• share: ^0.6.5+4 — discontinued in favor of share_plus.
4. Android Build Tooling:
• build.gradle uses Kotlin 1.3.50, Android Gradle Plugin 3.5.0, and the
shut-down jcenter() repository.

Normally, bridging a 6-year gap across both .NET and Flutter versions, fixing broken RSS feeds and redeploying a multi-service cloud architecture is a multi-weekend project. But this time was different.

From staged approvals to Turbo mode

My initial goal was simple: upgrade all the backend microservices and the Flutter frontend to the latest versions, get them running locally, and deploy them to Google Cloud.

At first, I took the cautious route. I asked Gemini to come up with a staged plan and let me approve and test each stage as the services were upgraded.

However, within 10 minutes, I realized that I was simply rubber-stamping and approving everything Gemini proposed anyway. So I quit the session, started over in Turbo mode in Antigravity and gave Gemini 4 a single prompt to do the entire job autonomously.

Prompt:

Please make a plan to upgrade both the backend and the frontend to the latest versions.
Save the plan for me to take a look but don't wait for my approval.

Follow this process during your upgrade:

- Upgrade the .NET backend to the latest, make sure it runs locally.
- During the upgrade, make sure the news feeds are still active. If some of the
news sources do not work, try to find the new links and if you can't, just
remove the obsolete news sources.
- Deploy the .NET backend to Google Cloud project. Use events-atamel as my main
project for this. Test all microservices and update scripts to deploy/test these
services.
- Upgrade the Flutter frontend with the latest, make sure it runs locally.
- Deploy a Flutter web frontend for it so I can test the UI afterwards.
- Make sure all READMEs and scripts for local testing and also cloud deployment
are also updated.
- Once the upgrade is done, do a review of the UI, make sure all the icons and
text displays properly, images are properly sized and doesn't take too much space.
Try to make it look pretty.
- Make all the changes locally without checking into Git. Once finished, I'll do
the checkin myself once I'm happy with the changes.
- Try to be as autonomous as possible unless you really need my feedback

What Gemini 4 did on its own

Once I hit enter, Gemini 4 went to work. It pulled in the gcloud and cloud-run-basics skills from the google-cloud-developer plugin, created a 5-phase implementation_plan.md and a task.md checklist to track its own progress, and worked through the entire modernization end-to-end without a single intervention from me.

Here is a brief look at the implementation_plan.md it generated:

# Amathus Backend & Frontend Upgrade Plan

## Phase 1: .NET Backend Upgrade (`netcoreapp3.1` → `net10.0`)
1. Project & Package Upgrades: Update <TargetFramework> to net10.0 across all 5 .csproj
files and upgrade NuGet dependencies (Google.Cloud.Firestore, Google.Cloud.Storage.V1,
System.ServiceModel.Syndication, etc.).
2. Code & Reliability Improvements: Fix async/await bug in ReadController.cs, update
FeedReader to use HttpClient, add an image proxy endpoint in Amathus.Web for Flutter
Web CORS, and update Dockerfiles to .NET 10.0 images.

## Phase 2: Audit & Update RSS News Sources
1. Test all 31 RSS feeds in amathussources.json and their logo URLs.
2. Discover updated RSS/logo URLs on active websites and remove defunct sources.
3. Update Source.cs, FeedConverter.cs, and functional tests, and verify with dotnet test.

## Phase 3: Deploy .NET Backend to Google Cloud (`events-atamel`)
Update Amathus/scripts/ to target events-atamel and deploy amathus-reader,
amathus-converter, and amathus-web to Cloud Run.

## Phase 4: Flutter Frontend Upgrade (`AmathusClient`) & Web Deployment
1. Upgrade pubspec.yaml to Dart 3 / Flutter 3.41 and replace discontinued packages.
2. Migrate to Sound Null Safety and SharedPreferences for Web compatibility.
3. Modernize UI with Material 3, responsive layouts, and deploy amathus-client to Cloud Run.

## Phase 5: Scripts & Documentation Update
Update READMEs and helper scripts, leaving all changes uncommitted for user review.

And the task.md checklist it updated as it completed each phase:

# Amathus Upgrade Tasks

- [x] **Phase 1: .NET Backend Upgrade (`net10.0`)**
- [x] Upgrade all 5 `.csproj` files from `netcoreapp3.1` to `net10.0` and update NuGet packages
- [x] Fix async upload bug in `ReadController.cs` and improve `FeedReader` / `DateTolerantXmlTextReader`
- [x] Update Dockerfiles to `.NET 10.0` images and `appsettings*.json` to `events-atamel`
- [x] **Phase 2: Verify & Update News Feeds (`amathussources.json`)**
- [x] Audit all 31 RSS feed URLs and logo URLs
- [x] Find updated RSS/logo URLs for moved sources and remove obsolete sources (17 active feeds verified)
- [x] Update `Source.cs`, `FeedConverter.cs`, `FeedTest.cs`, and `FeedtemTest.cs`
- [x] Verify all functional tests pass (`dotnet test` — 35/35 passed) and backend runs locally (`InMemory`)
- [x] **Phase 3: Deploy Backend Microservices to Google Cloud (`events-atamel`)**
- [x] Inspect existing resources on `events-atamel` (Cloud Run, Cloud Storage, Pub/Sub, Firestore, Cloud Scheduler)
- [x] Update `Amathus/scripts/` for `events-atamel` and test scripts (`test_services`)
- [x] Build and deploy `amathus-reader`, `amathus-converter`, and `amathus-web` to Cloud Run
- [x] End-to-end test all 3 deployed backend microservices
- [x] **Phase 4: Upgrade Flutter Frontend (`AmathusClient`) & Deploy Web App**
- [x] Upgrade `pubspec.yaml` to Dart 3 / Flutter 3.41 and modern packages
- [x] Migrate codebase to Sound Null Safety and Web compatibility
- [x] Redesign & polish UI (icons, typography, properly sized images, cards, responsive web layout)
- [x] Verify Flutter app locally and deploy Flutter Web frontend (`amathus-client`) to Cloud Run
- [x] **Phase 5: Update READMEs and Scripts**
- [x] Update `README.md`, `AmathusClient/README.md`, and deployment/testing scripts

Let’s break down what Gemini did in each subtask.

Upgraded the backend from .NET Core 3.1 to .NET 10.0

Gemini updated all 5 .csproj files to net10.0, upgraded all NuGet packages and Dockerfiles, fixed a subtle async void bug in ReadController.cs where Cloud Storage uploads weren't being awaited, and even added an image proxy endpoint to prevent CORS issues on Flutter Web.

Gemini’s response:

▸ Thought for 22s: The plan is to upgrade the Amathus project's `.csproj` files to a newer target framework
▸ Thought for 35s: Examining the Dockerfiles for the three services, the plan is to update the base image to the .NET 10.0 runtime
▸ Thought for 40s: Build verification confirms successful compilation on the specified .NET version, with no detected errors
...
#### 1. .NET Backend Upgrade (netcoreapp3.1 -> net10.0)
• Upgraded all 5 projects (Amathus.Common.csproj, Amathus.Reader.csproj,
Amathus.Converter.csproj, Amathus.Web.csproj, Amathus.FuncTests.csproj) to
.NET 10.0 (net10.0) and updated all NuGet packages (Google.Cloud.Firestore 3.10.0,
Google.Cloud.Storage.V1 4.13.0, Microsoft.AspNetCore.Mvc.NewtonsoftJson 10.0.0,
System.ServiceModel.Syndication 10.0.0, MSTest 3.8.2).
• Updated all 3 Dockerfiles to mcr.microsoft.com/dotnet/sdk:10.0 and
mcr.microsoft.com/dotnet/aspnet:10.0.
• Fixed an async void bug in ReadController.Read (await Task.WhenAll(...) instead
of feeds.ForEach(async ...)).
• Updated FirestoreFeedStore and CloudStorageSyndFeedStore to use
GoogleCredential.FromComputeCredential() when running on Cloud Run (K_SERVICE)
and reuse the StorageClient instance.
• Added ImageProxyController (GET /api/v1/imageproxy?url=...) to proxy remote news
logos and article thumbnails with CORS and cache headers for Flutter Web.

Audited and repaired 6 years of link rot in RSS feeds

Six years is an eternity for local newspaper websites. Out of the 31 RSS feeds in amathussources.json, many had changed their feed URLs, switched logo paths, or shut down entirely. Gemini wrote a script to probe every RSS feed and logo URL, discovered the new links on the active newspaper websites, removed defunct sources, and updated the XML parsers and functional tests.

Gemini’s response:

▸ Thought for 37s: Running a script to check the status of all RSS feeds and their logos should provide a current overview
▸ Thought for 22s: 33 out of 39 tests passed immediately, indicating an initial success rate.
▸ Thought for 1m 10s: Initial data retrieval seems successful: the feed fetch completed quickly with all expected items
...
#### 2. RSS News Sources Audit & Update
• Audited all 31 sources in amathussources.json. Updated moved RSS feed URLs and
HTTPS logo URLs for 17 active sources (cyprustoday, detaykibris, diyalog,
gazeddakibris, giynik, gundemkibris, haberalkibrisli, halkinsesi, havadis,
kibrisgazetesi, kibrisgercek, kibrismanset, kibristime, londragazete, vatan,
yenicag, yeniduzen) and removed defunct/blocked sources.
• Updated DateTolerantXmlTextReader and the feed item converters in
Amathus.Common/Converter to handle modern <atom:link rel="self">, <enclosure>,
and <media:content> tags.
• Verified all 35/35 functional tests pass (dotnet test Amathus.sln).

Migrated Flutter 1.x to 3.41 and visually debugged the UI

On the frontend, Gemini migrated AmathusClient from Dart 2.7 to Dart 3 Sound Null Safety and Flutter 3.41 with Material 3, replaced dart:io file storage with SharedPreferences for web compatibility, and containerized the Flutter Web build with Nginx.

Most impressively, after deploying the web app, Gemini opened the live URL, took screenshots to visually inspect its own UI work, and fixed visual issues it spotted — such as placing white transparent newspaper logos on dark contrast badges and fixing clipped card edges.

Gemini’s response:

▸ Thought for 31s: Upgrading the Flutter frontend, `AmathusClient`, begins with updating the Dart SDK constraint in `pubspec.yaml`
▸ Thought for 57s: Implemented image constraints for different feed item types: fixed size thumbnails for compact lists
▸ Thought for 16s: Attempting to capture a screenshot of the specified URL to visually inspect the rendered content
▸ Thought for 41s: It's necessary to investigate why the right edge of cards were clipped in a previous screenshot
▸ Thought for 15s: Successfully built the web application. Proceeding to rebuild and redeploy the client to the cloud environment
...
#### 3. Flutter Frontend Upgrade (AmathusClient) & UI Redesign
• Upgraded pubspec.yaml from Dart 2.7 to Dart 3.11 / Flutter 3.41 with sound null
safety and web-compatible packages (http, shared_preferences, url_launcher,
share_plus, flutter_widget_from_html_core, font_awesome_flutter, timeago).
• Replaced dart:io file storage in FeedsStorage with SharedPreferences so custom
source ordering works across Web, mobile, and desktop.
• Redesigned the UI across FeedsList, FeedListTile, FeedImage, FeedItemListTile,
FeedItemListTileWide, FeedItemView, AppDrawer, AppBottomNavigationBar,
SettingsView, and ContactView:
• Contrast-safe logo badges: Automatically places white-text transparent logos
(cyprustoday, detaykibris, gundemkibris, haberalkibrisli, kibrisgazetesi,
londragazete) on a dark slate badge and dark/colored logos on a white badge
alongside the source name and last updated time.
• Properly sized images: Constrained article thumbnails (96x76 in source lists,
124x92 in recent news cards, and 280px max height in article detail view)
with rounded corners and BoxFit.cover.
• Responsive layout: Adapts from a 1-column list on mobile to a 2/3-column
grid on tablet/desktop screens.

Deployed everything to Cloud Run

Using the gcloud and cloud-run-basics skills, Gemini set up the Cloud Storage bucket, Pub/Sub topic and push subscription, Firestore database, and Cloud Scheduler job, and deployed all three backend microservices and the Flutter Web frontend to Cloud Run in events-atamel ( europe-west1).

Gemini’s response:

● Read(~/.gemini/config/plugins/google-cloud-developer/skills/gcloud/SKILL.md)
▸ Thought for 18s: Considering the deployment target is Cloud Run, information relevant to "cloud-run-basics" must be retrieved...
▸ Thought for 1m 4s: Creating the storage bucket and Pub/Sub topic are the initial infrastructure steps.
▸ Thought for 13s: Services are now deployed and accessible. Proceeding to configure the necessary infrastructure components
▸ Thought for 26s: Investigating the root cause of the "default credentials not found" error in `amathus-converter`
▸ Thought for 11s: Deployment of the latest `amathus-client` image to Cloud Run in the specified region and project is required
...
Both the .NET backend (Amathus) and the Flutter frontend (AmathusClient) have been
upgraded to the latest versions, verified locally, and deployed to your Google Cloud
project (events-atamel in europe-west1). All changes remain uncommitted in your
local working tree so you can review and commit them when ready.
──────
### Live Cloud Run Services (events-atamel / europe-west1)
Service           | Role                                        | Live URL
-------------------|---------------------------------------------|----------------------------------------------
amathus-client    | Flutter Web Frontend                        | amathus-client-1086570528700.europe-west1.run.app
amathus-web       | Public REST API (/api/v1/feeds,             | amathus-web-1086570528700.europe-west1.run.app
| /api/v1/feeditems, /api/v1/imageproxy)      |
amathus-reader    | Scheduled RSS Feed Reader (amathus-reader-  | amathus-reader-1086570528700.europe-west1.run.app
| job every 10m -> gs://amathus-events-       |
| atamel-bucket)                              |
amathus-converter | Pub/Sub Push Converter (amathus-events-     | amathus-converter-1086570528700.europe-west1.run.app
| atamel-topic -> Firestore feeds)            |

Going further: A flurry of new features

Seeing Gemini 4 complete a 6-year full-stack upgrade and cloud deployment in onego was earth-shattering. I didn’t want to stop there. Staying in Turbo mode, I kept prompting Gemini to evolve the app into something more (see all commits).

Bilingual UI & navigation cleanup

First, I asked for a few quick UX improvements.

Prompt:

Great. I want you to make minor changes to the UI:

1- Currently the app is in Turkish, but add English as well and a way to toggle
between Turkish and English in settings.
2- Make "latest news" the main/first tab and "all news" as second. Also, rename
"all news" to something else. It's basically news from each news source,
maybe something like "newspapers"?
3- Change "Contact" page and only include my Twitter: https://twitter.com/meteatamel
and my dev email

Gemini’s response:

All three UI updates have been implemented, tested locally, and redeployed to Cloud Run:

• Live Web App URL: https://amathus-client-1086570528700.europe-west1.run.app

### Summary of Changes

1. Turkish & English Localization + Settings Toggle:
• Added bilingual (tr / en) localization state and persistence via SharedPreferences
in constants.dart and reactive rebuilding in AmathusApp (including timeago relative
timestamps in feeditem_view.dart, feed_list_tile.dart, feeditem_list_tile.dart, and
feeditem_list_tile_wide.dart).
• Added a Language selector card (Türkçe / English SegmentedButton) at the top of
SettingsView.
2. Reordered Tabs & Renamed "All News" to "Newspapers" (Gazeteler):
• Made Latest News (Son Haberler / Latest News, FeedItemsRecentView) the default home
screen and first tab (index: 0).
• Made Newspapers (Gazeteler / Newspapers, FeedsView) the second tab (index: 1)
across AppBottomNavigationBar and AppDrawer.
3. Updated Contact Page:
• Updated ContactView and constants.dart to remove Facebook and display only your
Twitter (https://twitter.com/meteatamel) and dev email (atameldev@gmail.com).

Expanding to all of Cyprus: Turkish, Greek, and English

Originally, Amathus only aggregated Turkish-language newspapers from Cyprus. I asked Gemini to research and add news sources from across the entire island of Cyprus in Turkish, Greek, and English, verify that every feed had current articles and working logos, and add language filtering with flag icons.

Prompt:

Currently this news reader app only contains news sources in Turkish
(and some English) from northern Cyprus. I want to expand it to include news
sources from all Cyprus and in Greek as well. Can you do a research on what other
news sources I can add? I'm looking for news sources from Cyprus with RSS feeds
and logos and in Turkish, Greek, or English.

Gemini inspected the XML of every candidate RSS feed, filtered out empty or stale feeds, onboarded 17 new Greek, English, and Turkish feeds (doubling the total to 34 active Cyprus newspapers), and added full Greek ( Ελληνικά) UI localization and vector flag icons.

Gemini’s response:

### Summary of Changes

#### 1. Backend (Amathus/) — 34 Cyprus News Sources & Language Support
- amathussources.json: Added all 17 verified news sources (8 Greek: AlphaNews.Live,
Dialogos, Lemesos Tv, Pafos Press, Philenews, Politis, Sigmalive, ToThemaOnline;
5 English: Cyprus Mail, Cyprus Today, Financial Mirror, Politis English, T-Vine;
21 Turkish total) along with a "Language" property ("tr", "el", or "en").
- Source.cs & Feed.cs: Added source ID constants and [FirestoreProperty] public string
Language { get; set; } so language metadata is persisted in Firestore and returned
by the API.
- Amathus.Web: Added optional ?language= query parameter filtering to /api/v1/feeds
and /api/v1/feeditems.

#### 2. Frontend (AmathusClient/) — Trilingual UI & Flag Icons
- Rebranded app from North Cyprus News (KKTC) to Cyprus News (Kıbrıs Haber /
Ειδήσεις Κύπρου / Cyprus News).
- Added full Greek (Ελληνικά) UI localization and timeago messages alongside Turkish
and English.
- Created FlagIcon widget rendering crisp vector Turkish, Greek, and British flags
across all platforms, and added SourceLanguageFilterBar to filter news sources by
All, Turkish, Greek, or English.

On-demand translation & “Cyprus Bicommunal News”

Having Turkish, Greek, and English newspapers side-by-side naturally begged the next question: what if you can’t read Greek or Turkish? I asked Gemini to add article translation using a Google Cloud service, allow hiding specific newspapers in Settings, rebrand the app to Cyprus Bicommunal News, and even generate a new logo for it.

Prompt:

Thanks. Now, I want a translation feature. For example, if news is in Turkish,
I want to be able to translate to Greek or English, and if it's Greek, I want to
be able to translate to Turkish and English, and if it's purely English, then
translate to Turkish or Greek. I want this button in every news item, ideally
by the share button on the top, but feel free to find a better place. Not sure
what you'd use for translation API, but prefer to use Google or Google Cloud
service and inform me about your decision.
...
I want the app to be called "Cyprus Bicommunal News"... Also, have a way to
unselect/hide some of the newspapers in settings... And I want a logo for my
Cyprus Bicommunal News app. Ideally, it should include the map of Cyprus and a
group of people (men, women, children) and some newspaper theme.

Gemini’s response:

### 1. Translation API Decision: Google Cloud Translation API V2 (translate.googleapis.com)
- Why this service:
1. Already enabled in events-atamel: translate.googleapis.com was already active on
your GCP project, and amathus-web authenticates automatically on Cloud Run via
Application Default Credentials (ADC) — so no API keys are needed or exposed to
the Flutter client.
2. HTML-aware translation: Using Google.Cloud.Translation.V2 (TranslateTextAsync for
Title/Summary and TranslateHtmlAsync for Detail) with in-memory caching.

### 2. Frontend Translation, Newspaper Hiding & Branding
- Added TranslateController and TranslateIconButton offering source-aware target
translation languages with flag icons (Turkish -> Greek/English, Greek ->
Turkish/English, English -> Turkish/Greek) and [Source Flag] -> [Translation Flag]
indicators.
- Added an eye/visibility icon button per newspaper in SettingsView to hide unselected
newspapers from Latest News and Newspapers.
- Integrated the new Cyprus Bicommunal News logo across the AppBar banners, navigation
drawer header, web favicon/PWA icons, and Android/iOS/macOS launcher icons.

One-click bulk translation & UI polish

As I played with the live web app, I realized translating articles one by one was too much clicking when browsing headlines. Over a few quick follow-up prompts, I asked Gemini to replace the per-card translate buttons with a single top-right bulk Translate dropdown button and clean up the card layout.

Prompt:

Instead of having translate buttons for each news item in both latest news and
newspapers pages, just keep the one translate button on top right. Somehow make
it more obvious that this is a translation button. When translation is in effect,
still show the to/from flags but move it in place of the translation button of
the news item now (left of share button basically). This should simplify UI.

Gemini’s response:

All updates have been applied and deployed to amathus-client:

1. Single Prominent Top-Right Translate Button (BulkTranslateIconButton):
Styled the top-right translate control as a clear dropdown button showing
[Translate Icon] Translate ▾ (localized to Çevir / Μετάφραση / Translate), and
[Translate Icon / Spinner] [Flag] <Language> ▾ when a translation is active.
2. Left Source Dropdown:
Updated SourceLanguageFilterBar to place the source language dropdown (All,
Türkçe, Ελληνικά, English) on the left and BulkTranslateIconButton on the right.
3. Removed Per-Item Translate Buttons in Lists:
Removed the individual translate buttons from each news card on both Latest News
and Newspaper pages, and placed the [From Flag] → [To Flag] indicator directly to
the left of the Share button when a translation is active.

The Final Result

Here is what Cyprus Bicommunal News looks like running live on the web today:

You can try out the live Flutter Web version on Cloud Run and check out the updated code on GitHub:

• Live Web App: https://amathus-client-1086570528700.europe-west1.run.app/
• GitHub Repo: https://github.com/meteatamel/amathus

Wrapping up

Looking back at my 2020 app modernization blog series, every phase of modernization back then, lifting and shifting, containerizing, moving to serverless, and migrating frameworks took weekends of manual effort and careful troubleshooting.

Fast forward to today: Gemini 4 took a 6-year-old codebase, migrated the backend across 7 major versions of .NET, migrated the frontend from Flutter 1.x to Flutter 3.41 with Sound Null Safety, repaired dozens of broken RSS feeds, deployed 4 microservices to Cloud Run, visually debugged its own UI via screenshots, and then helped me turn a single-language news reader into a trilingual, real-time translated Cyprus Bicommunal News web and mobile app in a matter of hours.

This is just the beginning. With Gemini 4, I have so many ideas on how to improve the app further, such as adding a AI news overview, AI news categorization, a daily AI generated podcast and more. Sky is the limit!

If you have an old side project gathering dust on GitHub, now is a great time to point Gemini 4 at it and see how far you can go.

Great time to be alive as a builder!

Originally published at https://atamel.dev.

6 Years of Tech Debt, 1 Prompt: Modernizing a Legacy App with Gemini 4 was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Antigravity (AGY) allows you to schedule instructions to run on a recurring schedule or one-time timer. However, it has two different ways of scheduling that results in two different behaviors.

In this post, I’ll share my learnings on scheduling tasks in AGY and the gotchas to look out for.

Two ways of scheduling tasks in AGY

In AGY, there are two ways of scheduling tasks:

1. With the /schedule command in the chat.
2. With the Scheduled Tasks panel on the top left.

While both let you schedule tasks, they are completely independent from each other and the way they schedule and display tasks are completely different as well. This can be confusing, so let’s look into each in more detail to clear up the confusion.

Permissions for scheduled tasks

Before we dive into how to schedule tasks, it’s important to note that scheduled tasks require the same permissions that you’d grant to the agent in your own conversations.

For example, let’s say you want to schedule this task:

Get the current weather in London from https://open-meteo.com/ and save it to a timestamped file

This prompt requires that the agent has write access to the project folder and it also has HTTP access to the Open-Meteo API. Normally, you’d allow these permissions as you go along at the conversation or project level but in scheduled tasks, you need to add these permissions ahead of time.

💡 Tip

Before scheduling a task, dry run the task in a project and add all the necessary permissions at the project level to make sure the scheduled task will run without permissions issues later.

In this case, I created a project and ran the prompt in the chat. I got the following prompt to allow HTTP access:

I allowed it for the project and now, I’m ready to schedule this prompt as a task in this project.

/schedule command

The first way to schedule tasks in AGY is with the /schedule command in a conversation. This command allows you to schedule one-time or recurring instructions as background tasks in the same conversation. As these background tasks are scheduled and executed, you can continue chatting with the agent in the same conversation as usual.

One-time task

For one-time task, you can try a prompt like this:

/schedule In 1 minute, get the current weather in London from https://open-meteo.com/ and save it to a timestamped file in the current folder.

First, you’ll see a background task scheduled in the chat:

You’ll also see the same background task on the right panel:

If you click on the background task on the right panel, you can also see the logs of the task which is quite useful:

Once the task is done, you’ll see updates in the chat and also the file created in the project folder:

Recurring task

For a recurring task, you can try this:

/schedule Every 10 minutes, get the current weather in London from https://open-meteo.com/ and save it to a timestamped file

You should see a similar background task in the chat and on the right hand side panel:

Similar to the one-time task, you can click on the background task to see the logs.

Every time the task runs, you’ll see updates in the chat and also the file created in the project folder.

If you close AGY desktop app and come back later, the background task will still be there and continue running at the scheduled interval.

However, if you further kill the AGY process like this:

The background task will be cancelled:

⚠️ Warning

Recurring tasks scheduled with /schedule command are cancelled if the AGY process is killed and you need to reschedule them.

Furthermore, you won’t see one-time or recurring tasks scheduled with the /schedule command in the Scheduled Tasks panel on the top left:

⚠️ Warning

It’s confusing that tasks scheduled with /schedule command in a conversation do not show up on the Scheduled Tasks panel.

Scheduled Tasks panel

The second way to schedule tasks in AGY is with the Scheduled Tasks panel on the top left but it’s different from the/schedule command in a number of ways:

1. You can only schedule recurring tasks with a cron schdule (i.e. no one-time tasks).
2. The scheduled tasks create their own conversation (i.e. not part of an existing conversation).
3. The scheduled tasks are actually scheduled sidecars with the added benefit of surviving AGY process restarts.

Let’s create the same example as a scheduled task and look at the differences.

Go to the Scheduled Tasks panel and create a new task as follows:

Once you create the task, you’ll see it listed under Scheduled Tasks panel.

You can also get the hint that it’s actually a sidecar. You can verify this by realizing that a new sidecar file is created in ~/.gemini/config/sidecars/london-weather-every-ten-min/sidecar.json:

{
  "builtin":  "schedule",
  "args":  [
    "*/10 * * * *",
    "agentapi",
    "new-conversation",
    "Get the current weather in London from https://open-meteo.com/ and save it to a timestamped file"
  ],
  "display_name":  "london-weather-every-ten-mins"
}

The sidecar is also enabled in ~/.gemini/config/config.json:

{
  "sidecars": {
    "london-weather-every-ten-mins": {
      "enabled": true,
      "projectId": "17bc69c1-0072-48b5-9b44-180b5e1c8694"
    }
  },
  ...

After 10 minutes, you should see the sidecar creating a new conversation and running the task. You’ll see updates in the chat and also the file created in the project folder.

If you close AGY desktop app and come back later, the scheduled task will still be there and continue running at the scheduled interval.

If you kill the AGY process, the sidecar will also be killed and you can verify this by checking the logs in ~/.gemini/antigravity/sidecar_data/london-weather-every-ten-mins/logs:

ERROR: logging before google.Init: I0922 12:24:50.517034      39 schedule.go:99] 
[schedule] Scheduler shutting down cleanly on signal: interrupt

However, if you start AGY app again, a new sidecar process will start up and will continue running the task at scheduled interval.

 [schedule] Next execution scheduled in 20s (at 2026-09-22 15:30:00 UTC), 
 will run by 2026-09-22 15:31:33 UTC

ℹ️ Note

If you want scheduled tasks to survive restarts, it’s better to use the Scheduled Tasks panel.

Summary

In this blog post, we’ve looked at two ways to schedule tasks in AGY. Here’s a summary of the key differences:

Originally published at https://atamel.dev.

Scheduling Tasks in Antigravity was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Antigravity (AGY) has an extensive permission system that defines how the agent should behave and what it has access to. However, these permissions are scattered across different settings and saved in various files that might make reasoning them difficult.

In this post, I’ll deep dive into these permission settings and share my learnings.

Permission Hierarchy

Before looking at the permission settings in detail, it’s important to note that the permissions in AGY are organized in a hierarchy:

1. Global (user) permissions.
2. Project (workspace) permissions.
3. Conversation (sesssion) permissions.

Each level inherits the permissions of the level above it but can override them. A project inherits global permissions but it can override them and a conversation can override both project and global permissions.

Global permissions

Global permissions apply to all projects and conversations of the user. They can be access via Settings -> General and are scattered across Agent Settings, Agent Behavior, Network Permissions, Terminal & Tooling Permissions and Browser sections:

These permissions are persisted in ~/.gemini/config/config.json file.

Project permissions

Project permissions inherit global permissions and can override them at the project level. These settings can be accessed via Project Settings and scattered across Agent Settings, Agent Behavior, and Local Permissions sections:

They’re very similar to global settings but arranged slightly differently in the UI and persisted in ~/.gemini/config/projects/<project_id>.json where<project_id> is the UUID of the project.

Conversation permissions

Conversation permissions are specific to a single conversation and they are triggered when an agent needs to perform an action that is not allowed by default:

You can allow the action once or only in the current conversation. You also have the option to always allow it at the project level or globally. In both cases, the relevant configuration files are updated.

Permissions

Now, let’s look into different permissions in detail. They’re presented slightly differently depending on whether you’re looking at global or project level settings.

Security preset

Security Preset dropdown is shown under Agent Settings both in global and project level settings. It is not a permission per say but rather it's a pre-set of 3 permissions: Outside of folders file access policy, Terminal Command Auto Execution and Enable Sandbox Mode with the following pre-set configurations:

• Default - manual review of terminal commands and files outside project folders.
• Full Machine - manual review of terminal commands and ability to read/write to any file.
• Turbo Mode - no review of terminal commands and ability to read/write to any file.
• Custom - custom settings.

💡 Tip

Always choose Custom in order to see and control the actual 3 underlying permissions.

Let’s break down the individual permissions in more detail.

Outside of folders file access policy

Configures how the agent tries to access files outside of its working folders:

• Always Ask (Default)
• Allow
• Deny

Terminal command auto execution

Controls whether terminal commands require your approval before running:

• Require Review (Default)
• Proceed in Sandbox
• Always Proceed

Enable sandbox mode

Restricts agent tools to a secure, isolated local sandbox:

• False (Default)
• True

Artifact review policy

Under Agent Behavior, there's Artifact Review Policy that determines whether the agent asks your review of artifacts (e.g. implementation plan) before proceeding:

• Always Ask (Default)
• Always Proceed

Browser Javascript execution policy

Only in global settings, under Browser, you'll find Browser Javascript Execution Policy that controls whether the agent can run custom JavaScript to automate complex browser actions:

• Disable (Default)
• Request Review
• Always Proceed

Agent Permissions

In addition to the settings above, there’s a number of fine-grained Agent Permissions on various actions such as file or network access, MCP tools, terminal commands, etc. with Deny, Ask, Allow options and a flexible pattern to specify what's allowed (e.g. read_file(/path) or read_file(dir), or read_file(*)).

These permissions show up in slightly different places in global and project settings but they’re for the following:

• File Access Rules: Allowed/denied file paths for read_file and write_file actions.
• Network Access Rules: Allowed/denied URLs for read_url action.
• Browser Actuation Rules: Allowed/denied URLs for execute_url action.
• Terminal Commands: Allowed/denied terminal commands for command action.
• Commands Outside Sandbox: Allowed/denied commands for unsandboxed action.
• MCP Tools: Allowed/denied MCP tools for mcp action.

Configuration files

It’s useful to know where these settings are persisted, in order to back them up or just see what’s being used without having to rely on the UI.

If you set these permissions globally, they end up in ~/.gemini/config/config.json under userSettings as follows:

{
  ...
  "userSettings": {
    "artifactReviewMode": "ARTIFACT_REVIEW_MODE_ALWAYS",
    "autoExecutionPolicy": "CASCADE_COMMANDS_AUTO_EXECUTION_OFF",
    "browserJsExecutionPolicy": "BROWSER_JS_EXECUTION_POLICY_DISABLED",
    "enableTerminalSandbox": false,
    "nonWorkspaceFileAccessPolicy": "AGENT_SETTING_POLICY_ASK",
    "globalPermissionGrants": {
      "allow": [
        "read_file(/Users/atamel/dev/local/testing)",
        "read_url(https://www.bbc.co.uk/)",
        "command(ls)",
        "unsandboxed(ls)",
        "mcp(cloudrun)"
      ],
      "ask": [
        "execute_url(https://www.bbc.co.uk/)",
        "command(ps)"
      ],
      "deny": [
        "write_file(/Users/atamel)",
        "command(rm)"
      ]
    }
  }
}

If you set them per project, they end up in ~/.gemini/config/projects/<project_id>.json under settings as:

{
  ...
  "permissionGrants": {
    "permissionGrants": {
      "allow": [
        "read_file(/Users/atamel/dev/local/testing)",
        "read_url(https://www.bbc.co.uk/)",
        "command(rm)",
        "unsandboxed(ls)",
        "mcp(cloudrun)"
      ],
      "deny": [
        "write_file(/Users/atamel)",
        "command(ls)"
      ],
      "ask": [
        "command(ps)"
      ]
    }
  },
  "settings": {
    "artifactReviewMode": "ARTIFACT_REVIEW_MODE_ALWAYS",
    "autoExecutionPolicy": "CASCADE_COMMANDS_AUTO_EXECUTION_OFF",
    "fileAccessPolicy": "AGENT_SETTING_POLICY_ASK",
    "sandboxMode": false
  }
}

ℹ️ Note

Global and project level settings have slightly different configuration names and organization, as you can see from the json snippets above.

What about AGY CLI and AGY IDE?

Everything I talked about above applies to AGY but you might be wondering: What about AGY CLI and AGY IDE and IDE extensions?

In AGY CLI, there’s a /permissions command that allows you to set some permissions and some of them end up in~/.gemini/antigravity-cli/settings.json and some end up in the global~/.gemini/config/config.json file. However, it's not quite intuitive and I couldn't figure out exactly which permissions ends up where and why.

In AGY IDE standalone, it seems like some of the permissions are saved in totally different place ~/Library/Application Support/Antigravity IDE/User/globalStorage/state.vscdb but I didn't dig into it further.

In a future post, I might try to explore permissions in AGY CLI and IDE in more detail.

Summary

This is a lot of information but hopefully the following table can be a good reference for all the permissions you can set in AGY:

Originally published at https://atamel.dev.

Agent Permissions in Antigravity was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

💡 This post is the concluding summary of a series on Antigravity configuration:

• Where does Antigravity look for Skills?
• Where does Antigravity look for MCP Servers?
• Where does Antigravity look for Rules and Workflows?
• Where does Antigravity look for Hooks?
• Where does Antigravity look for Sidecars?
• Where does Antigravity look for Agents?
• Where does Antigravity look for Plugins?

Over the past few weeks, I explored the ways to configure and extend Google Antigravity (AGY). What started as a simple exploration into agent skills quickly grew into a journey uncovering MCP servers, rules, workflows, lifecycle hooks, background sidecars, custom agents, and plugins.

Because Antigravity comes in three flavours (AGY, AGY CLI, and AGY IDE), and spans multiple configuration scopes (workspace, global, and plugin bundles), keeping track of what goes where can be challenging.

In this post, I’ll bring everything together into a single, comprehensive reference guide and cheat sheet.

Ways to Extend Antigravity

Here is a quick summary of what each customization mechanism is designed for:

1. Skills: Specialized folders containing instructions, scripts, and reference documents that give agents on-demand capabilities for complex workflows.
2. MCP Servers: External tool integrations using the Model Context Protocol standard to connect to databases, APIs, and cloud services.
3. Rules and Workflows: Rules are always-on or triggered behavioral guidelines and coding standards (system-level instructions). Workflows are user-triggered prompt templates executed on demand.
4. Hooks: Synchronous lifecycle event listeners that run scripts to enforce policies, add context, or log telemetry.
5. Sidecars: Autonomous background processes managed by AGY for long-running services, asynchronous listeners, or recurring schedules.
6. Custom Agents: Tailored agent personas with restricted tool sets, specialized system prompts, and dedicated models for specific subtasks.
7. Plugins: Distribution bundles packaging skills, MCP servers, rules, hooks, and custom agents together into a single distributable unit.

Directory Hierarchy

Below is the map of directories and files recognized across Antigravity:

~/.gemini/                         # GLOBAL
├── GEMINI.md                      # Rules
├── config/
│   ├── agents/                    # Agents
│   ├── config.json                # Config to enable sidecars
│   ├── global_workflows/          # Workflows
│   ├── hooks.json                 # Hooks
│   ├── mcp_config.json            # MCP servers
│   ├── plugins/                   # Plugins
│   │   ├── <plugin-name>/
│   │   │   ├── agents/            # Agents (plugin)
│   │   │   ├── hooks.json         # Hooks (plugin)
│   │   │   ├── mcp_config.json    # MCP servers (plugin)
│   │   │   ├── rules/             # Rules (plugin)
│   │   │   └── skills/            # Skills (plugin)
│   ├── sidecars/                  # Sidecars
│   └── skills/                    # Skills
|
├── antigravity/                   # AGY
│   ├── builtin/skills/            # Skills (builtin)
│   ├── mcp/                       # Cached MCP servers
│   └── sidecar_data/              # Sidecar runtime data
|
├── antigravity-cli/               # AGY CLI
│   ├── builtin/skills/            # Skills (builtin)
│   └── mcp/                       # Cached MCP servers
|
└── antigravity-ide/               # AGY IDE
    └── mcp/                       # Cached MCP servers

<workspace-root>/                  # WORKSPACE
└── .agents/
    ├── agents/                    # Agents
    ├── hooks.json                 # Hooks
    ├── mcp_config.json            # MCP servers
    ├── plugins/                   # Plugins
    │   ├── <plugin-name>/
    │   │   ├── agents/            # Agents (plugin)
    │   │   ├── hooks.json         # Hooks (plugin)
    │   │   ├── mcp_config.json    # MCP servers (plugin)
    │   │   ├── rules/             # Rules (plugin)
    │   │   └── skills/            # Skills (plugin)
    ├── rules/                     # Rules
    ├── skills/                    # Skills
    └── workflows/                 # Workflows

Wrapping Up

Antigravity provides a comprehensive and flexible customization options.

Check out the individual posts linked above for deeper walk-throughs.

Originally published at https://atamel.dev.

Summary : Where does Antigravity look for configurations? was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.