Multi-Soul Orchestration: When To Split, How To Hand Off

A single Soul carrying every responsibility — triage, drafting, deploying, customer support — eventually starts to sound like a junior generalist. The voice gets muddled, the memory stores collide, the refusal patterns conflict. The fix is not a bigger model; it's specialization. OpenClaw lets you spin up multiple Souls and hand work between them like an org chart.

The router pattern

The most common multi-Soul shape is one router Soul plus N specialist Souls. The router has a thin Soul brief — its job is to read the request, classify it, and hand off to the right specialist. The router doesn't try to answer; it dispatches. The specialists carry the deep voice, memory, and procedures for their domain.

1. 1User input arrives at the router Soul
2. 2Router classifies the request against known specialist taxonomies
3. 3Router hands off with a structured handoff payload — request, classification, relevant context
4. 4Specialist Soul takes over, runs the task, returns a result
5. 5Router decides whether the user sees the specialist directly, or whether the router summarizes
6. 6Episodic memory of the handoff is written so future routers learn from it

The handoff payload

Handoffs fail when they pass too little or too much. Too little: the specialist re-asks questions the user already answered. Too much: the specialist drowns in irrelevant prior context and the voice doesn't switch cleanly. Define the payload shape explicitly.

// The handoff payload OpenClaw passes between Souls.
// Keep it small, structured, and free of router voice.

type Handoff = {
  fromSoul: string;
  toSoul: string;
  reason: 'classified' | 'escalation' | 'fallback';
  request: {
    raw: string;            // the user's original message, verbatim
    intent: string;         // the router's classification
    entities: string[];     // people, systems, dates the router pulled out
  };
  context: {
    recentTurns: number;    // how many prior turns the specialist needs to read
    sharedFacts: string[];  // semantic memory keys to preload
    privateFacts?: never;   // never share another Soul's private episodic
  };
  permissions: {
    canRespondDirectly: boolean;  // or must hand back to router
    toolWhitelist: string[];      // narrower than the specialist's full kit
  };
};

Shared vs private memory

When you split into multiple Souls, the memory question gets harder. Some facts are organizational — every Soul should know them. Some are intimate to one Soul — a customer-success Soul shouldn't see the on-call Soul's incident notes. Decide the boundary deliberately.

Conversation continuity across handoff

Users hate being asked the same question twice. The specialist Soul should know what the router already knows — but only what's relevant. The cleanest pattern is: router writes a one-paragraph summary of the conversation to date, hands it to the specialist as part of the payload, and the specialist treats it as a primer, not as full episodic context.

• Router writes a 3-5 sentence summary capturing intent, entities, and what's been tried
• Specialist reads the summary as system context, NOT as episodic memory
• If the specialist needs more, it asks the router for specific shared facts by key
• Specialist's own episodic memory begins fresh from the moment it takes over
• On handoff back, specialist returns a structured result, not free-form transcript

When NOT to split

• Domain is small and unified — one voice, one memory, one Soul is fine
• Tasks rarely require domain-specific tone — context-switching costs more than it saves
• You're still iterating on the original Soul brief — splitting prematurely freezes mistakes
• Latency matters and the handoff would add a model roundtrip per turn
• You don't have eval coverage for each Soul individually — splits without evals just multiply unknowns

Apply: design a two-Soul split

1. 1Take an existing single-Soul agent that's starting to feel overloaded
2. 2List its top 10 tasks and group them by voice / memory needs
3. 3If two natural clusters emerge, draft Soul briefs for each — name, voice, refusals, memory boundary
4. 4Define the handoff payload shape for the two new Souls
5. 5Write three end-to-end scenarios that cross the boundary; trace what gets shared
6. 6Run the eval set you already had for the single Soul against the new pair — coverage should not regress

The big idea: multiple Souls work like an org chart with explicit handoffs. The wins come from specialization; the costs come from sloppy memory boundaries. Split when voice and memory genuinely diverge — and design the handoff before you wire it.