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.

TL;DR
agyis 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
agyfails silently: it exits0when 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:
| Area | Implementation | Operational Purpose |
|---|---|---|
| Execution mode | Non-interactive --print | Prevents the child process from hanging on interactive TTY prompts. |
| Model routing | Strict case-sensitive tier suffixes | Pins the exact Gemini 3.8 Flash variant (Low, Medium, or High). |
| Tool parity | Plugin and MCP management | Maps external MCP servers directly into the child agy workspace. |
| Quota checks | Local language server probe | Surfaces rate limits before burning time on a doomed prompt. |
| Failure triage | Log analysis on exit 0 | Separates 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:
- Inert without tool: A
command -vpreflight verifiesagyexists. If it is missing, the skill reports the requirement and stops. It never fabricates success. - Configurable engine: It respects
$AGY_BINbefore falling back toagyon$PATH. - Honest eval status: Because integration assertions require live Google credentials, the skill ships with its eval fixture marked as
pending1, 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-cliOnce 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
Verified through authenticated local runs; unauthenticated CI runners cannot exercise live Gemini endpoints. ↩