How AxiOwl Supports Multi-Agent Planning Without Merging Every Context

Multi-agent planning works best when each participant can stay focused. A planning agent does not need every provider session to share one giant transcript. It needs a way to address the right session, send a specific task, receive a reply, and know which parts of that handoff are proven. The current AxiOwl C++ implementation supports that model as explicit coordination between independent provider sessions through messages and MCP replies, not as automatic shared memory or context merging.

That difference is the point. AxiOwl keeps the operational facts needed for coordination: sender identity, target identity, provider surface, provider session id, node id, sendability, message id, run id, and delivery evidence. The provider sessions still remain separate sessions with their own local context.

Sources read

• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\README.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\README.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\reference\architecture-overview.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\reference\provider-support-matrix.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\user\README.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\developer\README.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\security\trust-boundaries.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\providers\README.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\providers\codex-agents.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\models.hpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\registry.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\message_pipeline.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\final_visible_body_builder.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\mcp_server.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\provider_edges.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\cli.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\tests\core_tests.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\tests\mcp_conformance.ps1

Planning Starts With Addressable Sessions

The source-of-truth architecture docs describe AxiOwl as a local Windows coordinator for sending messages between AI provider sessions. The core flow is:

user / provider MCP call / CLI
  -> axiowl.exe
  -> MCP or CLI command handler
  -> MessagePipeline
  -> registry target and sender resolution
  -> targeted discovery repair when needed
  -> provider_edges dispatch
  -> provider-specific delivery
  -> delivery logs and provider proof

For planning, the important part is not that every agent sees the same transcript. The important part is that AxiOwl can resolve a planning instruction like "send this review task to the build agent" into a concrete provider session.

In the C++ model, an AgentRecord includes a human display name, aliases, provider, provider-owned session id, node id, enabled state, sendable state, source, timestamps, and last error. That registry row is the planning handle. A planner can target a named session without pasting every previous conversation into every other session.

The tests make this more concrete. Duplicate display names can exist across different provider sessions, and the registry keeps them as separate rows. A name lookup can prefer the newest matching session, while an exact session id lookup can still reach an older session. Discovery can update a session name without collapsing it into unrelated work. Manual rows are protected from being overwritten by later discovery. These are coordination rules, not memory-merging rules.

A Plan Step Becomes A Message

AxiOwl exposes a direct command surface for handoffs:

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

For larger planning instructions, the same send path can read from stdin:

axiowl send --to "Target chat name" --stdin

The MessagePipeline validates the target and body, resolves the sender, resolves the target registry row, performs one targeted discovery repair when needed, builds the final visible body, and hands provider delivery to the delivery worker. If the target is known but not sendable, the pipeline rejects the send instead of pretending the plan was delivered.

That behavior is useful in multi-agent planning because it keeps each handoff bounded. A planner can send "inspect the migration risk," "write the test case," or "summarize this failure" as separate messages to separate provider sessions. AxiOwl is not assembling a universal context object behind the scenes. It is routing explicit messages to explicit sessions.

The provider dispatch table reinforces that separation. Delivery goes through provider-specific edges such as codex, codex_cli, vscode_native, vscode_copilot_backed, antigravity, cursor, claude_code_cli, copilot_cli, and opencode_cli. Each provider surface has its own delivery implementation and support status. A planning workflow can involve multiple providers, but AxiOwl still treats each recipient as a specific target with a specific route.

Replies Are Explicit Too

The reply path is where AxiOwl's design becomes especially relevant to planning. The final visible body builder does not ask the receiving agent to guess who sent the message. When the sender is resolved, it prepends a sender header and appends an exact MCP reply instruction:

mcp__axiowl.axiowl_send_message({
  "to": "Sender Agent",
  "body": "<full reply>"
})

When the pipeline has a run id and message id, the helper can also include runId and receiptForMessageId. That gives a planner a practical way to connect a returned answer to the planning step that produced it.

The tests assert the shape of this helper. They check that resolved senders get the axiowl_send_message MCP call, that JSON target names are escaped correctly, and that runId plus receiptForMessageId are included when available. They also assert that older shell fallback wording, raw axiowl send instructions, and manually supplied --from guidance do not return in the final visible body.

That is a deliberate coordination contract. The receiving provider session replies through the installed AxiOwl MCP tool. The reply is not treated as a magical shared-memory update. It is another AxiOwl message, sent back to a specific registered sender with provider/session identity metadata.

MCP Carries Sender Identity

For multi-agent planning, identity matters. If a planner sends work to three agents and gets three replies, it needs to know which session responded. AxiOwl's MCP server is built around that requirement.

The MCP tool list includes axiowl_whoami, axiowl_send_message, axiowl_create_agent, and other operational tools. The axiowl_send_message tool description says the host MCP session ID is used as the stable sender identity key and that success is only an MCP-to-AxiOwl handoff receipt. Provider delivery and reply are not implied.

The implementation resolves identity from provider metadata and session state, registers the sender in the registry when possible, and then runs the CLI send path with the provider session or sender address as the sender key. If the provider host does not supply usable session metadata, the MCP server fails loudly instead of launching a no-session send.

The docs state the same rule: provider replies must include enough metadata for AxiOwl to identify the sender session, and final CLI support must not rely on environment-only identity injection. For supported provider surfaces, the support bar includes discovery, install/config, send, provider receive, provider MCP reply, and correct sender identity.

That makes planning more auditable. A reply is not just "some agent answered." AxiOwl expects the reply to come from a provider-owned session identity that can be tied back to the registry.

Receipts Prevent False Confidence

A multi-agent plan can fail quietly if the coordinator treats every handoff as complete the moment a message is accepted. AxiOwl avoids that by separating receipt states.

The source docs define accepted_by_axiowl as a local handoff receipt. It means AxiOwl accepted and validated the request and handed it to the delivery layer. It does not prove that the provider displayed the message, processed it, or replied.

That boundary is enforced in the code and tests. MessagePipeline::send can return accepted_by_axiowl before provider delivery has completed. The core tests verify that the send receipt path does not report provider acceptance, logs delivery_receipt as axiowl_only, records the boundary as after target resolution and before delivery worker or provider work, and starts background delivery after the receipt.

For planning, this is important operational feedback. A planning agent can distinguish:

• "AxiOwl accepted the handoff."
• "The provider edge reported provider acceptance."
• "The target provider actually replied through AxiOwl MCP with usable identity."

Those are different states. AxiOwl keeps them different.

No Automatic Context Merge Is Visible In The Current Source

The files read for this article show message routing, registry lookup, provider discovery, MCP identity, final visible reply instructions, delivery evidence, and receipt boundaries. They do not show an automatic transcript merge system that pushes every session's context into every other session.

There is a sourceContext field on MCP send arguments and the CLI request model, but in the implementation paths read here it is coordination metadata, not a shared memory store that merges provider histories. The final visible body is built from the requested message, the resolved sender, and reply/correlation information. It does not gather all other provider transcripts into the recipient's context.

That restraint is a feature for planning. It lets each provider session remain an independent worker with its own local context while still participating in a larger plan. The planner sends the piece of work that matters. The recipient replies through AxiOwl. The reply can be correlated. The registry preserves addressability. The logs preserve proof boundaries.

A Practical Planning Pattern

A realistic AxiOwl planning flow looks like this:

1. Discover or register the provider sessions that should participate.
2. Confirm that the target rows are sendable.
3. Send a bounded planning task to one target session.
4. Let the receiving session work in its own provider context.
5. Have the receiving session reply through axiowl_send_message.
6. Use runId, receiptForMessageId, delivery logs, and sender identity to reconcile the reply.
7. Send the next planning step based on the reply, rather than forcing every participant to ingest the whole plan history.

That model scales better than one enormous shared prompt. It makes the coordination layer responsible for routing and evidence, while the provider sessions remain responsible for their own reasoning work.

Planning Without A Merged Transcript

AxiOwl supports multi-agent planning by making handoffs explicit. It gives operators and provider sessions a way to name targets, resolve senders, send messages, request replies, and verify identity. It does not need to merge every context to do that.

The result is a practical coordination layer: independent sessions, explicit messages, structured MCP replies, clear receipt boundaries, and logs that separate acceptance from proof. That is the current implementation-backed way AxiOwl helps multiple agents plan together without turning every chat into one shared transcript.

Image prompt:

Create a polished graphic image related to: multi-agent planning without merged context.

Subject: a central routing console coordinating several separate transparent workflow panels, with thin glowing message paths between the panels and no readable labels.
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.