Two Agents Are Better Than One for Planning

Two Agents Are Better Than One for Planning

Planning improves when a second agent can look at the same objective from a different angle, but that only helps if the handoff is explicit. AxiOwl treats that handoff as a message between independent, named provider sessions. One session can ask another session to review a plan, produce an alternate sequence, check assumptions, or list risks. AxiOwl does not need to pretend the two agents share one giant memory. It routes a concrete message to a concrete target and gives the sender a clear path for a reply.

That distinction matters. AxiOwl is not an automatic judge of which plan is correct. In the current C++ implementation, it is a local Windows coordinator for provider-to-provider messaging. It discovers provider sessions, records them in a registry, resolves named targets, sends messages through provider-specific edges, and records receipts and delivery evidence. The planning value comes from making the conversation addressable and auditable.

Sources read

Planning Needs Separate Minds, Not Blended Context

A common failure mode in agent workflows is asking one long-running chat to be the planner, implementer, reviewer, risk analyst, and final editor. That can work for small tasks, but it also creates blind spots. The same session carries the same assumptions forward. It may overfit to the first approach it produced. It may stop noticing missing constraints because those constraints were never written down clearly.

AxiOwl supports a more concrete pattern: keep multiple sessions addressable and ask for help when the plan matters.

For example, one session can draft a deployment plan. A second session can be asked to review only the risk model. A third session can inspect whether the plan is too broad for the current repo state. Those sessions do not need invisible shared memory. They need the planning packet: the objective, constraints, evidence, open questions, and the response contract.

In AxiOwl terms, that packet is just a message sent to a named registered target.

axiowl send --to "Release Risk Reviewer" --stdin --from "Implementation Planner"

The receiving session gets a visible message from the sender. If AxiOwl resolves the sender identity, the final visible body includes an MCP reply instruction that targets the original sender by name. The current final_visible_body_builder.cpp implementation builds the message as "Message from …" followed by the original body and an exact axiowl_send_message tool-call shape for replying.

That is the core planning primitive: one named session can ask another named session for a bounded answer, and the answer can come back through the same coordination layer.

The Registry Makes Planning Partners Addressable

AxiOwl planning workflows depend on the registry because "ask another agent" should not mean "hope the tool finds something nearby." A registry row represents a reachable provider session or agent. The C++ model includes fields for display name, aliases, provider, provider session id, node id, enabled state, sendable state, source, timestamps, and last error.

That means a planning partner can be addressed as a name, while AxiOwl still retains the provider-specific route behind the name. The operator or sending agent can target:

axiowl send --to "Architecture Planner" --body "Review this migration plan for hidden coupling." --from "Backend Planner"

or:

axiowl send --to "Frontend Planning Thread" --stdin --from "Product Planner"

The quoted target is resolved through the local registry. If the target is found and sendable, the pipeline keeps the provider route explicit. provider_edges.cpp dispatches by the resolved provider value, including current edges such as codex, codex_cli, vscode_native, vscode_copilot_backed, antigravity, cursor, claude_code_cli, copilot_cli, and opencode_cli.

This is not a shared whiteboard. It is a routed message to a real session. That is why the pattern stays practical: the planning session you chose is the planning session that receives the request.

MCP Sender Identity Keeps Replies Grounded

The strongest planning loop is not a one-way send. It is a send followed by a reply from the recipient back to the sender.

The AxiOwl MCP server exposes tools such as axiowl_whoami, axiowl_list_agents, axiowl_send_message, and axiowl_create_agent. The MCP tool description in mcp_server.cpp is explicit that axiowl_send_message uses the host MCP session ID as the stable sender identity key. During MCP initialization, the server instructs hosts to use axiowl_send_message for sending and not to invent raw command arguments or session ids.

That matters for planning because replies need a real route. If Agent B is reviewing Agent A's plan, Agent B should not guess who Agent A is. AxiOwl resolves the sender from provider metadata, registers the sender when appropriate, and sends the message through the normal pipeline with a --from value derived from that identity.

The Codex plugin skill in the repo says the same thing in operational language: prefer the bundled MCP tool over shell commands because the tool receives Codex thread metadata, do not ask the chat agent to know its own Codex session id, and treat CLI acceptance as different from recipient reply.

For planning, that gives a clean rule:

Use MCP replies when the recipient is answering back into the workflow. Use raw CLI sends mostly for operator-driven tests or controlled handoffs where the sender is explicit.

Receipts Are Not Correctness Judgments

AxiOwl is careful about receipt boundaries, and planning workflows should be too.

In message_pipeline.cpp, a send can return accepted_by_axiowl after AxiOwl validates the request, resolves the target, confirms the target is sendable, builds the final visible body, and starts delivery worker handoff. The CLI text in cli.cpp states the boundary directly: provider delivery, provider wake-up, and provider reply are not implied by the AxiOwl handoff receipt.

The user docs and architecture overview make the same distinction. accepted_by_axiowl means AxiOwl accepted the request and handed it to delivery. A provider result such as accepted_by_provider is stronger, but still not the same as a useful planning answer. The strongest proof is a response over MCP: the target provider received the message, acted on it, and replied through AxiOwl with provider-owned sender identity.

That is why "two agents are better than one" should not be read as "AxiOwl decides the better plan." The implementation does not prove that. What it supports is a planning loop with visible steps:

  1. Agent A sends a specific planning request to Agent B.
  2. AxiOwl resolves Agent B as a named, sendable target.
  3. AxiOwl records the handoff boundary and delivery evidence.
  4. Agent B replies through AxiOwl MCP when the host exposes the tool.
  5. The operator or workflow compares the original plan, the second plan, and the evidence.

The judgment still belongs to the workflow. AxiOwl makes the exchange explicit enough that the judgment has something concrete to inspect.

What a Good Planning Packet Looks Like

The planning request should be narrow enough for the second agent to add value. A message like "look at this" is weak. A message with a role, objective, constraints, and reply format is better:

You are the planning reviewer for this change.

Objective: reduce deployment risk for the installer update.
Context: the first plan changes discovery, registry enrollment, and provider delivery.
Constraints: do not change unrelated provider integrations; do not invent fallback behavior.
Please reply with:
- assumptions you would verify before editing
- the riskiest part of the plan
- one smaller alternate plan
- any blocker that should stop implementation

Sent through AxiOwl, this becomes a message to a named session. The receiving agent can reply with a bounded planning artifact rather than absorbing the entire project history. The sender can then decide whether to revise the plan, ask for a third review, or proceed.

This is especially useful for plans that touch multiple concerns. One session can focus on implementation sequence. Another can focus on blast radius. Another can focus on test coverage. AxiOwl's value is that those sessions can stay independent while still communicating.

Independent Sessions Make Disagreement Useful

Two agents are useful for planning only when disagreement is allowed to remain visible. If a system silently merges the outputs, the operator loses the reason each plan exists. AxiOwl does not silently merge them. It sends messages, records events, and gives agents a route to reply.

That fits the current implementation model. The registry preserves distinct provider sessions. The MCP server requires sender identity rather than accepting anonymous replies. The message pipeline logs receipt boundaries. The delivery worker records provider-edge results. The evidence log writes JSONL events with timestamps and fields such as message id, target, provider, sender, state, method, evidence, and error.

Those details are not decoration. They make planning conversations inspectable. If Agent B says the plan is too risky, you can see which session was asked, what target name was used, whether AxiOwl accepted the request, and whether a reply came through the MCP path. That does not make Agent B correct. It makes the review attributable.

A Practical Two-Agent Planning Flow

A simple AxiOwl planning workflow looks like this:

First, list available planning partners:

axiowl list agents

Then send a bounded plan review request:

axiowl send --to "Risk Review Thread" --stdin --from "Planning Thread"

If the sender is a provider session with AxiOwl MCP available, the preferred route is the axiowl_send_message MCP tool, because the MCP path carries provider/session identity metadata. The recipient can then reply using the exact AxiOwl MCP tool-call shape attached in the visible message.

Finally, compare the outputs as separate artifacts:

That last step is important. AxiOwl coordinates the exchange, but it does not replace the planning decision.

Why This Helps Operators

The operator benefit is not that two agents magically become one smarter agent. The benefit is that planning work can be split without losing the thread.

One named session can hold the implementation plan. Another named session can challenge the assumptions. A third can check provider-specific risk. Each can operate inside its own context window, provider surface, and session history. AxiOwl supplies the coordination layer: target resolution, sender identity, message handoff, reply instructions, and evidence.

That makes planning more durable. A blocked or overloaded session does not have to be the only place where the plan exists. A review does not have to be pasted manually from one app to another. A reply does not have to depend on a guessed sender name. The planning conversation becomes a set of explicit messages between registered sessions.

Closing

Two agents are better than one for planning when the second agent is asked a real planning question and can answer back through a real route. AxiOwl's current C++ implementation supports that pattern by keeping provider sessions addressable, resolving sender identity, routing messages through provider edges, and recording the boundary between handoff, delivery, and reply.

It does not claim automatic shared memory. It does not decide which plan is correct. It gives independent sessions a practical way to coordinate, which is the part planning workflows actually need.

Image prompt:

Create a polished graphic image related to: two independent AI agent sessions coordinating on a planning workflow through AxiOwl.

Subject: two separate modern workstation terminals connected to a central routing hub, with floating checklist cards and branching plan diagrams represented only by abstract lines and blocks, no readable text.
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