Skip to main content

How AxiOwl Works

AxiOwl is a normalization and communication layer around provider sessions, daemon-hosted agents, mobile clients, and A2A endpoints.

One Common Journey

choose target
-> resolve exact identity
-> select declared route
-> use destination integration
-> record correlation
-> return provider reply, task result, or agent timeline

Identity And Addressing

IdentityPurpose
Display nameHuman-readable label
AliasConvenient lookup name
Provider and surfaceExact product experience, such as Codex agents or Codex CLI
Provider session IDProvider-owned conversation address
Host IDImmutable identity of one AxiOwl daemon
Mobile client IDStable identity of one paired app installation
Project/workspace IDHost-owned working context
Agent IDOne daemon-managed agent lifecycle
A2A agent/task IDStandards-based endpoint and task identity

Friendly names can change. Delivery continues to use the concrete provider, host, client, agent, or task identity required by the selected route.

Discovery And Registry

Provider surfaces store sessions differently. Their AxiOwl packages discover through the provider-specific state available to that product and normalize useful fields into the local registry.

A registry record can include display name, aliases, provider, surface, provider session ID, local or remote ownership, supported operations, sendable state, and recent observation information.

The daemon maintains a related connected view of providers, projects, workspaces, agents, and active client sessions on its host.

Provider Packages

Each local provider surface has its own package because discovery, MCP metadata, delivery, patching, process ownership, and cleanup differ by product.

A package may contain an isolated worker, MCP configuration, provider plugin or skill, VSIX bridge, metadata integration, and installer ownership. Provider authentication and conversation data remain with the provider.

Provider packages can update independently from the AxiOwl core and from other providers.

Local Provider Flow

CLI, mailbox, or MCP caller
-> local registry target
-> selected provider package
-> provider-owned session
-> receipt and correlated MCP reply

Daemon And Mobile Flow

paired mobile app
-> encrypted relay or direct connection
-> AxiOwl daemon
-> selected project, workspace, and agent
-> provider runtime
-> ordered timeline back to the client

The daemon owns host identity, pairing, provider processes, projects, workspaces, agents, permissions, timeline sequencing, acknowledgements, and reconnect state.

A2A Flow

A2A client
-> Agent Card and authenticated endpoint
-> message or task
-> destination agent
-> state, result, and artifacts

Desktop provider sessions can be exposed as selected A2A agents through the interactive user boundary. AxiOwl can also call external Agent Cards.

Route Selection

DestinationRoute
Provider session on this computerLocal provider package
Paired host across networksEncrypted relay
Paired host on a controlled networkDirect daemon connection
External standards-based agentA2A
Managed AxiOwl nodeA2A-over-SSH
Explicit remote CLI operationSSH Command Dispatch

Receipts And Completion

EvidenceMeaning
Acceptance receiptAxiOwl accepted the operation
Provider delivery stateThe provider integration accepted the handoff
MCP replyThe provider session returned a correlated response
A2A task stateThe external endpoint reported task progress
A2A terminal resultThe task returned its result and artifacts
Daemon connection stateThe client is connected to the intended host
Agent timeline terminal eventThe host provider turn reached its reported terminal state

Account And Authority Boundaries

Website account, license entitlement, host identity, mobile pairing, relay routing, direct network access, A2A credentials, SSH keys, and provider authentication remain separate. One credential does not silently become authority for another subsystem.