AxiOwl vs Agent Coordination Protocols

Agent coordination protocols are useful because they give software a shared way to describe calls, tools, messages, or handoffs. But a shared interface is not the same thing as a working route between real provider sessions on a real machine. AxiOwl sits in that second category: it uses protocol surfaces where they help, but its main job is operational coordination across installed provider apps, local registries, discovery, delivery adapters, and evidence logs.

That distinction matters. A protocol can say what a message should look like. AxiOwl has to answer the messier questions: which provider session is the target, whether that session is still sendable, which adapter can reach it, what identity should be used for the sender, what the installer configured, and what kind of proof the operator actually has after a send.

AxiOwl Uses Protocols, But It Is Not Only A Protocol

The current AxiOwl C++ repo is explicit about the product shape. The user documentation in docs/user/README.md describes AxiOwl as a local Windows coordinator that lets supported AI provider sessions send messages to each other. The architecture reference in docs/reference/architecture-overview.md lays out the flow:

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

That is broader than a coordination protocol. AxiOwl exposes a CLI in apps/windows-desktop/src/cli.cpp, an MCP server in apps/windows-desktop/src/mcp_server.cpp, a relay-session stdio frame handler in apps/windows-desktop/src/remote_relay.cpp, and provider dispatch in apps/windows-desktop/src/provider_edges.cpp. The protocol-facing parts are entry points into a coordinator that owns runtime state and provider-specific behavior.

The top-level README.md calls the repository a monorepo with Windows desktop, Linux desktop, and reserved Linux remote targets. The Windows desktop README is more specific about current implementation status: the CLI skeleton, fixed send pipeline, create-session pipeline, TSV registry, final visible body builder, JSONL evidence log, provider edge interface, and live provider delivery for current local Windows edges are implemented. The same README also says a local always-running service is not implemented yet. That is an important product boundary: AxiOwl is a working coordinator and installer line, not a claim that every possible background service or route already exists.

The Registry Is A Product Feature, Not Just Metadata

Protocol-first designs often assume a participant already knows who it is talking to. AxiOwl cannot make that assumption. It keeps a durable local registry of sessions and nodes.

The registry model in apps/windows-desktop/src/models.hpp includes AgentRecord fields for display name, aliases, provider, provider session ID, node ID, enabled state, sendability, source, timestamps, and last error. NodeRecord tracks remote node identity, host, SSH user, SSH key path, enabled state, timestamps, and last error. apps/windows-desktop/src/app_paths.cpp places the local registry under %LOCALAPPDATA%\AxiOwl\registry, with agents.tsv and nodes.tsv.

apps/windows-desktop/src/registry.cpp does more than read and write rows. It resolves names and aliases, prefers exact session matches where appropriate, chooses the newest duplicate display-name row when needed, and resolves senders from registered session identity. The tests in apps/windows-desktop/tests/core_tests.cpp cover those details: duplicate names remain separate rows, newest sessions can win display-name lookup, manual rows are protected from blind downgrade, and prompt-like provider chat titles remain valid display names.

This is where AxiOwl diverges from a simple coordination protocol. AxiOwl is not only asking, "Can this system accept a message object?" It is asking, "Which concrete provider session should receive this, and do we have enough evidence to treat it as sendable?"

Sender Identity Is Treated As Routing State

AxiOwl also treats sender identity as something the coordinator must resolve, not something a chat should invent. The bundled Codex skill at apps/windows-desktop/extensions/codex-plugin/skills/axiowl/SKILL.md tells Codex to prefer the AxiOwl MCP tool because the tool receives Codex thread metadata. It also says not to ask the chat agent to know its own session ID.

The MCP server reinforces that boundary. In apps/windows-desktop/src/mcp_server.cpp, the initialization instructions say to use axiowl_send_message for sending and axiowl_create_agent for creating chats. They also say these typed tools require the host MCP session ID as the stable sender identity key, and that AxiOwl resolves that key to the registered visible sender name before appending reply instructions.

That is a practical coordination problem. A reply must route back to a real provider session, not a guessed display name. apps/windows-desktop/src/final_visible_body_builder.cpp builds the final visible message body with a "Message from …" header and an exact MCP tool-call instruction for replying to the resolved sender. The tests verify that the helper no longer includes shell fallback wording or manual --from instructions. That keeps replies inside the typed AxiOwl path where sender identity can be tied back to provider-owned metadata.

Receipts Are Not The Same As End-To-End Proof

One of AxiOwl's most useful differences from a protocol-only view is its receipt boundary. The user docs say accepted_by_axiowl means AxiOwl accepted the message and handed it to the delivery layer. It does not prove the target provider displayed or processed the message.

The implementation matches that wording. In apps/windows-desktop/src/message_pipeline.cpp, the pipeline validates the target and body, resolves the sender, attempts a single targeted discovery repair when a target is missing or stale, rejects non-sendable targets, records a local acceptance event, builds the final visible body, and starts a delivery-worker handoff.

The test test_send_returns_axiowl_receipt_then_starts_delivery_handoff in apps/windows-desktop/tests/core_tests.cpp makes the boundary explicit. It requires the send receipt to be accepted by AxiOwl, not accepted by the provider, and checks that the log records delivery_receipt as axiowl_only with the receipt boundary after target resolution and before delivery worker or provider work.

That is a more honest operational model than treating a successful API call as a completed conversation. AxiOwl separates:

• AxiOwl accepting the request.
• Provider delivery being attempted.
• Provider acceptance being reported.
• A recipient replying through AxiOwl MCP with correct sender identity.

The strongest proof is the last one, because it shows that the target provider received the message, acted on it, had the AxiOwl tool path available, and sent a reply with usable identity metadata.

Provider Edges Are Where Coordination Becomes Real

A generic coordination protocol can be provider-neutral. AxiOwl has to be provider-specific at the edges.

apps/windows-desktop/src/provider_edges.cpp dispatches deliver, create, and rename requests to provider modules such as Codex, VS Code native, VS Code Copilot-backed, Antigravity, Cursor, Claude Code CLI, Copilot CLI, and OpenCode CLI. The declarations in apps/windows-desktop/src/provider_modules.hpp show separate deliver/create/rename functions for these surfaces rather than one universal provider call.

That shape is intentional. The provider support matrix in docs/reference/provider-support-matrix.md does not mark a provider supported just because a config file exists. It defines the support bar as discovery, installer setup, send, provider receive, provider MCP reply, and correct provider-owned sender identity. As of that matrix, supported surfaces include Codex agents, Codex CLI, VS Code agents, Copilot through the VS Code extension path, Cursor agents, and Antigravity agents. Several CLI surfaces are still target, and remote is marked unsupported for local-provider remediation builds.

The code also reflects that current boundary. Although apps/windows-desktop/src/provider_remote.cpp and apps/windows-desktop/src/remote_relay.cpp contain SSH and stdio relay mechanics, provider_edges.cpp currently returns an explicit remote_out_of_scope result for remote delivery in this local-provider remediation build. That is the kind of implementation-state detail a coordinator must expose clearly. Silent fallback would make operators think a route existed when the current support matrix says it should not be used as local-provider fallback.

Installation Is Part Of Coordination

AxiOwl coordination starts before the first message is sent. The Windows installer is part of the product surface because provider messaging often requires MCP config, bridge extensions, provider-specific patches, discovery records, and cleanup of stale AxiOwl-owned files.

The installer docs in docs/installer/README.md say the MSI installs the local runtime under %LOCALAPPDATA%\AxiOwl, including bin\axiowl.exe, runtime directories, registry directories, logs, selected provider integration files, and provider-specific MCP or bridge pieces. The installer behavior matrix in docs/reference/installer-behavior-matrix.md emphasizes that provider checkboxes should default from discovery, unchecked provider features should not be installed or patched as collateral damage, and a successful install does not prove all message paths work.

The C++ installer contract in apps/windows-desktop/src/installer_provider_contract.cpp encodes provider-specific feature IDs, helper actions, process scopes, and config scopes. For example, Codex has plugin and MCP-related install pieces, VS Code native and Copilot-backed paths have bridge extension and MCP pieces, Cursor includes extension, MCP, patch, and discovery pieces, and remote features are remote-only. The tests in apps/windows-desktop/tests/installer_provider_contract_tests.cpp check that selected features produce only their intended coordinator actions and that unchecked provider scan rules stay scoped.

That is another practical difference from protocol-only thinking. The protocol surface may look clean, but the operator still needs the right integration installed in the right host without damaging unrelated provider state.

A Good Way To Think About The Difference

Agent coordination protocols answer interface questions:

• What is the frame or tool-call shape?
• How does a host list tools?
• How does a caller invoke a target capability?
• What fields should a message include?

AxiOwl answers runtime coordination questions:

• Which provider sessions exist on this machine?
• Which sessions are sendable right now?
• Which provider edge can reach the selected target?
• Which sender identity is real enough for replies?
• What did the installer configure or patch?
• What receipt boundary did this send reach?
• What evidence proves more than local acceptance?

Those are complementary layers. AxiOwl can expose an MCP server and still need its own registry, discovery, provider adapters, delivery worker, evidence logs, support matrix, and installer behavior. The protocol gives one entry point. AxiOwl makes the entry point operational against real provider sessions.

The Operator Value

For a developer or operator, the value is clarity. axiowl status reports the state root, registry path, node registry, evidence log, delivery log, create lifecycle log, activation file, and license state. axiowl list agents shows registered sendable targets. axiowl send --to ... --body ... enters the message pipeline. MCP tools such as axiowl_whoami, axiowl_list_agents, axiowl_send_message, and axiowl_create_agent let supported hosts call into the same coordinator without making chats invent session identity.

Most importantly, AxiOwl does not collapse all success states into one word. A local receipt, a provider handoff, a provider acceptance, and a reply through AxiOwl are different events with different evidentiary value. That distinction is not academic. It is what lets a team debug whether a failure is registry lookup, sender identity, provider installation, provider delivery, MCP availability, or reply routing.

Closing

AxiOwl should be compared to agent coordination protocols as an operational coordinator, not as a replacement for every protocol surface. It uses protocol interfaces where they fit, especially MCP and stdio-style relay frames, but the real product work is in mapping those interfaces to provider sessions, local install state, target discovery, provider edges, receipt boundaries, and evidence.

That is why the repo spends so much code on registry.cpp, message_pipeline.cpp, provider_edges.cpp, mcp_server.cpp, delivery_worker.cpp, installer contracts, and support matrices. The hard part is not only agreeing on how agents can speak. It is proving that the right installed session received the right message from the right sender and can reply through the same coordinated path.