Temporary image generation instructions
Image 1 – icon / symbol: Create a detailed cartoon icon or symbolic illustration for AxiOwl article 51, "How AxiOwl Sends Messages Between Named Agents". Show an owl-themed AI message dispatcher, named agent badges, and a clear visual metaphor for this topic: AxiOwl starts with a simple user action: send this message to that agent. Style: modern SaaS cartoon, bold shapes, high contrast, polished but friendly, simple or transparent background, no readable text.
Image 2 – article image / screenshot: Create a blog hero image or product-style screenshot for AxiOwl article 51, "How AxiOwl Sends Messages Between Named Agents". Show a developer workstation or clean software interface where named AI agents exchange messages through AxiOwl. Include visual cues specific to this topic: AxiOwl starts with a simple user action: send this message to that agent. Style: polished SaaS website image, widescreen 16:9, believable fictional UI, no real credentials or real private data.
AxiOwl starts with a simple user action: send this message to that agent.
The important word is named. AxiOwl is not designed around hunting for whichever chat window happens to be visible. It is designed around known targets. An agent has a display name, provider surface, provider session id, node id, and sendable status in the local registry. When a user or provider sends a message, AxiOwl resolves the name to one of those registry rows.
That resolution step is what turns a chat window into an addressable target.
After the target is resolved, AxiOwl builds the message that will be delivered. The message is not just the user's text. AxiOwl can add visible reply instructions so the receiving agent knows how to respond back through AxiOwl. When the sender is known, the delivered body can include the sender name, run id, and receipt id.
Then AxiOwl hands the request to the provider edge for that target. A Codex session, Cursor session, VS Code chat, Claude Code CLI session, OpenCode CLI session, and remote node can require different delivery mechanics. AxiOwl keeps those mechanics at the provider edge instead of forcing every provider through one fake path.
The result is a receipt. A local receipt means AxiOwl accepted the request and started the delivery process. A provider acceptance result means the provider edge reported that it accepted the message. A reply from the target is stronger proof than either receipt.
This design keeps the human workflow simple while preserving technical detail where it matters. The user sends to a name. AxiOwl resolves that name, builds a reply-aware body, routes through the provider surface, records evidence, and waits for a response path when the provider supports one.
Named agents are the foundation of the whole system. Without names, messaging is just another form of manual window targeting. With names, AI sessions can become real participants in a coordinated workflow.