How to Confirm Which Agents Are Active

When an AxiOwl operator asks which agents are active, the practical question is not just "what names are saved somewhere?" The real question is: which provider sessions does AxiOwl currently consider usable as message targets, and what evidence supports that decision?

AxiOwl answers that through a durable local registry, provider discovery, and delivery proof. The quick command is axiowl list agents, but the strongest operational read comes from understanding what that command filters in, what discovery refreshes, and what a successful reply proves.

Start With The Active Agent List

The user-facing command is:

axiowl list agents

In the current Windows desktop implementation, this command loads AxiOwl's registry and prints only rows that are both enabled and sendable. Each printed line uses this shape:

Display name | provider=<provider> | node=<node>

If there are no registry rows at all, AxiOwl prints:

No agents are registered.
Registry: <registry path>

That distinction matters. An empty registry means AxiOwl has no saved agent rows. A silent or surprisingly short active list can also mean there are rows that exist but are not currently marked sendable, or are disabled. The active list is intentionally narrower than a raw file dump.

Know What AxiOwl Is Filtering

AxiOwl's registry model stores one row per reachable provider session or agent. The architecture docs identify important row fields such as display_name, aliases, provider, provider_session_id, node_id, sendable, source, last_seen_at, last_verified_at, and last_error.

The registry file format in the current implementation is TSV with this header:

agent_id	display_name	aliases	provider	provider_session_id	node_id	enabled	sendable	source	first_seen_at	last_seen_at	last_verified_at	last_error

For routine use, axiowl list agents is the safer view because it filters to enabled, sendable rows. For troubleshooting, the registry fields tell you why a row may or may not appear:

• enabled says whether the row is available for lookup.
• sendable says whether AxiOwl believes the row can currently receive messages.
• provider_session_id is the provider-owned session identity, stronger than a display name.
• node_id separates local and remote identity.
• source explains where the row came from, such as discovery, manual registration, or provider-specific integration.
• last_seen_at shows recent discovery or registration evidence.
• last_verified_at records stronger verification timing.
• last_error preserves the most recent known problem.

If a name is missing from axiowl list agents, do not assume the provider is gone. Check whether the row exists but is disabled, not sendable, stale, or carrying an error.

Refresh Discovery Before Trusting The List

Provider sessions move. Users rename chats, restart tools, close windows, change workspaces, and install or remove provider integrations. AxiOwl is built with provider-specific discovery modules so the registry can be refreshed from current provider state.

The command shape is:

axiowl discover <provider> [--target <agent>] [--json]

The CLI usage lists provider options including codex, codex-cli, vscode-native, vscode-copilot, copilot-cli, antigravity, antigravity-cli, cursor, cursor-cli, claude-code-cli, opencode-cli, and all.

For a broad refresh, use:

axiowl discover all
axiowl list agents

For a specific missing or questionable target, use targeted discovery:

axiowl discover codex --target "Target chat name"

When --json is used, discovery emits structured row data including display_name, provider, provider_session_id, node_id, status, sendable, has_enrollment_proof, source, evidence, last_seen_at, and last_error, followed by a discovery summary. That is useful when you need to compare current discovery evidence with the registry row AxiOwl will later use for delivery.

Interpret "Active" As A Ladder Of Evidence

AxiOwl deliberately separates levels of proof. The support docs warn not to treat one event as proof of a later event. That same rule applies when deciding whether an agent is active.

A reasonable evidence ladder is:

1. The row exists in the registry.
2. Discovery recently saw the provider session.
3. The row is enabled and sendable, so it appears in axiowl list agents.
4. A send to that row is accepted by AxiOwl.
5. The provider edge reports that delivery was accepted.
6. The target provider replies through AxiOwl MCP with correct provider-owned sender identity.

Step 3 is the normal answer to "which agents can I target right now?" Step 6 is the stronger answer to "which agent path has actually worked end to end?"

This distinction is built into the product. A send receipt of accepted_by_axiowl means AxiOwl accepted the request and handed it to the delivery layer. It does not prove that the provider displayed, processed, or replied to the message. A response over MCP proves much more: the target received the message, had AxiOwl MCP available, sent a reply, and carried enough provider/session metadata for AxiOwl to identify the sender.

Use Status For File Locations And Counts

The broader status command is:

axiowl status

The current implementation prints the AxiOwl version, state root, registry path, node registry path, evidence log path, delivery log path, create lifecycle log path, installed executable information, activation state, runtime role, registered agent count, and registered node count.

Use axiowl status when you need to know which registry file is being read or where to collect logs. Use axiowl list agents when you want the filtered active target list.

When The Active List Looks Wrong

If an agent should be active but is missing, work through the concrete state instead of guessing:

axiowl status
axiowl discover all --json
axiowl list agents

Then inspect the registry and logs that axiowl status reports. The support docs call out these fields for bad discovery cases: provider session ids, display names and aliases, sendable, source, last_seen_at, last_verified_at, and last_error.

Common causes include stale registry rows, reused old session names, provider workspace folders that no longer exist, skipped provider discovery because the provider was not selected during install, or a provider-specific session format changing under AxiOwl.

For a target that appears active but does not behave correctly, send-path evidence matters. AxiOwl records evidence and delivery logs, and the CLI distinguishes "accepted by AxiOwl" from provider delivery status when a provider path reports it explicitly. That prevents a clean local handoff from being mistaken for a real target response.

Why AxiOwl Uses This Model

Agent names are convenient for people, but they are weak identifiers. Provider-owned session ids, node ids, discovery source, and proof timestamps are better operational facts. AxiOwl's registry lookup code prefers sendable rows and uses recency fields when multiple candidates could match. Discovery can repair stale or missing registry state, but the developer docs are explicit that discovery should not silently convert stale rows into sendable rows or hide provider delivery failures.

That is why the active agent check is a workflow, not just a name list:

axiowl discover all
axiowl list agents
axiowl status

For everyday routing, axiowl list agents tells you which enabled, sendable targets AxiOwl currently exposes. For operations and debugging, discovery output, registry fields, and MCP replies tell you whether the target is merely listed, recently found, sendable, or proven end to end.

The clean habit is simple: refresh discovery when state may have changed, read the active list for usable targets, and treat a provider reply through AxiOwl MCP as the final confirmation that the agent path is genuinely alive.