Overview
OrcBot’s multi-agent orchestration system enables parallel task execution by spawning isolated worker processes. Each worker is a full Agent instance that can execute tasks independently while coordinating with the main agent through IPC (Inter-Process Communication).Multi-agent orchestration is ideal for parallelizing independent tasks, background research, or long-running operations that shouldn’t block the main agent.
Architecture
Key Components
- AgentOrchestrator (
src/core/AgentOrchestrator.ts) - Manages worker lifecycle - AgentWorker (
src/core/AgentWorker.ts) - Worker process wrapper - WorkerProfileManager (
src/core/WorkerProfile.ts) - Worker metadata and persistence - MessageBus - IPC communication channel
Spawning Workers
Using spawn_agent Skill
Unique identifier for the worker agent
Agent type:
worker (isolated process) or peer (network agent)Optional configuration overrides for the worker
Using delegate_task Skill
Task description to delegate
Task priority (1-10)
Specific worker name, or omit for auto-assignment
Worker Lifecycle
Spawn
Main agent calls The orchestrator forks a new Node.js process running
spawn_agent with a unique name and optional config.AgentWorker.ts.Initialize
Worker loads its own Agent instance with shared or custom configuration.Worker has access to:
- All core skills
- Shared memory (read-only for safety)
- Its own action queue
- IPC channel to main agent
Monitoring Workers
In the TUI
- Worker name and PID
- Current status (idle, busy, error)
- Task queue depth
- Memory usage
- Uptime
Using orchestrator_status Skill
Inter-Agent Communication
Sending Messages
Name of the worker to message
Message content
Message priority
Broadcasting
Use Cases
Parallel Research
Spawn multiple researchers to investigate different topics simultaneously.
Background Monitoring
Delegate long-running monitoring tasks to workers.
Data Processing Pipeline
Chain workers for ETL (Extract, Transform, Load) operations.
- Worker 1: Scrape data
- Worker 2: Transform and validate
- Worker 3: Store in database
Multi-User Support
Dedicate workers to handle specific users or channels.
Configuration
Worker-Specific Settings
Per-Worker Overrides
Best Practices
Do’s
- Use workers for independent, parallelizable tasks
- Set reasonable timeouts for worker tasks
- Monitor worker health in production
- Use cheaper models for worker agents
- Clean up idle workers to free resources
Don’ts
- Don’t spawn workers for trivial tasks (use the main agent)
- Don’t share mutable state between workers and main agent
- Don’t rely on worker execution order (they’re async)
- Don’t spawn workers recursively (workers can’t spawn workers)
Troubleshooting
Worker Not Starting
Symptoms:spawn_agent completes but worker doesn’t appear in orchestrator_status.
Causes:
- Insufficient system resources
- Worker name conflicts
- Invalid configuration
Worker Crashes
Symptoms: Worker disappears from orchestrator status mid-task. Causes:- Out of memory
- Uncaught exception in worker code
- Task timeout exceeded
Tasks Not Distributing
Symptoms: All tasks go to one worker instead of distributing. Causes:- Only one worker marked as available
- Task routing rules favor specific worker
Performance Metrics
Worker Pool Efficiency
- Utilization: Percentage of time workers are busy vs idle
- Queue depth: Average number of pending tasks per worker
- Throughput: Tasks completed per minute
- Latency: Average time from task delegation to completion
- High utilization (greater than 80%): Spawn more workers
- Low utilization (less than 20%): Reduce worker count
- High queue depth: Increase worker capacity or add workers
- High latency: Check for slow tasks or resource bottlenecks