How to Ask One Agent to Report Back to Another Agent

The useful version of agent-to-agent messaging is not just "send this prompt over there." It is "send this prompt to that specific agent, and make the answer come back through the same routing system with a sender identity AxiOwl can verify." AxiOwl is built around that distinction. A handoff receipt is useful, but a real report-back loop is proven only when the receiving provider replies through AxiOwl MCP and AxiOwl can identify which provider session sent the reply.

That matters because AxiOwl is coordinating real provider sessions. Its user docs describe a local Windows coordinator that discovers provider sessions, records them in a local registry, sends messages to selected provider sessions, exposes an MCP tool for replies, and records receipts, logs, and delivery evidence. The target is not a vague assistant. It is a registered agent row with a provider, a provider session id, a node id, aliases, and sendable state.

The Basic Shape

At the CLI level, the ordinary send form is:

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

For longer instructions, use stdin:

@'
Please inspect the latest test output.
Report your findings back to "Coordinator Agent" through AxiOwl.
'@ | axiowl send --to "Worker Agent" --stdin

That is enough to ask a worker agent to do something. It is not, by itself, proof that the worker received the message, processed it, and replied. The current CLI output makes that boundary explicit: an accepted_by_axiowl handoff means AxiOwl accepted the MCP or CLI request and handed it to the delivery layer. Provider wake-up, provider delivery, and provider reply are separate events.

The report-back instruction should therefore tell the receiving agent exactly how to answer: use the AxiOwl MCP send tool, not a hand-built command string.

Ask for an MCP Reply, Not a Raw Shell Command

A good report-back request is explicit about the return target and the reply path:

Please complete the requested check, then report back to "Coordinator Agent" using the AxiOwl MCP tool `axiowl_send_message`.

Send a concise result with:
- status
- what you checked
- any blocker or evidence path

Do not construct raw `axiowl send` arguments yourself. Use the AxiOwl send tool exposed in your provider session.

That wording follows the MCP server's own instructions. In the current implementation, the AxiOwl MCP server exposes axiowl_send_message with to and body arguments. Its tool description says success is an MCP-to-AxiOwl handoff receipt only, and the server initialization instructions tell provider sessions to use axiowl_send_message for sending. The same instructions warn providers not to construct raw send, create, or relay argv and not to provide --from manually.

That is not just a style preference. The MCP path carries host session identity metadata. AxiOwl uses that stable sender identity key to resolve the registered visible sender before it appends reply instructions. The developer docs state the sender identity order plainly: provider-owned MCP metadata first, then explicit provider session id, then explicit sender address or alias, then targeted discovery repair. Guessing from a display name is not the goal.

When to Use --from

There are two different cases.

If a provider session is replying from inside its own AxiOwl MCP integration, it should use axiowl_send_message and let the host-provided identity travel with the tool call. The receiving agent should not invent its own session id, and it should not manually add a --from value.

If an operator is starting a CLI-only test from a shell, there may be no provider host metadata attached to that command. In that case, an explicit sender can be useful:

@'
Run the smoke check and report the result back to "Coordinator Agent" through AxiOwl MCP.
'@ | axiowl send --to "Worker Agent" --from "Coordinator Agent" --stdin

The CLI supports --from and --from-node on axiowl send, and it also requires sender identity for raw CLI create commands that include an initial message. That protects the reply loop from starting with an anonymous sender. For normal provider-to-provider replies, though, the MCP tool path is the cleaner path because it carries provider/session identity metadata rather than relying on a human-supplied sender label.

Check the Registry First

Before asking one agent to report back to another, make sure both names are actually sendable:

axiowl list agents

The registry is durable local state, not a temporary cache. The developer docs describe it as the mapping from names and aliases to provider sessions. A row should not be treated as sendable unless discovery or direct proof justifies it.

If the target is missing, discovery is the next step:

axiowl discover all

The exact provider support depends on the current support matrix. As of the source material reviewed for this draft, supported response-backed surfaces include Codex agents, Codex CLI, VS Code native agents, VS Code Copilot-backed sessions, Cursor agents, and Antigravity agents. Several CLI surfaces are targets rather than fully supported, and remote is listed as unsupported in the local-provider support matrix. That status matters when designing a report-back workflow: choose provider surfaces that can actually receive a message and reply through AxiOwl MCP with correct sender identity.

What a Good Report-Back Prompt Includes

A practical operator prompt should name the return agent, define the expected payload, and identify the required return channel:

You are receiving this through AxiOwl.

Task:
Check whether the local build command completes.

Report back to:
"Coordinator Agent"

Return channel:
Use the AxiOwl MCP tool `axiowl_send_message`.

Reply body:
1. PASS or FAIL
2. Command checked
3. Important output or error summary
4. File path or log path if relevant

Do not send the answer only in this chat. The report is complete only after it is sent back through AxiOwl.

That last sentence is important. A provider can visibly answer in its own chat, but that is not the same thing as an AxiOwl round trip. The support docs separate accepted_by_axiowl, provider accepted, and MCP reply received as different events. They explicitly warn not to treat an earlier event as proof of a later one.

How to Read the Result

When the initial send succeeds, expect a handoff receipt with a message id and delivery state. Treat that as the beginning of the workflow, not the end.

For end-to-end proof, look for the returning message from the worker agent through AxiOwl. The user docs define the stronger proof chain this way: AxiOwl accepted the request, the provider received the message, the provider had AxiOwl MCP available, the provider sent a reply through AxiOwl, and AxiOwl could identify the provider session that replied.

If the reply does not arrive, collect the right evidence:

%LOCALAPPDATA%\AxiOwl\logs
%LOCALAPPDATA%\AxiOwl\registry
%LOCALAPPDATA%\AxiOwl\runtime

Depending on the provider, also check the provider bridge output channel, provider CLI stdout or stderr, and relevant session files when safe. Missing MCP tools usually mean the provider session was not restarted after install, the MCP config is not visible to that provider, the axiowl.exe mcp-server path is wrong, or the provider did not pass usable metadata.

A Small Pattern That Scales

The operator pattern is simple:

1. Use axiowl list agents to confirm both agents are registered and sendable.
2. Send the worker a concrete task with axiowl send --to ....
3. Tell the worker to report back to the coordinator using axiowl_send_message.
4. Treat the first receipt as a handoff only.
5. Treat the MCP reply with correct sender identity as the real completion signal.

This is the difference between message dispatch and coordinated agent work. AxiOwl's registry, MCP server, sender identity rules, and evidence logs are all there to make that difference visible. When one agent reports back to another through the typed AxiOwl MCP tool, the result is not just a chat transcript. It is a routed exchange with a named target, a named sender, and a traceable delivery boundary.