What AxiOwl Agents Should Not Be Allowed to Do

AxiOwl is built around a simple but important idea: AI provider sessions can send messages to each other, but they should not be given broad, implicit control over the user's machine, provider accounts, or routing state. A useful agent network is not one where every agent can do anything. It is one where every message, sender, target, install action, and provider mutation has a bounded path and a visible reason.

That distinction matters because AxiOwl sits between real provider sessions. The Windows desktop app exposes a CLI and MCP server, keeps a durable local registry of provider sessions, discovers active sessions, and delivers messages through provider-specific edges. It is a coordinator, not a replacement for Codex, Cursor, VS Code, Antigravity, Claude Code, OpenCode, or Copilot. Its job is to route work between known surfaces without letting one integration accidentally become a general-purpose operator.

Agents Should Not Invent Their Own Identity

The first thing an AxiOwl agent should not be allowed to do is pretend to be someone else.

In the AxiOwl MCP path, sender identity is not casual text in a prompt. The architecture docs state that AxiOwl must know who is sending, and that MCP sender identity must come from provider MCP metadata or a provider patch that supplies metadata programmatically. The implementation follows that rule. In mcp_server.cpp, AxiOwl resolves host metadata into a session identity. If the host does not provide usable session metadata, AxiOwl refuses to launch a no-session send or create a no-session body.

That refusal is intentional. A reply must route back to a real provider session, not to a guessed display name, a stale path, or a value the model typed into its own message. The MCP tool instructions also tell providers to use typed tools such as axiowl_send_message and axiowl_create_agent, and not to construct raw send or create argv or provide --from manually.

The practical rule is: an agent may send as itself through the identity that the provider supplies. It should not be allowed to self-assign a sender name, forge a session ID, or route a reply through an identity AxiOwl cannot verify.

Agents Should Not Treat Receipts as Delivery Proof

AxiOwl has a clear receipt boundary. A successful handoff to AxiOwl is not the same thing as proof that the provider received, displayed, processed, and replied to the message.

The user docs define accepted_by_axiowl as a local acceptance and delivery-layer handoff. The stronger proof is a provider reply through AxiOwl MCP with correct sender identity. The message pipeline uses the same distinction. It can mark a request accepted_by_axiowl after target resolution and before the delivery worker or provider has completed the path. Delivery proof is a later stage.

An agent should therefore not be allowed to say "the other provider got it" merely because AxiOwl accepted the request. That would collapse a useful diagnostic boundary. Operators need to know whether they are looking at a request validation success, a delivery worker handoff, provider acceptance, or a full response-backed round trip.

This is why the provider support matrix sets a high bar for "supported." A provider is not supported just because AxiOwl can write a config file or start a process. The current bar includes discovery, install/config, send, provider receive, provider MCP reply, and correct provider-owned sender identity.

Agents Should Not Route to Unknown or Unsuitable Targets

AxiOwl keeps a local registry of provider sessions, aliases, providers, provider session IDs, node IDs, sendability, discovery source, and error state. When a target is missing or stale, the message pipeline performs one targeted discovery repair. If it still cannot find a sendable exact target row, it rejects the send with an explicit error.

That behavior is a boundary. An agent should not be allowed to route to a vague target, silently choose a nearby match, or continue when the registry only has evidence but no sendable exact row. A wrong delivery can be worse than a failed delivery, especially when multiple provider sessions are open.

The same applies to sender identity. The pipeline attempts targeted repair for certain unresolved sender cases, but if the sender still cannot be resolved, it rejects the send. That keeps AxiOwl from turning missing identity into guessed identity.

Agents Should Not Use Remote Fallback to Hide Local Failure

Remote routing is another place where restraint matters. The current provider matrix marks remote as unsupported for local-provider remediation builds. The remote provider page says remote should not be used as a fallback to hide local provider failures, and the installer behavior matrix says remote features may exist but should be unchecked by default.

That is a concrete product boundary. If local Cursor, VS Code, Codex, or another provider path is broken, AxiOwl should not quietly reroute through remote infrastructure and call the task solved. That would make debugging harder and could change the operational trust model without the user noticing.

Remote work needs its own explicit contract and validation. Until then, an agent should not be allowed to use remote routing as a silent escape hatch.

Agents Should Not Touch Unselected Provider Integrations

The installer documentation is especially clear about what AxiOwl agents and helper actions should not do. The Windows MSI installs the AxiOwl runtime and selected provider integrations, but each provider checkbox should behave like a separate feature.

Unchecked provider features should not be installed, patched, closed, restarted, or uninstalled as collateral damage. The behavior matrix also says the installer should not remove unrelated provider files, user chats, user auth tokens, unrelated extensions, or unrelated settings.

The tests reinforce this. installer_provider_contract_tests.cpp checks that unchecked Codex does not leak into selected features, that remote is unchecked by default, that unknown providers are validation errors, and that coordinator actions are selected-only. installer_robustness_guard_tests.cpp checks for selected-only conditions in MSI custom actions and rejects provider payloads that leak into the always-installed payload feature.

For operators, this means AxiOwl should not let an agent or installer helper treat "provider discovered on disk" as permission to mutate it. Discovery can inform a checkbox default. Selection authorizes work. Those are different steps.

Agents Should Not Patch First and Explain Later

Some provider integrations are patch-sensitive. The support matrix calls Cursor private internals patch-sensitive, and the installer docs note that VS Code and Cursor integrations can require patching private provider implementation details.

The repo's VS Code install planning files describe a defensive model: confirm selected-provider intent, classify the discovered target, fail before mutation when targets are ambiguous, run through a simulator, write evidence, use rollback, and produce loud blocked or verification failure states. The transaction narrative says helpers should refuse to install, patch, configure, close, or remove VS Code state unless selected intent explicitly authorizes that action. It also says process closure must be tied to a selected action that requires closure, and discovery alone must not close VS Code.

That is the right posture for agentic software. An agent should not be allowed to patch private provider files just because it found a familiar-looking path. It should not close editor processes merely because discovery ran. It should not mutate unsupported or ambiguous builds and hope the result works. AxiOwl's safer model is plan, authorize, simulate, mutate only inside declared scope, verify, and leave evidence.

Agents Should Not Hide Failure Behind Silent Fallbacks

AxiOwl's documentation repeatedly favors loud failure over silent fallback. Unsupported provider states, missing metadata, absent targets, unsafe installer conditions, and unverified provider paths are supposed to be visible. The VS Code patch reasoner describes unsupported builds as quarantined for VS Code only, without breaking unrelated providers. The transaction notes say partial mutation, failed rollback, unsupported state, and stale hash mismatch should be loud results with evidence.

This is not just defensive programming. It is operational usability. When an agent network fails quietly, the operator loses the ability to tell whether the problem is identity, discovery, registry state, provider auth, a stale extension, a private provider patch, or an actual delivery failure.

Clear refusal is a feature. "No usable session ID metadata" is better than a fake sender. "Target is not in registry after targeted discovery" is better than a guessed target. "Selected provider unsupported" is better than unbounded mutation.

What Agents Should Be Allowed to Do Instead

The restricted model still leaves plenty of useful behavior.

An AxiOwl agent should be allowed to send a message to a named, sendable provider session using the common CLI form:

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

Provider sessions should also be allowed to reply through MCP using axiowl_send_message, because that path can carry provider/session metadata. Agents should be able to trigger discovery repair where AxiOwl has a targeted mechanism for it. Installer helpers should be able to install, patch, configure, and verify selected provider features. Logs and registry records should be available for diagnosis under the documented AxiOwl state locations.

The important point is that these actions are bounded. The sender is resolved. The target is resolved. The selected provider owns the files being touched. The receipt boundary is named. Unsupported states are visible.

Boundaries Make Agent Coordination Usable

AxiOwl is most useful when it lets different AI provider sessions cooperate without blurring ownership. The registry, MCP identity checks, provider support matrix, installer feature contracts, and delivery logs all point in the same direction: agents should be powerful inside explicit boundaries and conservative outside them.

The short version is simple. AxiOwl agents should not invent identity, overstate delivery proof, guess targets, use remote fallback to mask local failure, touch unselected providers, mutate ambiguous private files, remove user data, or hide failure. They should send through verified paths, preserve provider ownership, and leave enough evidence for an operator to understand what happened.

That is how agent-to-agent messaging becomes operational infrastructure instead of a pile of side effects.