Mete Atamel

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

ℹ️ Note

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

In today’s post, I’ll talk about Hooks in Antigravity, what they are, how to configure them, and some shortcomings.

Hooks

Hooks allow you to run custom scripts or programs at specific points in the Antigravity agent lifecycle, such as before or after model or tool calls. They are a way to extend the functionality of the agent. Hooks run synchronously as part of the agent loop and they can be useful for things like adding context, validating actions, enforce policies or logging interactions.

ℹ️ Note

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

I’ve been exploring different ways of customizing Antigravity and where it saves its various configuration files. For Agent Skills, see Where does Antigravity look for Agent Skills? and for MCP Servers, see Where does Antigravity look for MCP Servers?.

In today’s post, I’ll revisit Rules and Workflows. Back in November, I blogged about them in Customize Google Antigravity with rules and workflows but a few things changed since then, so let’s do a refresh.