AxiOwl Docs
AxiOwl is local Windows software for AI provider messaging and provider normalization. It installs provider integrations, discovers provider sessions, gives different provider surfaces a shared vocabulary, sends messages to those sessions, and lets providers reply back through AxiOwl MCP with sender identity.
Plain English version: AxiOwl is a local switchboard and translation layer for AI work sessions. It helps one provider session talk to another while making different provider tools easier to name, test, compare, and diagnose.
Start Here
New readers should start with the plain-English workflow pages before jumping into the matrices:
| Why page | Why it matters |
|---|---|
| Why Use AxiOwl | Explains the problem AxiOwl solves. |
| Who AxiOwl Is For | Describes the people and workflows that benefit. |
| A Workflow Story | Shows how AxiOwl fits into everyday work. |
| Why Download And Install It | Explains what installing gives you. |
| When Not To Use AxiOwl | Sets honest boundaries. |
| Practical Examples | Shows real use cases. |
Then move to the beginner pages:
| Beginner page | Why it matters |
|---|---|
| What AxiOwl Is | Establishes the switchboard mental model. |
| Install And First Run | Explains what the MSI should do and what install success means. |
| Send Your First Message | Shows the basic send/receipt/reply loop. |
| How To Read Status And Logs | Helps users find evidence instead of guessing. |
After that, use the source-of-truth docs:
| Document | Purpose |
|---|---|
| Architecture Overview | How AxiOwl is structured and how messages move through the system. |
| Provider Support Matrix | Which provider surfaces are supported, target, experimental, unsupported, or removed. |
| Installer Behavior Matrix | What the MSI installs, patches, configures, removes, and avoids. |
| Release Validation Checklist | Required release and QA gates. |
Audience Guides
| Audience | Guide |
|---|---|
| Users | User Docs |
| Installer operators | Installer Docs |
| Provider-specific work | Provider Docs |
| Developers | Developer Docs |
| Support and diagnosis | Support / Forensics |
| Release and QA | Release / QA |
| Security and trust | Security / Trust |
Concept Guides
| Concept | Guide |
|---|---|
| Provider surfaces | Provider Surfaces |
| Normalization layer | AxiOwl As A Normalization Layer |
| Support status words | Supported, Target, Experimental, Unsupported |
| Receipts and proof | Receipts Versus Proof |
| MCP identity | MCP And Metadata |
| Discovery and registry | Discovery And Registry |
| Installer checkboxes | Installer Checkboxes |
| Local and remote | Local Versus Remote |
The One Rule To Remember
An AxiOwl receipt means AxiOwl accepted a request. It does not prove the target provider received the message. The strongest normal proof is a response from the provider over AxiOwl MCP with the correct sender identity.