Using AxiOwl for QA and Browser Testing
QA for agent software is difficult because a successful command is not the same thing as a successful user-visible result. A tool can accept a request, a provider can return exit code 0, and the actual target chat can still fail to receive, display, or act on the message. AxiOwl is built around that distinction.
AxiOwl is not a generic replacement for Playwright, Selenium, or a browser test runner. Its practical value for QA is more specific: it gives operators a routed way to send real test instructions to named agent sessions, record evidence across delivery stages, and separate "AxiOwl accepted this request" from "the provider accepted it" and "the target actually responded." For browser-like desktop surfaces such as Antigravity Manager, the repo also contains CDP lab tooling used to probe, focus, and submit into the running application without pretending that a low-level injection is the same as a completed regression.
What AxiOwl Tests
The current AxiOwl codebase centers on provider sessions. The CLI exposes commands such as:
axiowl send --to <agent> --body <message>
axiowl send --to <agent> --stdin
axiowl create --provider <provider> --name <agent>
axiowl discover <provider|all> --json
axiowl list agents
axiowl provider smoke-test --all-local
axiowl mcp-server
axiowl mcp-self-test
Those commands are useful in QA because they test the real routing path through the registry and provider edge instead of a mocked happy path. AxiOwl discovers and stores provider sessions, resolves a human-readable target name, builds the final visible message body, hands the request to the delivery worker, and logs evidence about what happened.
The implementation supports provider routing across surfaces including Codex, Codex CLI, VS Code native sessions, VS Code Copilot-backed sessions, Antigravity, Antigravity CLI, Cursor, Cursor CLI, Claude Code CLI, Copilot CLI, and OpenCode CLI. The source tree is explicit that support varies by surface and provider. That matters for QA: a test should name the provider surface it is proving, not just the product brand.
Proof Gates Instead of Vague Passes
The testing plan in the repo sets a useful standard: do not call a provider supported until it proves required edge behavior. For each provider, AxiOwl expects proof that the edge can insert text, wake or steer the target, preserve the visible sender name, and report failure honestly.
That is a better QA model than a single "passed" line. The project separates facts such as:
AxiOwl accepted
provider accepted
target visible
target woke
reply received
The support and forensics guide makes the same point in operational language. MSI install success, accepted_by_axiowl, provider acceptance, and MCP reply receipt are separate events. Treating the first event as proof of the last one hides the exact class of bugs that agent routing systems tend to have.
This shows up directly in message_pipeline.cpp. When a request enters the pipeline, AxiOwl records an accepted stage with a note that provider delivery is not implied. After target resolution, it records route resolution. After handoff, it records whether the delivery worker handoff started or failed. The MCP tool description for axiowl_send_message also states that success is a handoff receipt only, not proof of provider delivery or reply.
For QA work, that means a useful AxiOwl test does not stop at "the command returned." It asks: did the target resolve to the intended registry row, did the selected provider edge accept the final visible body, did the target become visible, did it wake, and did the expected response arrive?
Browser-Like Testing Through CDP Lab Tools
The Antigravity work in the Linux lab shows how AxiOwl approaches browser-style surfaces. Antigravity Manager is an Electron/Chrome-based application exposed through the Chrome DevTools Protocol on a local debugging port in the lab environment. The scripts under apps/linux-desktop/axiowl-linux-x86_64/scripts/ use CDP to inspect targets, probe DOM state, focus a conversation, and submit a user turn.
For example, jetski-cdp-probe.mjs connects to the local CDP endpoint, reads /json/version, opens the browser WebSocket, and asks for Target.getTargets. jetski-cdp-dom-probe.mjs evaluates JavaScript in the selected target to find candidate message inputs and send buttons. jetski-cdp-wake-act.mjs is the more complete wake-and-act driver: it finds the Manager target, switches to the requested cascade ID, confirms that focus landed on the intended conversation, and then submits through one of the configured modes.
The script documents three modes:
hook
cdp-composer
focus-only
The default hook mode calls an application hook named __axiowlSubmitItems, avoiding composer typing and clicking. The cdp-composer mode uses CDP input events to focus the composer, insert text, and press Enter or click the send button. The focus-only mode switches the conversation without submitting a message.
That is browser testing in the AxiOwl sense: targeted verification of a live provider UI surface, with guardrails. The script checks that the active cascade matches the requested cascade before submitting, and aborts if focus does not land on the target. The regression report also records a permanent operator rule: do not close, kill, or restart the application just to run a test; if CDP or hooks are unavailable, stop and report.
Why This Helps QA
AxiOwl makes QA practical for multi-agent workflows because it tests the thing operators actually care about: whether a named agent session can be reached through its real provider surface and produce observable behavior.
A regression can be written as a routed instruction:
axiowl send --to "axiowl claude test agent" --body "Reply with exactly: QA_ROUTE_OK"
Or, for larger prompts and browser-testing instructions, via stdin:
axiowl send --to "frontend qa agent" --stdin
The same pattern works for tests that ask an agent to inspect a page, run a browser check, or report a precise status. AxiOwl's job is not to replace the browser automation inside that receiving agent. Its job is to route the instruction to the right session, preserve sender identity, and provide receipts and logs that show where the workflow did or did not progress.
This becomes especially useful when QA spans several providers. The provider support chart separates brands from surfaces: agents windows, editors, CLIs, and extensions are distinct. The handoff documentation makes the same distinction for Copilot CLI versus VS Code Copilot-backed sessions. A QA failure in one surface should not be misdiagnosed as a failure of the entire brand.
What To Capture In A Real Test
A good AxiOwl QA run should capture the same fields the repo's live provider proof template asks for:
provider
target agent
message id
exact body
method used
expected visible effect
expected wake effect
receipt
provider evidence
result
For browser-like Antigravity runs, the regression report goes further by separating delivery methods, actuation methods, and repeatability runs. Delivery methods answer how the message was injected. Actuation methods answer how a user turn was triggered. Regression runs answer whether a chosen path repeats on the same target. Keeping those dimensions separate prevents a common QA mistake: calling five repeats of one method "five methods."
The forensics guide also points operators to the useful evidence locations: AxiOwl logs, registry state, runtime state, provider stdout/stderr, bridge output channels, and relevant provider session files when safe. A failed test should be written up with expected behavior, actual behavior, logs reviewed, timeline, evidence, root cause, non-causes ruled out, fix options, selected fix, and regression tests.
The Practical Pattern
For a QA operator, the workflow is straightforward:
- Discover or register the target session with AxiOwl.
- List agents and confirm the target is sendable.
- Send a precise test instruction with a unique expected response or proof artifact.
- Check the AxiOwl receipt and delivery logs.
- Check provider-visible evidence.
- Confirm whether the target became visible, woke, acted, and replied.
- Record the result without collapsing the stages.
That last step is the most important. AxiOwl's design makes failures more diagnosable because it refuses to treat the routing layer, provider layer, UI layer, and reply layer as one black box.
Closing
Using AxiOwl for QA and browser testing means using it as a control plane for real agent sessions, not as a generic click recorder. It can route browser-testing work to the right agent, prove provider-specific delivery paths, and support CDP-based lab checks for browser-like applications such as Antigravity Manager. The result is a QA process that is concrete, repeatable, and honest about exactly which part of the chain passed.