AxiOwl Helps Agents Work Without Sharing One Giant Context

AxiOwl Helps Agents Work Without Sharing One Giant Context

Many multi-agent workflows fail because people try to make every agent know everything. They paste long summaries between chats, copy logs from one provider into another, and eventually end up with one oversized shared context that is hard to trust. AxiOwl takes a different approach. In the current C++ implementation, it gives separate provider sessions a routing layer, not a merged brain.

That distinction is practical. AxiOwl does not need every agent to carry the same transcript. It needs to know which session is addressable, which provider owns it, whether it is sendable, who is sending, and how a reply should come back. The work can stay distributed across separate chats while AxiOwl carries the coordination facts between them.

Sources read

The Registry Carries Routing Context

The center of AxiOwl's coordination model is the registry. In models.hpp, an AgentRecord has fields for display_name, aliases, provider, provider_session_id, node_id, enabled, sendable, source, timestamps, and last_error. In the Windows desktop implementation, those rows are stored as TSV records and loaded by Registry.

That is a compact form of operational context. Instead of sending every chat the full history of every other chat, AxiOwl stores enough information to answer routing questions:

The tests show why this matters. A duplicate display name can exist in more than one session, and AxiOwl keeps those as separate rows. A normal name lookup prefers the newest matching session, while an exact provider session ID lookup can still select the older session. Discovery can update a session name without duplicating the row, and the old name becomes an alias. Manual rows are protected from discovery downgrades.

That is a better coordination primitive than a shared wall of text. Each agent can keep its own local provider context, while AxiOwl keeps the address book that lets the agents reach each other.

Sendability Is Not the Same as Being Known

A giant shared context tends to blur facts together. If a transcript mentions an agent, people may assume it is reachable. AxiOwl is stricter.

The registry separates known rows from sendable rows. The discovery merge code only enrolls a new row as a sendable target when the discovered row has enough enrollment proof. Weak evidence is still tracked, but it does not silently become a delivery route. The tests explicitly cover this behavior for Codex: a weak evidence-only Codex row is counted as evidence and skipped for enrollment, while a targeted Codex row with desktop IPC owner proof can become sendable.

The message pipeline enforces the same rule. If the target is known but sendable is false, AxiOwl rejects the send with a clear error. It does not hand the task to a stale or evidence-only row and hope the provider figures it out.

That makes the system less magical and more useful. AxiOwl can say, in effect, "I have seen something that looks related to this target, but I do not have a valid delivery route." That is the kind of boundary an operator needs when several agents are working at once.

A Message Is a Handoff, Not a Memory Dump

The user-facing CLI can look small:

axiowl send --to "Review Agent" --body "Please inspect the current patch and report back."

For longer instructions, the CLI can read from stdin:

axiowl send --to "Review Agent" --stdin

Underneath, MessagePipeline validates the target and body, resolves the sender, resolves the target registry row, performs one targeted discovery repair if the target is missing or stale, builds a final visible message body, and hands provider delivery to the delivery worker.

That flow is intentionally message-oriented. The pipeline is not trying to assemble one universal context that all agents must consume. It sends a specific body to a specific target through a provider edge. The receiving agent gets the task plus enough reply information to send a response back through AxiOwl when asked.

The final visible body builder is the clearest example. When the sender is resolved, AxiOwl prepends a simple sender header and appends an exact MCP reply instruction using mcp__axiowl.axiowl_send_message. The helper can include a runId and receiptForMessageId so the reply can be correlated. When the sender is not resolved, the helper does not attach a return command.

That is not shared memory. It is a deliberate handoff envelope.

MCP Preserves Sender Identity

AxiOwl's MCP server reinforces the same design. The axiowl_send_message tool description says success is an MCP-to-AxiOwl handoff receipt only; provider delivery and reply are not implied. The server instructions also tell provider hosts to use the typed AxiOwl tools and to rely on the host MCP session ID as the stable sender identity key.

In mcp_server.cpp, a provider session that calls axiowl_send_message must provide usable session metadata. If the MCP call does not include a required provider session ID, AxiOwl refuses the action instead of launching a no-session send. When identity is present, AxiOwl can register the sender with provider, session, node, and raw metadata, then call the CLI send path with the resolved sender address.

That matters for multi-agent work. A reply should not come from a guessed display name. It should come from the provider-owned session that actually sent it. AxiOwl's MCP layer carries that sender identity so the next handoff can be routed through the registry rather than through a growing pile of copied chat summaries.

Discovery Repairs the Map, Not the Whole Conversation

When a target is missing or stale, the pipeline runs targeted discovery once. The discovery code checks local provider surfaces such as Codex, Codex CLI, VS Code native, VS Code Copilot-backed sessions, Copilot CLI, Antigravity, Cursor, Claude Code CLI, and OpenCode CLI paths. It then merges any discovered rows into the registry.

The merge rules are conservative. Rows with missing identity fields are skipped. Manual rows can be enriched without being overwritten. Evidence-only rows can update evidence state without becoming sendable. If no sendable target is found, the pipeline returns a targeted discovery summary with counts for rows found, enrolled, updated, skipped, and evidence-only matches.

This is exactly the kind of context AxiOwl should share: the routing map. It does not need to broadcast every agent's entire working memory to every other agent. It needs to keep the map fresh enough that a named target can be reached, and honest enough that a non-sendable target is not treated as working.

Provider Edges Keep Separate Agents Separate

The provider dispatch table keeps delivery provider-specific. provider_edges.cpp routes delivery to Codex, Codex CLI, VS Code native, VS Code Copilot-backed sessions, Antigravity, Antigravity CLI, Cursor, Cursor CLI, Claude Code CLI, Copilot CLI, and OpenCode CLI provider modules where those edges exist. Create and rename operations use the same provider-edge structure where supported.

The provider support matrix is explicit about status. A supported surface has to meet the current bar: discovery works, the required integration is installed, AxiOwl can send to a named session, the provider receives the message, the provider replies through AxiOwl MCP, and the reply carries correct provider-owned sender identity. Surfaces that do not meet that bar stay target, experimental, unsupported, or removed.

That separation is important for context design. A Codex session, a Cursor session, a VS Code session, and an Antigravity session do not need to become the same thing. AxiOwl coordinates them by provider-specific edges and a shared registry contract.

Receipts Keep Proof Narrow

The receipt boundary is another reason AxiOwl can avoid the "one giant context" pattern. The pipeline returns accepted_by_axiowl after AxiOwl validates the request, resolves the route, and starts the provider handoff path. The tests assert that this receipt must not claim provider acceptance. Provider delivery and provider replies are separate proof events.

That narrow receipt is useful in real operations. If one agent sends work to another, the sender does not need the whole remote transcript back immediately. It needs to know what AxiOwl accepted, which target was selected, which provider edge was used, and whether later provider proof or a reply arrives.

The system stays inspectable because each fact has its own boundary. AxiOwl accepted the message. The delivery worker started. The provider edge accepted or failed. The target replied through MCP or did not. Those are separate operational events, not one blended success story.

Why This Helps Actual Agent Work

Keeping agents out of one giant context has a practical benefit: each session can specialize. A coding agent can keep its local patch context. A review agent can receive a focused request. A browser-testing agent can get only the steps it needs. A provider-specific session can stay inside the provider surface it knows how to operate.

AxiOwl supplies the connective tissue: names, session IDs, sendability, discovery repair, provider dispatch, sender identity, and receipt evidence. The agents do not need to share every token of context. They need reliable ways to send focused work and return focused results.

That is the current AxiOwl model in the C++ codebase. It is not a pooled memory system. It is a local coordinator that lets separate AI sessions cooperate without pretending they are one session. The implementation keeps the context that belongs in the coordinator, and leaves the working context with the agent that is doing the work.

Image prompt:

Create a polished graphic image related to: AI agents coordinating through compact routing context instead of one giant shared prompt.

Subject: a sleek central routing console holding a small stack of glowing index cards, with several separate blank glass terminal panels connected by thin light paths; each panel is isolated in its own lane, and the console shows abstract connection nodes with no readable characters.
Style: halfway between a clean symbolic icon and a realistic product/technical illustration; professional SaaS/technical marketing style; crisp edges; high detail; no text; no logos.
Background: solid #00ff00 chroma key green screen background covering the full canvas edge to edge.
Restrictions: no owl, no axolotl, no birds, no animals, no mascot, no text, no watermark.

Tagged