AxiOwl Cross-Provider Messaging Explained

Cross-provider messaging in AxiOwl means that one AI session can address another by a registered agent name, while AxiOwl handles the provider-specific mechanics underneath. The sender does not need to know whether the target is a Codex agent, a Codex CLI thread, a Cursor composer, a VS Code chat surface, VS Code Copilot, or an Antigravity agent. AxiOwl resolves the target, checks identity, and dispatches the message through the correct provider edge.

That is the important distinction: AxiOwl is not just a shared prompt template or a clipboard helper. In the current Windows desktop architecture, it is a local coordinator with a CLI, an MCP server, a durable registry of sessions, provider discovery, provider-specific delivery code, evidence logs, and a delivery worker boundary.

The Basic Flow

The AxiOwl architecture documents describe the core path like this: a user, CLI call, or provider MCP call enters axiowl.exe; command handling passes into the message pipeline; the pipeline resolves the sender and target from the registry; targeted discovery can run once if the target is missing or stale; provider dispatch chooses the right edge; provider-specific delivery writes to the actual provider surface; logs record what happened.

In practical terms, the operator-facing command looks like this:

axiowl send --to <agent> --body <message> --from <agent>

For longer payloads, AxiOwl also supports stdin:

Get-Content .\message.txt | axiowl send --to <agent> --stdin --from <agent>

Provider-hosted agents should normally use the typed MCP tool instead of building raw command lines themselves. The MCP server exposes tools such as axiowl_send_message, axiowl_create_agent, axiowl_discover, axiowl_list_agents, axiowl_status, and axiowl_whoami. Its initialization instructions explicitly tell provider hosts to use axiowl_send_message for sending and to let AxiOwl resolve stable sender identity from the host MCP session metadata.

The Registry Is The Address Book

AxiOwl cross-provider routing depends on a durable local registry. A registry row represents one reachable provider session or agent. The implementation stores fields for the visible display name, aliases, provider, provider-owned session id, node id, enabled state, sendable state, source, first seen time, last seen time, last verified time, and last error.

That registry is what lets a human or an agent say "send this to Build Reviewer" instead of supplying a provider-specific session id every time. The lookup code matches by display name, alias, provider session id, and some normalized session forms. It prefers sendable and newer rows when multiple candidates exist.

The CLI exposes this registry directly:

axiowl list agents
axiowl registry add-agent --name <agent> --provider <provider> --session <provider-session-id>
axiowl registry remove-agent --name <agent> --provider <provider> --session <provider-session-id>

Discovery can also populate or repair rows:

axiowl discover all --json
axiowl discover codex --target <agent> --json
axiowl discover cursor --target <agent> --json

The message pipeline uses discovery carefully. If a target is not found, or if an existing target row needs repair, AxiOwl runs one targeted discovery pass and then checks the registry again. Discovery is useful for finding candidate sessions, but the docs are clear that discovery alone is not provider delivery proof.

Provider Edges Do The Actual Delivery

The provider dispatch table is the cross-provider switchboard. In the current implementation, deliver_to_provider routes known provider names to provider-specific functions:

• codex
• codex_cli
• vscode_native
• vscode_copilot_backed
• antigravity
• antigravity_cli
• cursor
• cursor_cli
• claude_code_cli
• copilot_cli
• opencode_cli

The support matrix separates current supported surfaces from target or unsupported surfaces. Supported surfaces include Codex agents, Codex CLI, VS Code native chat/session surfaces, VS Code Copilot, Cursor agents, and Antigravity agents. Some CLI surfaces have code paths or historical evidence but remain target status until they meet the current metadata and response-backed proof bar. Remote delivery is explicitly out of scope for the local-provider remediation build, and the provider edge returns a loud remote-out-of-scope result instead of silently falling back.

This matters operationally. AxiOwl is designed so provider differences live in provider edges, bridge extensions, patches, and MCP config, not in every message sender. Cursor delivery uses a Cursor bridge command watcher and the glass.axiowlSubmitToAgent hook when installed. VS Code native delivery uses bridge commands and VS Code chat/session commands. Codex agent delivery uses the Codex provider edge and MCP reply path. Antigravity agent delivery uses the Antigravity provider edge and MCP reply path.

The sender sees a consistent address and command shape. AxiOwl carries the provider-specific details.

A Receipt Is Not The Same As Proof

One of the most useful design choices in AxiOwl is that it names the receipt boundary. When the message pipeline validates the request, resolves the target, and hands the request to the delivery layer, it can return accepted_by_axiowl. That means AxiOwl accepted the request. It does not automatically mean the provider received the message.

The stronger signal is provider acceptance, and the strongest end-to-end proof is a reply through AxiOwl MCP from the target provider session. The architecture overview says the reply path matters because it proves the target provider received the message, acted on it, and replied with provider-owned sender identity.

That distinction prevents false confidence. If a Cursor bridge is stale, a VS Code extension folder is old, a Codex session has stale MCP state, or an Antigravity session lacks usable metadata, AxiOwl should show the failure or unresolved state rather than pretending a message completed.

Sender Identity Is A Hard Rule

Cross-provider messaging only works if replies can route back to a real provider session. AxiOwl therefore requires sender identity to be resolved. For CLI send, the usage supports --from <agent> and --from-node <node>. In MCP flows, the server expects provider/session metadata from the host or from a provider patch that supplies metadata programmatically.

The current support matrix is explicit: for CLI providers, environment-only identity injection is not considered final support. The sender identity must come from real MCP metadata or a provider-owned patch. The registry code also rejects weak identity in subtle cases, such as a display name that is really just a raw session id for a non-manual source.

That may sound strict, but it is what makes cross-provider replies useful. Without a reliable sender, the target can receive a message but AxiOwl cannot confidently know where the response should go.

What Operators Can Inspect

AxiOwl is built to be inspectable. The status command prints paths for the registry, node registry, evidence log, delivery log, create lifecycle log, installed executable, activation state, local endpoint, registered agents, and registered nodes:

axiowl status

The provider matrix also defines the support bar. A surface is not supported merely because AxiOwl can write a config file or launch a process. The bar is provider/session discovery, required installer pieces, sending to a named session, provider receipt, reply through AxiOwl MCP, and correct provider-owned sender identity on the reply.

For developers, that gives debugging a concrete shape:

• Is the target in axiowl list agents?
• Is the registry row sendable?
• Does axiowl discover <provider> --target <agent> --json find or repair the session?
• Does axiowl status point to the expected registry and logs?
• Did AxiOwl only accept the request, or did the provider edge report acceptance?
• Did the target reply through MCP with the right sender identity?

Those questions line up with real implementation boundaries instead of vague "agent did not respond" troubleshooting.

Why Cross-Provider Messaging Matters

The practical value is coordination. A Codex session can ask a Cursor agent to inspect UI behavior. A VS Code chat session can send context to a Codex CLI thread. An Antigravity agent can participate in the same addressable messaging system as editor-backed agents, as long as the provider surface has the required AxiOwl integration and identity metadata.

AxiOwl does not erase provider differences. It makes those differences explicit and routeable. Each provider still has its own bridge, MCP config, patch sensitivity, auth state, session metadata, and failure modes. The benefit is that the sender can work at the level of named agents while AxiOwl handles the session registry, provider edge selection, delivery boundary, and reply identity rules.

That is the core of AxiOwl cross-provider messaging: a local coordinator, a real registry, explicit provider edges, inspectable logs, and a strict proof standard for replies. It is a messaging layer for working agents, not a claim that every provider surface behaves the same.