Mete Atamel

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.

ℹ️ Note

This post blog is part of a series, see Summary : Where does Antigravity look for configurations?

Custom Agents have been recently announced in Antigravity (AGY). In today’s post, I’ll explore how to configure and use Custom Agents.

Custom Agents

Custom Agents in AGY are a way to create customized agents that can be used as main or sub-agents. This can be useful to limit the agent to a particular role with its specialized instructions, tools, and constraints. Currently, custom agents are only supported in AGY and AGY CLI, but not in AGY IDE.

ℹ️ Note

This post blog is part of a series, see Summary : Where does Antigravity look for configurations?

I’ve been exploring how to configure and extend Antigravity (AGY).

In today’s post, I’ll explore Plugins, yet another way of configuring AGY. We’ll also explore Build with Google plugins and the differences between AGY plugins and Agent plugins.

Plugins

Plugins in AGY are a way to package and group **Agents, Skills, MCP Servers, Rules, and Hooks together. This can be useful when you want to distribute and install a collection of these configuration options in one go. It’s also another way of configuring and extending AGY.

ℹ️ Note

This post blog is part of a series, see Summary : Where does Antigravity look for configurations?

Sidecars are a less known feature of Antigravity (AGY) with limited samples and documentation but still worth knowing about and that’s the topic of today’s post.

Sidecars

Sidecars are background processes that can run alongside AGY with their lifecycle managed by AGY. They can be useful to run background scripts (e.g. sending telemetry data) or recurring tasks that you want to run on a schedule (e.g. summarize across sessions).