Reorganizing Agent Teams: From Generalists to Role-Based Specialization

In the era of AI Agents, running an efficient team is more than just providing access to Large Language Models (LLMs). Recently, we underwent a significant transformation: transitioning from a setup of 5 agents sharing a general set of instructions to a model of 6 specialized roles.

This article shares the practical experiences and technical principles we applied to optimize this process.

1. Evolution: From Generalists to Specialists

Previously, our system consisted of 5 “Jack-of-all-trades” agents, all sharing a long and complex instruction set. This often led to context dilution and inconsistent outputs.

We decided to restructure into a team with 6 distinct roles:

  • PO (Product Owner): Manages product vision and prioritizes the backlog. (PO-SOUL.md)
  • BA (Business Analyst): Analyzes requirements and details feature specifications. (BA-SOUL.md)
  • DEV (Developer): Focuses entirely on code execution and technical problem-solving. (DEV-SOUL.md)
  • TEST (Tester): Responsible for QA, bug finding, and ensuring product reliability. (TEST-SOUL.md)
  • SEARCH (Search Specialist): Gathers information, researches documentation, and fetches the latest data from the web. (SEARCH-SOUL.md)
  • DEVOPS (DevOps Engineer): Manages infrastructure, deployment, and system monitoring. (DEVOPS-SOUL.md)

Splitting roles allows each agent to maintain a cleaner context window, focusing only on the skills essential to their specific tasks.

2. Technical Details & Implementation

To bring this model to life, we optimized the system for OpenClaw version 2026.2.6-3. Below is how we define roles and manage permissions.

Agent Configuration in openclaw.json

We focus on the configuration of the main (PO) and dev agents to highlight the difference: main has coordination authority (subagents), while dev has specialized technical permissions (browser, nodes). Note the use of the <USER_HOME> alias for system paths:

  "agents": {
    "list": [
      {
        "id": "main",
        "name": "po",
        "workspace": "<USER_HOME>/.openclaw/workspace",
        "agentDir": "<USER_HOME>/.openclaw/agents/main/agent",
        "identity": { "name": "PO", "emoji": "🎯" },
        "subagents": {
          "allowAgents": ["ba", "dev", "test", "search", "devops"]
        },
        "tools": {
          "allow": ["sessions_send", "sessions_spawn", "read", "write", "edit", "exec", "process", "web_fetch", "web_search", "cron", "message", "gateway"]
        }
      },
      {
        "id": "dev",
        "name": "dev",
        "workspace": "<USER_HOME>/.openclaw/workspace-dev",
        "agentDir": "<USER_HOME>/.openclaw/agents/dev/agent",
        "identity": { "name": "DEV", "emoji": "🏋️‍♂️" },
        "tools": {
          "allow": ["read", "write", "edit", "exec", "process", "web_search", "web_fetch", "browser", "nodes"]
        }
      }
    ]
  }

Permission Boundaries

A key strategy we apply is: Retain maximum technical permissions in openclaw.json but limit actual behavior through “Iron Discipline” in SOUL.md.

Why? Overly restrictive configuration in JSON files can cause the system to hang or fail when an agent needs to perform a minor operation blocked at the core level. Instead, we provide sufficient tools but require agents to self-limit via instructions in SOUL.md.

Example of the PO’s self-imposed boundaries in SOUL.md:

## 🎯 ROLE: PROJECT OWNER (PO) - SUPREME COORDINATOR

- **"No Overstepping" Policy:** You are the driver. You NEVER write code, edit Specs, or run tests yourself. Your job is to coordinate the right person for the right job.
- **Control Constraints:** You must verify the Artifact of the previous Agent before calling the next one (e.g., verify BA's Specs before calling DEV).
- **Decision Authority:** Make the final decision when there is a logical conflict between member Agents.

Coordination Configuration (Collaboration)

Coordination capabilities are demonstrated through the subagents configuration in the main (PO) agent. The PO has the authority to summon and assign tasks to other specialized agents. Additionally, setting subagents.thinking: "off" by default optimizes speed and cost when agents collaborate.

3. “Steel Terms” and the “No Overstepping” Policy

The biggest challenge in role fragmentation is overlapping responsibilities. To address this, we established strict “Steel Terms”.

Each agent has a clearly defined scope. Alongside this is the “No Overstepping” policy: A DEV Agent must never unilaterally modify business requirements set by the BA, and a PO must not interfere with the DEVOPS infrastructure implementation.

If an agent identifies an issue outside their scope, they must use a delegation mechanism or report back to the relevant agent instead of handling it themselves. This ensures system integrity and makes debugging significantly easier.

4. Performance Optimization via Request-based Quota Monitoring

As the number of agents increased, managing costs and resources became critical. Instead of monitoring vague metrics, we upgraded to a Request-based Quota Monitoring system.

The new system allows us to:

  • Set request limits for specific roles.
  • Track agent performance based on request success rates.
  • Automatically throttle or alert when an agent enters an infinite loop or consumes resources abnormally.
  • Automatic quota reset at 00:00 daily.

This change not only saved costs but also forced agents to “think twice” (optimize prompting) before executing each action.

5. Conclusion

Transitioning to a Role-based model is not just a technical shift; it’s a change in the philosophy of AI team management. By specializing, enforcing strict discipline, and closely monitoring resources, we have built an Agent system that is robust, stable, and highly scalable.

We hope these insights help you on your journey of building and optimizing your own Multi-Agent systems.

Related posts