AxiOwl Is for Multi-Agent Operations, Not Demo Theater

AxiOwl is built around a plain operating problem: real provider sessions need to find each other, address each other, send work to the right target, and prove what happened. That is different from a staged demo where two chat windows appear to pass a message once. A demo can stop at the exciting moment. Operations cannot. Operations needs names, session IDs, sender identity, receipts, logs, provider-specific delivery, and a clear answer when something is not actually supported.

The current AxiOwl C++ implementation is a local Windows coordinator for provider-to-provider messaging. It exposes both a CLI and an MCP server, records sessions in a durable local registry, discovers provider sessions, dispatches delivery through provider-specific edges, and writes evidence as the message moves through the system. The code treats "AxiOwl accepted this" and "the provider received and replied" as separate facts. That boundary is the difference between operational software and demo theater.

Sources read

• C:\Users\kjhgf\OneDrive\Documents\New project\axiowl-blog-production-instructions.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\README.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\README.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\reference\architecture-overview.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\reference\provider-support-matrix.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\reference\installer-behavior-matrix.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\reference\release-validation-checklist.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\security\trust-boundaries.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\user\README.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\support\forensics.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\cli.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\mcp_server.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\message_pipeline.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\registry.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\discovery.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\provider_edges.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\delivery_worker.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\evidence_log.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\provider_codex.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\provider_cursor.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\provider_vscode_native.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\tests\core_tests.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\tests\mcp_conformance.ps1

The product shape is operational

The AxiOwl command surface is not just one "send message" shortcut. The CLI usage in cli.cpp includes send, create, rename, discover, list agents, doctor inventory, provider smoke-test, node registration commands, registry commands, mcp-server, mcp-self-test, delivery-worker, relay-session, license, and status. That shape matters. It means the system is designed to manage provider sessions over time, not only to push a single string into a single window.

The architecture overview describes the flow as:

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 flow is visible in the code. MessagePipeline::send creates a message ID, resolves the sender, resolves the target from the registry, runs one targeted discovery repair when the target is stale or missing, rejects known-but-not-sendable targets, builds the final visible message body, and hands provider delivery to the background delivery worker. It writes delivery stages and evidence along the way.

This is the work a real multi-agent operations layer has to do. It cannot assume that a pretty display name still points to the right chat. It cannot assume that a stale provider path is safe. It cannot assume that a CLI session has valid metadata because a config file exists. It has to prove enough to route the message and be honest about the remaining proof boundary.

A registry is not a prop

AxiOwl's local registry is one of the clearest signs that the product is built for operations. A registry row stores fields such as 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 implementation serializes those records as TSV under the AxiOwl state area, and lookup logic prefers exact session matches over display-name matches while also preferring newer rows when duplicate names exist.

That is not a cosmetic detail. Provider sessions drift. Two chats can reuse the same title. A provider can rename a conversation. A stale row can look plausible but no longer be safe to address. The tests cover these cases: duplicate names keep both sessions, exact session lookup wins over recency, manual rows are enriched without being overwritten, and weak discovery evidence does not create a sendable registry row.

The discovery merge code is especially conservative for Codex-style local provider rows. Evidence-only rows can be counted and logged without being enrolled as sendable. A targeted Codex row with stronger IPC owner proof can enroll. Manual rows keep their display names and source while accepting useful aliases and timestamps. That is operational behavior: collect evidence, improve the registry, but do not silently turn uncertainty into routable state.

The receipt boundary is explicit

AxiOwl does not pretend that local acceptance equals end-to-end success. The documentation and tests both draw the same line:

• accepted_by_axiowl means AxiOwl accepted and validated the request and handed it to the delivery layer.
• Provider acceptance means the provider edge reported that the provider accepted the message.
• A provider reply over AxiOwl MCP is the strongest proof, because it shows that the target received the message, acted on it, and replied with provider-owned sender identity.

The implementation follows that rule. MessagePipeline::send sets accepted_by_axiowl, marks the state as accepted_by_axiowl, and records axiowl_receipt_only after target resolution but before provider delivery proof. A core test asserts that this receipt must not report provider acceptance, must log delivery_receipt as axiowl_only, and must not wait for a provider result before returning to the sender.

The MCP server says the same thing in its tool description for axiowl_send_message: success is an MCP-to-AxiOwl handoff receipt only; provider delivery and reply are not implied. That wording matters because it prevents a common demo mistake. In a demo, "the send command returned" can look like success. In operations, that is just one event in a longer chain.

Sender identity is part of the system, not a prompt trick

Multi-agent operations breaks down quickly if replies cannot route back to the real sender. AxiOwl treats sender identity as a first-class requirement.

For MCP sends, the server resolves identity from provider/session metadata. The code handles provider-specific metadata shapes for Antigravity, Cursor, Claude Code CLI, Copilot CLI, OpenCode CLI, VS Code native sessions, VS Code Copilot session state, Codex threads, and Codex CLI registry records. When the MCP host does not provide usable session metadata, axiowl_send_message refuses to launch a no-session send. It does not ask the model to invent a session ID. It does not rely on a display name alone when the provider should be able to supply stronger metadata.

When identity is usable, the MCP server registers the sender in the AxiOwl registry using registry add-agent with provider, session, node, source, raw metadata, and an optional sender address. It then calls the CLI send path with --from set to the provider-owned sender address or session ID. The visible message body asks the receiving provider to reply with the typed AxiOwl MCP tool call, not with a hand-built shell command. Tests specifically prevent old fallback wording from returning, including raw axiowl send reply instructions and manual --from patterns.

That design reflects the product goal: provider sessions should participate through AxiOwl as identifiable senders and receivers, not as anonymous text boxes.

Provider support has a bar

AxiOwl's provider matrix separates supported, target, experimental, unsupported, and removed surfaces. Current supported surfaces include Codex agents, Codex CLI, VS Code native, VS Code Copilot-backed sessions, Cursor agents, and Antigravity agents. Several CLI surfaces have code paths or historical evidence but remain target surfaces until they meet the current metadata and response proof bar. Cursor CLI is marked unsupported in the current matrix. Remote is explicitly unsupported for local-provider remediation builds and must not hide local delivery failures.

The support bar is concrete:

1. Discovery works.
2. The installer installs only the required integration pieces.
3. AxiOwl can send to a named provider session.
4. The provider receives the message.
5. The provider replies through AxiOwl MCP.
6. The reply carries correct provider-owned sender identity.

That is a useful standard because it keeps the product honest. A config file is not support. A discovered session file is not support. A local acceptance receipt is not support. Support means the full path works and the identity on the way back is correct.

Provider edges are real boundaries

The provider dispatch table in provider_edges.cpp routes delivery, create, and rename operations to provider-specific implementations. Codex, Codex CLI, VS Code native, VS Code Copilot-backed, Antigravity, Antigravity CLI, Cursor, Cursor CLI, Claude Code CLI, Copilot CLI, OpenCode CLI, and remote all have explicit handling. Unknown providers fail with an unknown-provider result. Remote delivery returns an explicit out-of-scope result in the local build.

The specific provider implementations reinforce the same pattern. Codex desktop delivery checks for the target thread, probes IPC owner state, records owner evidence, and reports accepted provider state only when the desktop IPC send path succeeds. Cursor delivery uses bridge command files, result files, patch health checks, command watcher state, and a fallback trigger path; the evidence records command IDs, bridge IDs, result paths, workspace details, and whether the watcher path was available. VS Code native delivery uses an AxiOwl bridge registry, command/result files, bridge capability checks, exact session IDs, and verification states for create and rename operations.

These details are not marketing decoration. They are the connective tissue required to operate across providers that expose different surfaces, different session metadata, and different failure modes.

Installation is selected-feature work

The installer behavior matrix also rejects demo thinking. The MSI installs one AxiOwl runtime, but each provider feature is treated like a separate install unit. Provider checkboxes should default from discovery rather than stale assumptions. Unchecked provider features should not be installed, patched, closed, restarted, or removed as collateral damage. Selected provider work should fail loudly when it cannot be installed safely.

That is the right model for a local coordinator that touches provider integrations. AxiOwl may write its own runtime, manifest, logs, registry, runtime files, selected MCP configs, selected bridge extension files, selected patches, and selected AxiOwl-owned config entries. It should not modify unrelated provider extensions, auth tokens, unrelated settings, unrelated workspace files, unchecked provider surfaces, or remote configuration unless remote is explicitly selected.

The release checklist applies the same discipline after installation. A successful MSI install proves selected install actions completed. It does not prove provider message paths. Release validation still requires discovery, registry checks, fresh/current target chats, send/receive tests, provider MCP replies, correct run IDs, correct sender identity, CLI provider tests, and uninstall/reinstall validation.

What operators get from this approach

For operators, the practical value is not "agents can chat." The value is that the system records enough state to make failures inspectable.

If a message does not get through, the support docs tell operators to separate MSI install success, AxiOwl acceptance, provider acceptance, and MCP reply receipt. Logs live under %LOCALAPPDATA%\AxiOwl\logs; registry data lives under %LOCALAPPDATA%\AxiOwl\registry; runtime handoff files live under %LOCALAPPDATA%\AxiOwl\runtime. For a bad discovery case, the operator checks provider session IDs, display names, aliases, sendable state, source, last seen time, last verified time, and last error. For missing MCP tools, the operator checks provider restart state, MCP config location, executable path, provider startup, and whether the MCP server received metadata.

Those are boring details in the best possible sense. They are the details that make the system usable after the demo, when a real provider app updates, a session is stale, a bridge extension did not activate, a patch is unhealthy, or a CLI provider is authenticated but still lacks final metadata proof.

The point

AxiOwl is for multi-agent operations because it models the actual operating surface: local provider sessions, durable registry records, provider-specific delivery edges, selected installer work, typed MCP tools, sender identity, logs, receipts, and proof levels. It does not flatten that into a single success message.

That discipline is what makes AxiOwl useful. A local handoff receipt is useful when it is labeled as a handoff receipt. Discovery is useful when evidence-only rows are not promoted into sendable targets. A provider integration is useful when it has response-backed proof and correct identity. A failure is useful when it is loud, logged, and specific enough to fix.

That is the product line between multi-agent operations and demo theater.

Image prompt:

Create a polished graphic image related to: multi-agent operations with verifiable routing and evidence boundaries.

Subject: a central compact local coordinator device on a technical workbench connected by clean cable paths to several distinct terminal-like panels, with small receipt cards, log sheets, and route indicators arranged around it; no readable symbols or labels.
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.