Mete Atamel

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 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.

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.

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.

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.

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.

Back in early 2020, I wrote a 4-part blog series on how a friend and I modernized Amathus, a Cyprus news aggregator app, using Google Cloud’s serverless technologies.

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):

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:

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:

💡 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.