AxiOwl Is Not a Chatbot

AxiOwl is easy to misunderstand if the only mental model is "another AI chat window." That is not what the current product is. A chatbot is where a person types a prompt and expects that same product to generate the answer. AxiOwl is a coordination layer for provider sessions that already exist. Its job is to discover those sessions, give them stable names, route messages to the right target, expose an MCP reply path, and record enough evidence to know what actually happened.

That distinction matters. If you expect AxiOwl to replace Codex, VS Code Copilot, Cursor, Antigravity, or another provider, you will look for the wrong thing. AxiOwl does not try to be the model. It sits beside provider sessions and gives them an addressable message fabric.

What AxiOwl Actually Does

The user docs state the product boundary directly: AxiOwl lets supported AI provider sessions send messages to each other through a local Windows coordinator. It is designed for local provider-to-provider messaging, not for replacing the providers themselves.

In the C++ implementation, that boundary shows up as concrete runtime pieces:

• a Windows local coordinator and registry owner;
• a CLI surface with commands such as send, create, discover, list agents, status, registry add-agent, and mcp-server;
• a TSV registry of agents and nodes;
• JSONL evidence and delivery logs;
• a final visible body builder that appends reply instructions for the receiving provider;
• provider edges for supported or targeted surfaces;
• a native MCP server that exposes typed AxiOwl tools over stdin/stdout.

None of those pieces is a general chat UI. They are routing and proof machinery.

The current Windows desktop README describes the implemented line as a 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. It also says the always-running local service is not implemented yet. The current path is the executable, the registry, provider integrations, and MCP.

The Registry Is the Address Book

A chatbot usually has one active conversation: the user and the bot. AxiOwl has a registry.

The AgentRecord model stores the fields that make a provider session addressable: display name, aliases, provider, provider session ID, node ID, enabled state, sendable state, source, first-seen time, last-seen time, last-verified time, and last error. The registry implementation reads and writes those records as TSV. On Windows, app_paths.cpp places the agent registry at:

%LOCALAPPDATA%\AxiOwl\registry\agents.tsv

There is also a node registry at:

%LOCALAPPDATA%\AxiOwl\registry\nodes.tsv

That makes AxiOwl closer to a switchboard than a chat window. A user or provider can refer to a target by a registered name. AxiOwl resolves that name to a provider session and provider edge. If the target is missing or stale, the message pipeline performs a targeted discovery attempt before failing loudly.

That is also why AxiOwl cares about sender identity. The message path is not just "send some text." The sender has to be resolved from MCP metadata, from the registry, or from explicit CLI context. If AxiOwl cannot resolve a sender, the send is rejected instead of hiding the problem.

The MCP Tools Are Operations, Not a Chatbot Persona

AxiOwl's MCP server exposes tools for provider hosts. The tool list includes axiowl_whoami, axiowl_list_agents, axiowl_send_message, axiowl_create_agent, axiowl_rename_agent, axiowl_discover, axiowl_status, node commands, registry commands, and version/status helpers.

The description for axiowl_send_message is especially important. It sends a message through AxiOwl, but success is an MCP-to-AxiOwl handoff receipt only. Provider delivery and reply are not implied by that receipt.

That is not chatbot behavior. A chatbot tends to collapse the experience into one answer bubble. AxiOwl keeps the boundaries visible:

1. The provider host calls an AxiOwl MCP tool.
2. AxiOwl resolves the sender and target.
3. AxiOwl records an accepted-by-AxiOwl receipt after target resolution.
4. AxiOwl hands work to the delivery worker.
5. The delivery worker dispatches to a provider edge.
6. A real end-to-end proof requires the target provider to reply through AxiOwl MCP with correct sender identity.

The tests enforce this separation. core_tests.cpp checks that a send can return accepted_by_axiowl while still not reporting provider acceptance. It also checks that the local receipt boundary is after target resolution and before delivery worker or provider work. In other words, a receipt is not proof that the provider displayed or processed the message.

Provider Edges Do the Delivery Work

AxiOwl routes through provider-specific edges. provider_edges.cpp dispatches delivery, create, and rename operations to providers such as Codex agents, Codex CLI, VS Code native, VS Code Copilot-backed sessions, Antigravity agents, Cursor agents, and several CLI targets. Unknown providers fail as unknown providers. Remote delivery is explicitly out of scope in the current local-provider remediation build.

That provider-specific design is another reason AxiOwl is not a chatbot. AxiOwl does not pretend every provider surface is the same. The support matrix treats each provider surface separately and defines status terms:

• supported means the current code has a provider edge and response-backed proof or active working test evidence.
• target means intended support exists or is planned, but the current implementation has not met the current test bar.
• experimental means a path exists but depends on fragile private provider behavior or patch-sensitive internals.
• unsupported means there is no current supported implementation.

The same matrix defines the support bar. A provider is not supported just because AxiOwl can write a config file or start a process. The full path must include discovery, install/config, send, provider receive, provider MCP reply, and correct sender identity.

That is a practical operating standard. It keeps AxiOwl from becoming vague middleware that claims success too early.

The Installer Wires Hosts, It Does Not Create a New AI

The Windows MSI installs the local runtime and selected provider integrations. The installer docs list the core install location under %LOCALAPPDATA%\AxiOwl, including bin\axiowl.exe, runtime directories, registry directories, logs, and selected provider integration files.

Depending on selected features, the installer may configure MCP entries, a VS Code bridge extension, a Cursor bridge extension, provider patches, CLI config, Codex plugin/skill integration, and Antigravity/Gemini MCP config. The installer provider contract tests check that provider actions are scoped to selected providers and that unchecked provider features do not leak into selected action plans.

That is integration work. It is not the installation of a new chatbot brain. AxiOwl gives existing hosts a way to discover, address, send, create, reply, and prove messages across sessions.

Why the Difference Helps Operators

The "not a chatbot" framing is not just semantics. It changes how you debug and operate the system.

If a provider does not reply, the right question is not "why did AxiOwl answer badly?" The right questions are:

• Did discovery find the target provider session?
• Is the target row sendable?
• Did the sender resolve to a real registered identity?
• Did the MCP handoff reach AxiOwl?
• Did the delivery worker start?
• Which provider edge was selected?
• Did the provider receive the final visible body?
• Did the provider reply back through AxiOwl MCP with correct identity?

AxiOwl records those boundaries in logs. app_paths.cpp defines the event log at %LOCALAPPDATA%\AxiOwl\logs\events.jsonl, the delivery log at %LOCALAPPDATA%\AxiOwl\logs\delivery.jsonl, and the create lifecycle log at %LOCALAPPDATA%\AxiOwl\logs\create-lifecycle.jsonl. These logs exist because the product is built around routing evidence, not around presenting a single conversational surface.

The final visible body builder shows the same mindset. When AxiOwl sends a message, it can prepend "Message from" information and append an exact MCP reply instruction so the receiving provider can route the answer back. The tests make sure the helper uses the MCP tool form, includes receipt correlation when available, quotes JSON safely, and does not fall back to old shell-command reply wording.

Use the Providers for Reasoning, Use AxiOwl for Coordination

The clean mental model is this:

Provider sessions think and respond.
AxiOwl discovers, names, routes, hands off, and records.

Codex agents, Codex CLI, VS Code native chat, VS Code Copilot, Cursor agents, and Antigravity agents remain the provider surfaces. AxiOwl makes those sessions reachable from each other through a local coordinator, registry, provider edges, and MCP tools.

That is why the product is useful. It lets operators and developers keep using the provider sessions they already rely on, while adding a disciplined addressing and delivery layer between them. A chatbot tries to be the conversation. AxiOwl makes conversations between provider sessions operational.

Closing

AxiOwl is not a chatbot, and that is the point. It is an agent coordination system with a C++ local runtime, a registry, a send pipeline, MCP tools, provider-specific delivery edges, and evidence logs. When it works correctly, the proof is not that AxiOwl produced a clever answer. The proof is that the right provider session received the message, replied through the registered AxiOwl path, and carried the correct sender identity back with it.