Using AxiOwl With Antigravity

AxiOwl can work with Antigravity agent sessions as one of its supported local provider surfaces. In normal use, that means an operator or another agent can address a discovered Antigravity chat by name, send it a message through AxiOwl, and let Antigravity reply back through the AxiOwl MCP path with the correct provider-owned conversation identity.

The important detail is that AxiOwl treats "Antigravity" as a real provider surface, not as a generic text box. It discovers Antigravity sessions from Antigravity-owned local state, records them in the AxiOwl registry with provider-specific session ids, sends through an Antigravity delivery edge, and uses Antigravity MCP metadata to identify replies.

The Supported Surface

The current support matrix marks antigravity:agents as supported. The same matrix marks antigravity:cli as target, which is intentionally different. Antigravity agent sessions have response-backed support. Standalone AGY or Antigravity CLI conversations have historical proof and code paths, but the documented current bar still requires provider-owned metadata proof before they should be described as fully supported.

For operators, the safe rule is simple: use the antigravity provider for supported Antigravity agent sessions. Do not assume that antigravity-cli has the same support status.

What Installation Adds

On Windows, the AxiOwl installer line installs axiowl.exe and configures MCP entries for Antigravity. The documented install locations include:

%USERPROFILE%\.gemini\config\mcp_config.json
%USERPROFILE%\.gemini\antigravity\mcp_config.json
%USERPROFILE%\.gemini\antigravity-cli\mcp_config.json

The installer helper writes an axiowl MCP server entry that launches the installed executable with Antigravity host/provider settings. After installation, Antigravity should be restarted or a fresh chat should be opened so the MCP server definition is loaded by the provider.

That MCP setup matters because outbound delivery is only half the workflow. For a real AxiOwl roundtrip, Antigravity needs to be able to call the AxiOwl MCP tool when it replies.

How Discovery Works

AxiOwl discovery for Antigravity agents reads Antigravity annotation files under:

%USERPROFILE%\.gemini\antigravity\annotations

The discovery code looks for usable titles in those annotation files and creates registry-ready rows with:

provider: antigravity
provider_session_id: antigravity:cascade:<conversation-uuid>
node_id: local
source: antigravity_annotation_title
sendable: true

That is why a discovered Antigravity chat can be addressed by a human-readable name while AxiOwl still routes to a concrete provider session id. The visible name is for the operator. The antigravity:cascade:<uuid> value is the durable routing address.

The practical discovery command is:

axiowl discover antigravity --json

After discovery, the normal registry and list commands can show which names AxiOwl can send to:

axiowl list agents

Sending To An Antigravity Agent

Once an Antigravity session is discovered and enrolled, the everyday send command uses the same shape as other AxiOwl provider sends:

axiowl send --to "Antigravity chat name" --body "Please review the latest handoff note and reply with the next action."

For longer prompts, use standard input:

@'
Read the current task context.
Summarize the risk.
Reply through AxiOwl with the concrete next step.
'@ | axiowl send --to "Antigravity chat name" --stdin

The Antigravity provider implementation expects the target registry row to contain a usable cascade id. It normalizes the recipient id from antigravity:cascade:<uuid>, locates Antigravity's language server executable, reads the live Antigravity main.log, derives the local AgentAPI endpoint, and calls the language server agentapi send-message path.

The provider method recorded by the implementation is:

antigravity_language_server_agentapi_send_message

If AxiOwl cannot find the language server, cannot read the live Antigravity log, cannot derive the AgentAPI endpoint, or cannot verify that the provider echoed the delivered content, it fails loudly instead of claiming delivery.

Creating A New Antigravity Conversation

AxiOwl also exposes a create path for Antigravity:

axiowl create --provider antigravity --name "New Antigravity Chat" --body "Start a new conversation."

The implementation uses the Antigravity language server AgentAPI new-conversation path. It requires an initial message, derives the live AgentAPI endpoint from Antigravity runtime logs, reads the Antigravity project id from local app storage, and returns a provider session id in the antigravity:cascade:<uuid> form when it can correlate the new conversation.

The requested display name and the provider's eventual display title are not always the same thing. AxiOwl records correlation state and can recommend a rename when the provider title does not match the requested name.

How Replies Keep Their Identity

The most important Antigravity roundtrip detail is sender identity. A reply should not be guessed from a workspace path, a command-line argument, or a stale registry row. It should come from provider-owned metadata attached to the MCP tool call.

For Antigravity agents, AxiOwl accepts metadata keys such as:

antigravity.google/conversation_id
antigravity.google/conversationId
antigravity.conversation_id
antigravity.conversationId

The working identity mapping is:

Antigravity MCP metadata conversation UUID
-> sender address: <uuid>
-> registry session: antigravity:cascade:<uuid>
-> identity source: mcp_call_meta+antigravity_conversation_id

This is what lets an Antigravity chat reply through AxiOwl and be recognized as the same provider session that discovery enrolled earlier. A documented roundtrip test proved this path: an Antigravity chat received a request, performed a web-backed answer, called the AxiOwl MCP send tool, and the reply appeared back in the originating Codex chat with sender identity resolved from antigravity.google/conversation_id.

What To Expect Operationally

Antigravity has had more than one tested message insertion path. Older tests showed that AgentAPI system messages could be stored in Antigravity's brain storage without automatically causing the agent to act. Later work used a CDP user-turn method against the Antigravity Manager composer to trigger immediate action in the selected cascade.

That distinction is useful for operators:

• A provider accepting a message is not the same thing as the agent acting on it.
• A response-backed MCP roundtrip is stronger evidence than a local send receipt.
• The target session id matters. AxiOwl should route to the named antigravity:cascade:<uuid> target, not whichever chat happens to be visible.
• If Antigravity runtime state is stale, restart Antigravity or open a new chat after MCP configuration changes.

In routine AxiOwl usage, start with discovery, send to a named Antigravity agent, and verify the reply path. For diagnostics, the useful checks are whether the registry row exists, whether the provider session id has the antigravity:cascade: prefix, whether Antigravity has loaded the AxiOwl MCP server, and whether replies include provider metadata.

What Not To Overclaim

The current repository is explicit about the boundary between Antigravity agent support and Antigravity CLI support. The supported article-level claim is that AxiOwl supports Antigravity agent sessions through the Antigravity provider edge and MCP reply path.

The Antigravity CLI path is different. The code can discover AGY conversations from:

%USERPROFILE%\.gemini\antigravity-cli\cache\last_conversations.json
%USERPROFILE%\.gemini\antigravity-cli\conversations

and it has create/send implementation work around the agy executable. But the provider documentation says final CLI support still needs provider-owned MCP metadata proof or an equivalent provider-supported metadata path. Until that bar is met, Antigravity CLI belongs in the target category.

Closing

Using AxiOwl with Antigravity is mostly about respecting the provider boundary. AxiOwl discovers real Antigravity sessions, records them as antigravity:cascade:<uuid> registry targets, sends through the Antigravity language server AgentAPI path, and accepts replies through MCP only when Antigravity supplies usable conversation metadata.

That makes Antigravity a first-class AxiOwl routing target without pretending every Antigravity-adjacent surface is already finished. Use antigravity for supported agent sessions, keep antigravity-cli separate, and treat response-backed MCP identity as the proof that the route is working.