When to Split One Agent Into Multiple Agents

The most common architecture mistake in the OpenClaw ecosystem is the god agent: one agent that handles customer support, processes orders, sends marketing emails, manages internal tasks, and generates reports. It starts as a convenient prototype and becomes an unmaintainable mess within weeks.

If your agent's SOUL.md is longer than two pages or your AGENTS.md grants permissions to more than six tools, you probably need to split. Here's how to know for sure and how to do it without starting over.

## Signs You Need to Split

**Contradictory behavioral rules.** Your SOUL.md says "be concise and direct" for support interactions but "be thorough and detailed" for research tasks. The agent can't follow both rules simultaneously, so it picks one randomly or tries to compromise, which satisfies neither use case. If you're writing conditional behavior rules based on conversation type, you've outgrown a single agent.

**Overly broad permissions.** Your AGENTS.md gives the agent write access to your CRM, your support ticketing system, your email platform, your calendar, and your database. Each permission is justified for some part of the agent's job. But collectively, the agent has the keys to everything, and one misinterpreted instruction can cause damage across multiple systems.

**Inconsistent performance.** The agent handles billing questions well but fumbles product recommendations. It's great at scheduling meetings but terrible at writing follow-up emails. When one agent covers multiple domains, it optimizes for none of them. The SOUL.md can only do so much when the agent is context-switching between fundamentally different tasks.

**Debugging is painful.** When something goes wrong, you can't tell which part of the agent caused it. Was it the support logic, the sales logic, or the ops logic? The logs show a single conversation thread mixing concerns. Isolating the failure means reading through the entire interaction history.

**Slow response times.** A large SOUL.md and extensive AGENTS.md consume tokens on every interaction. The model needs to process all of those instructions even when most of them are irrelevant to the current request. Two focused agents with lean configs will each respond faster than one bloated agent.

## The Single-Responsibility Principle for Agents

Software engineering figured this out decades ago: each module should do one thing well. The same principle applies to agents.

A well-scoped agent has: - A SOUL.md that fits on one page - An AGENTS.md with 2-4 skills - A clear answer to "what does this agent do?" in one sentence - Behavioral rules that never contradict each other - Permissions that make sense together

If you can't describe your agent's job in one sentence without using the word "and" more than once, it's doing too much. "Handles customer billing inquiries" is one agent. "Handles customer billing inquiries and schedules meetings and writes marketing copy" is three agents pretending to be one.

## How Skills Overlap Causes Confusion

The subtlest problem with god agents is skill overlap. Consider an agent with both email and Slack access. When a user says "send a message to Sarah," should the agent use email or Slack? The answer depends on context that the agent might not have.

With separate agents, there's no ambiguity. The email agent sends emails. The Slack agent sends Slack messages. The routing happens before the message reaches an agent, not inside the agent's reasoning chain.

Skill overlap also creates permission escalation risks. An agent with read access to a database and write access to email can effectively exfiltrate data by emailing query results. Two separate agents, one with database access and one with email access, can't combine their permissions this way. Separation of capabilities is a security boundary, not just an organizational preference.

## Step-by-Step Splitting Guide

Splitting a god agent is less painful than most people expect. Here's the process:

**Step 1: List every distinct function.** Go through your SOUL.md and AGENTS.md and list every discrete thing the agent does. "Answer billing questions," "schedule meetings," "send weekly reports," "respond to Slack questions." Be specific.

**Step 2: Group related functions.** Cluster the functions by domain. Billing questions and refund processing belong together. Meeting scheduling and calendar management belong together. If two functions share the same skill dependencies, they're probably in the same group.

**Step 3: Create a new agent for each group.** For each cluster, create a new agent with its own SOUL.md and AGENTS.md. Extract the relevant sections from the original config. Each new agent's SOUL.md should be focused and short. Each AGENTS.md should include only the skills that group needs.

**Step 4: Set up routing.** You need something to direct incoming requests to the right agent. Options include:

- **Keyword routing:** Simple pattern matching on the incoming message. Messages containing "billing" or "invoice" go to the billing agent. Messages containing "meeting" or "schedule" go to the calendar agent. - **Classifier routing:** A lightweight LLM call that reads the message and picks the right agent. More accurate than keywords, costs a few cents per request. - **Channel routing:** Different input channels go to different agents. Support tickets go to the support agent. Slack messages in #sales go to the sales agent. This is the simplest and most reliable approach when your agents serve different audiences.

ClawSprout supports all three routing methods. The dashboard lets you configure routing rules visually and shows you which agent handled each request.

**Step 5: Test with historical inputs.** Take the last 50-100 real interactions your god agent handled. Run them through the new multi-agent setup and verify that each request reaches the right agent and gets a good response. This is the best way to catch routing gaps and missing behavioral rules.

## Sharing Context Between Agents

The biggest concern when splitting is losing shared context. Your god agent knew the full history of every interaction. Separate agents each see only their own conversations.

OpenClaw handles this with shared memory. Agents can read from and write to a shared context store. When the billing agent resolves a customer issue, it writes a summary to shared memory. When the support agent later handles a follow-up from the same customer, it reads that summary.

```markdown ## Shared Memory

### store: customer_context - read: [billing-agent, support-agent, sales-agent] - write: [billing-agent, support-agent] - retention: 90 days ```

The key is being deliberate about what gets shared. Don't share everything. Share the minimum context each agent needs to do its job. Customer name, recent interactions, and open issues are useful context. Internal reasoning chains and intermediate steps are noise.

ClawSprout's multi-agent dashboard shows the shared memory store and which agents are reading and writing. You can see exactly what context is flowing between agents, which makes debugging cross-agent issues much easier than debugging a monolithic god agent.

## When Not to Split

Not every agent needs to be split. If your agent does one thing, does it well, and has a clean SOUL.md under one page, leave it alone. Splitting for the sake of architecture adds complexity without benefit.

The rule of thumb: split when you feel pain, not preemptively. If your agent is performing well, responding quickly, and easy to debug, its current scope is fine. When you start noticing the signs listed above: contradictory rules, broad permissions, inconsistent performance, or painful debugging, that's when splitting pays off.

Start with two agents. Extract the most distinct function into its own agent and leave everything else in the original. Get that working, then evaluate whether the original needs further splitting. Incremental migration beats a big-bang rewrite every time.

Related posts