AxiOwl Makes Remote AI Work Addressable

Remote AI work gets hard when "the target" is only a memory: a terminal on one machine, a chat window on another, an SSH host, a provider session id, or a title that changed yesterday. AxiOwl's current C++ implementation treats that problem as an addressing problem. It records reachable AI sessions as named registry rows, records remote machines as node rows, and makes sender, target, provider, and proof state explicit before a message is handed to delivery.

That distinction matters. AxiOwl is not a generic background tunnel that guesses where work should go. The current source-of-truth provider matrix marks remote as unsupported for local-provider remediation builds, and the dispatch table intentionally returns a remote-out-of-scope result for that build. The useful product idea is narrower and more durable: AxiOwl has a concrete address model for AI work, and it refuses to use remote paths as a silent fallback when local delivery is not proven.

Addressability Starts With The Registry

AxiOwl is structured as a local Windows coordinator. The documented core flow is:

user / provider MCP call / CLI
  -> axiowl.exe
  -> MCP or CLI command handler
  -> MessagePipeline
  -> registry target and sender resolution
  -> targeted discovery repair when needed
  -> provider_edges dispatch
  -> provider-specific delivery
  -> delivery logs and provider proof

The important step is registry resolution. A registry row is not just a label. In the C++ model, an AgentRecord includes:

• display_name and aliases, so an operator can use human-readable names.
• provider, such as codex, cursor, vscode_native, or remote.
• provider_session_id, so the name resolves to the provider-owned session.
• node_id, so the session is tied to a local or remote machine.
• sendable, source, last_seen_at, last_verified_at, and last_error, so AxiOwl can distinguish usable addresses from weak evidence.

That is what makes work addressable. The command is simple:

axiowl send --to "Target chat name" --body "Message text"

But under the command, AxiOwl resolves a named target to a specific provider session and node before it accepts the request. If the target is missing, the MessagePipeline runs one targeted discovery repair. If a row exists but is not sendable, the send is rejected instead of pretending the address is good.

Remote Nodes Are Separate Address Records

Remote addressability uses a second registry: node records. A NodeRecord stores the node id, display name, aliases, host, SSH user, SSH key path, enabled state, verification timestamps, and last error. The CLI exposes that model directly:

axiowl node add --id "front" --host "<host>" --ssh-user "<ssh-user>" --key "<ssh-key-path>" --name "Frontend"
axiowl node verify --id "front"
axiowl node list

The older registry add-node command shape is still present too:

axiowl registry add-node --id "front" --host "<host>" --user "<ssh-user>" --key "<ssh-key-path>" --name "Frontend"

Once a node exists, a remote agent row can point at it:

axiowl registry add-agent --name "Remote Test" --provider remote --node "front" --session "<remote agent name>"

The address is no longer "SSH into that box and find the right chat." It is "Remote Test", backed by a node id and a remote target identifier. That gives operators a durable handle they can inspect, list, verify, repair, or remove.

AxiOwl Does Not Confuse Addresses With Proof

AxiOwl's docs and tests are careful about proof boundaries. A send receipt can say accepted_by_axiowl, but that is not the same as provider delivery proof. The receipt means AxiOwl validated the request, resolved the target, and handed the request to the delivery layer. End-to-end proof requires the target provider to receive the message and reply back through the AxiOwl MCP tool with correct provider-owned sender metadata.

That design shows up in the tests. The core test suite verifies that a send returns an AxiOwl receipt first, logs delivery_receipt as axiowl_only, records the receipt boundary as after target resolution and before provider work, and does not report provider acceptance on the sender receipt path.

The same principle protects sender identity. AxiOwl requires an explicit sender for CLI sends, and MCP replies are expected to carry provider/session metadata. The registry can resolve a sender by exact provider session id, alias, or name, but the implementation avoids treating stale display names as stronger than provider-owned session identity.

Remote Is Explicit, Not A Fallback

The current product contract is conservative about remote behavior:

• The provider support matrix says remote is unsupported for the local-provider remediation build.
• The installer behavior matrix says remote features can remain present, but should be unchecked by default.
• The installer provider contract marks remote as remote-only and gives it explicit enroll, deploy, and discovery feature ids.
• The security docs say local provider support should remain local unless remote is explicitly selected.
• The provider dispatch table returns an excluded_remote_out_of_scope result for remote in this build.
• Targeted discovery adds an issue saying remote discovery is out of scope for local targeted miss resolution.

That may sound like a limitation, but it is the right boundary. If a local VS Code, Cursor, Codex, or CLI provider path fails, AxiOwl should not hide that failure by hopping to another machine. Unsupported remote delivery must be visible as unsupported.

At the same time, the repo contains the pieces that make a remote path addressable when a build or selected feature enables that contract. provider_remote.cpp builds an SSH relay command against a registered node. remote_relay.cpp implements a simple stdio relay protocol with hello, deliver, error, upstream_message, and deliver_result frames. The relay carries the final visible body plus sender fields such as sender agent, sender node, and sender source. The Windows desktop README also documents the Linux-side command surface:

axiowl relay-session --stdio

The README is explicit that the Linux remote app supports Codex CLI delivery only and does not support VS Code, Antigravity, desktop IPC, GUI, tray behavior, or remote relay chaining.

Why This Helps Operators

Addressable remote AI work gives an operator a better control surface than ad hoc instructions. You can inspect the registered nodes. You can see whether an agent row is sendable. You can tell whether the row came from manual enrollment, discovery, MCP metadata, or another source. You can separate a missing node, a missing target, an unsupported provider, and a provider that accepted a message but never replied.

It also makes failures easier to discuss. "Remote Test is not in the registry" is different from "front is not verified" or "the current build excludes remote delivery" or "the provider reply did not carry sender metadata." AxiOwl's logs and registry fields exist to preserve those distinctions.

The Practical Takeaway

AxiOwl makes remote AI work addressable by turning chats, sessions, and machines into explicit records. A human can still use a friendly name, but AxiOwl keeps the provider session id, node id, sendability, source, and proof state behind that name.

In the current source-of-truth docs, remote is not a broadly supported delivery surface. That is not a contradiction. It is the point of the design: first make the work addressable, then require each delivery path to prove itself instead of falling through silently.

Sources read

• README.md
• apps/windows-desktop/README.md
• docs/reference/README.md
• docs/reference/architecture-overview.md
• docs/reference/provider-support-matrix.md
• docs/reference/installer-behavior-matrix.md
• docs/user/README.md
• docs/developer/README.md
• docs/security/trust-boundaries.md
• docs/providers/remote.md
• apps/windows-desktop/src/models.hpp
• apps/windows-desktop/src/registry.hpp
• apps/windows-desktop/src/registry.cpp
• apps/windows-desktop/src/message_pipeline.cpp
• apps/windows-desktop/src/provider_edges.cpp
• apps/windows-desktop/src/provider_remote.cpp
• apps/windows-desktop/src/remote_relay.cpp
• apps/windows-desktop/src/discovery.cpp
• apps/windows-desktop/src/discovery_remote.cpp
• apps/windows-desktop/src/cli.cpp
• apps/windows-desktop/src/installer_provider_contract.cpp
• apps/windows-desktop/tests/core_tests.cpp
• apps/windows-desktop/tests/installer_provider_contract_tests.cpp

Image prompt:

Create a polished graphic image related to: remote AI work becoming addressable through explicit node and session records.

Subject: a clean technical illustration of a metal address plate connected by glowing network paths to three small server terminals and a central routing console, with abstract session cards beside the console but no readable text.
Style: halfway between a clean symbolic icon and a realistic product/technical illustration; professional SaaS/technical marketing style; crisp edges; high detail; no text; no logos.
Background: solid #00ff00 chroma key green screen background covering the full canvas edge to edge.
Restrictions: no owl, no axolotl, no birds, no animals, no mascot, no text, no watermark.