skip to content

Piloting Antigravity from Hermes: How to Drive agy Headless and Keep It Honest


There is a model that beats mine at gnarly refactors. It just lives behind a different CLI.

The usual workaround is miserable. Open a second terminal. Paste the context again. Re-explain your repo conventions. Then lose the whole thing the moment you close the window.

So I stopped switching. I taught my agent to drive the coding agents, like a real orchestrator.

This picks up where my previous post on the Hermes Skills Foundry left off.

Hermes agy

TL;DR

  • agy is Google’s Antigravity CLI, currently at v1.4.0 — a terminal-first agent running Gemini.
  • I wrapped it in a Hermes skill, agy-antigravity-cli, so Hermes can delegate work to it without giving up its own memory and skills.
  • Headless agy fails silently: it exits 0 when a turn times out or a file write is auto-denied. The skill catches both.
  • That forced a real amendment to my foundry’s Gate 4 — with explicit rules for adapter skills.
  • Net result: two agents, one workflow, no vendor lock-in.

Enter agy (and the Adapter Idea)

agy is Google’s official Antigravity CLI. It is fast and navigates large codebases with precision — exactly what makes it worth reaching for on a thorny refactor.

But swapping your primary agent runtime just to access it means throwing away your learned skills and memory tiers. That is a bad trade.

So I built an adapter: agy-antigravity-cli, open-sourced under the MIT license in my foundry repository.

Hermes stays on its own model and remains the pilot. When a task calls for Gemini, Hermes delegates the work to agy through a subshell call, monitors execution, and folds the result back into working memory.


The Orchestration Flow

Here is the pipeline from prompt to disk:

flowchart LR
accTitle: Hermes piloting agy flow
accDescr: Hermes receives a prompt, triggers agy-antigravity-cli via subshell, executes agy against Gemini 3.8 Flash, and captures stdout and file diffs.
User([Task / Prompt]) --> Hermes[Hermes Agent]
Hermes -->|skill call| Adapter[agy-antigravity-cli]
Adapter -->|subprocess --print| Agy[agy v1.4.0]
Agy -->|API call| Gemini[Gemini 3.8 Flash<br/>Low / Medium / High]
Gemini -->|reasoning + edits| Agy
Agy -->|stdout + filesystem| Adapter
Adapter -->|verified result| Hermes

Hermes stays lean. agy does the heavy lifting. Neither agent needs to know the internal wiring of the other.


What the Skill Covers

Driving a terminal-oriented AI assistant headlessly from another agent is full of sharp edges. The skill packages that ergonomics into a predictable interface:

AreaImplementationOperational Purpose
Execution modeNon-interactive --printPrevents the child process from hanging on interactive TTY prompts.
Model routingStrict case-sensitive tier suffixesPins the exact Gemini 3.8 Flash variant (Low, Medium, or High).
Tool parityPlugin and MCP managementMaps external MCP servers directly into the child agy workspace.
Quota checksLocal language server probeSurfaces rate limits before burning time on a doomed prompt.
Failure triageLog analysis on exit 0Separates silent auto-denials from auth expirations and resource caps.

Two Hard-Won Rules for Headless agy

Headless AI tools love to fail silently while reporting success. Two agy quirks cost me hours of debugging.

1. Bound the Job, Not the Clock

Pass a finite timeout like --print-timeout 30 and agy hard-cuts the turn the second time runs out.

The trap? It still exits with code 0.

Your parent agent sees a clean shell exit, reads empty stdout, and assumes the job succeeded cleanly. The skill defaults to --print-timeout 0, so agy waits for the model turn to finish instead. Bound the task in your prompt — never clip the turn with a blunt wall-clock timer.

2. Headless Writes Require Explicit Bypass

Interactively, agy prompts for confirmation before modifying a file or running a shell command.

In headless print mode, there is no interactive terminal. Rather than throwing an error, agy auto-denies the action, writes nothing to disk, and exits 0.

To let agy edit files and run commands unattended, pass --dangerously-skip-permissions.


Gate 4 and the Standard Amendment

In my previous post, I introduced the Hermes Skills Foundry and its four quality gates. Gate 4 originally banned any skill requiring an external code assistant, to prevent vendor lock-in.

agy-antigravity-cli needed an explicit exception.

Rather than bending the rules, I amended the foundry standard. Gate 4 now permits adapter skills — skills whose declared purpose is piloting an external agent — under three mandatory conditions:

  1. Inert without tool: A command -v preflight verifies agy exists. If it is missing, the skill reports the requirement and stops. It never fabricates success.
  2. Configurable engine: It respects $AGY_BIN before falling back to agy on $PATH.
  3. Honest eval status: Because integration assertions require live Google credentials, the skill ships with its eval fixture marked as pending 1, rather than faking a 100% pass rate.

Getting Started

Install the adapter skill directly into your Hermes setup with one command:

hermes skills install sentenza/hermes-skills-foundry/skills/agy-antigravity-cli

Once installed, Hermes auto-detects agy, respects your Gemini reasoning tiers, and treats Antigravity as a first-class execution backend.

Check out the implementation, test fixtures, and updated Gate 4 specification in the hermes-skills-foundry repository.

Footnotes

  1. Verified through authenticated local runs; unauthenticated CI runners cannot exercise live Gemini endpoints. ↩