Overview
When you need to perform a long-running operation (like running tests, generating reports, or fetching data from multiple sources), subagents execute the task in the background while the main agent remains responsive. Key features:- Non-blocking background execution
- Full agent capabilities (tools, LLM reasoning)
- Automatic result announcement to the main agent
- Session-based task tracking and cancellation
- Separate tool registry (no message/spawn tools to prevent recursion)
- Configurable iteration limits and timeouts
Architecture
Fromnanobot/agent/subagent.py:21-51:
- Task ID: Short UUID for tracking (8 characters)
- Label: Human-readable description
- Origin: Channel and chat_id for result delivery
- Tool access: Read, write, edit, list, exec, web search, web fetch
- No message tool: Prevents sending intermediate updates
- No spawn tool: Prevents recursive subagent creation
Spawning a Subagent
Fromnanobot/agent/subagent.py:53-83:
Tool Registry
Subagents have a restricted tool set to prevent unwanted side effects (nanobot/agent/subagent.py:96-110):
- File operations: read, write, edit, list
- Shell execution: run commands
- Web: search and fetch
- Message sending (prevents spamming channels)
- Spawn (prevents recursive subagent creation)
Execution Loop
Fromnanobot/agent/subagent.py:119-167:
Result Announcement
When a subagent completes, it announces the result to the main agent via the message bus (nanobot/agent/subagent.py:180-210):
System Prompt
Subagents use a focused prompt (nanobot/agent/subagent.py:212-232):
Usage Examples
1. Running Tests
2. Data Collection
3. Report Generation
4. File Processing
Session Management
Tracking Running Tasks
Canceling Tasks by Session
nanobot/agent/subagent.py:234-242:
Use Cases
1. Long-Running Analysis
Analyzing large datasets without blocking the main conversation:2. Multi-Step Workflows
Complex tasks that require multiple tool calls:3. Parallel Research
Gathering information from multiple sources:4. Background Monitoring
Continuous monitoring without blocking:Configuration
| Parameter | Type | Default | Description |
|---|---|---|---|
provider | LLMProvider | required | LLM provider for subagent reasoning |
workspace | Path | required | Working directory for file operations |
bus | MessageBus | required | Message bus for result announcements |
model | str | provider default | Model to use for subagent |
temperature | float | 0.7 | Sampling temperature |
max_tokens | int | 4096 | Max tokens per response |
reasoning_effort | str | None | Reasoning effort level (provider-specific) |
brave_api_key | str | None | API key for web search |
web_proxy | str | None | Proxy for web requests |
exec_config | ExecToolConfig | default | Shell execution configuration |
restrict_to_workspace | bool | False | Limit file/shell access to workspace |
Best Practices
- Use descriptive labels: Labels appear in the status message and help track tasks
- Set session keys: Enable session-based cancellation for user-initiated tasks
- Keep tasks focused: Break complex workflows into smaller subagent tasks
- Monitor running count: Limit concurrent subagents to avoid resource exhaustion
- Handle failures gracefully: Subagents can fail; main agent should handle error announcements
- Use workspace restriction: Set
restrict_to_workspace=Truein production to sandbox file access - Set appropriate iteration limits: Default 15 iterations prevents infinite loops
Limitations
- No message tool: Subagents cannot send intermediate updates to channels
- No nested spawning: Subagents cannot spawn other subagents
- Fixed iteration limit: Maximum 15 LLM calls per subagent
- No progress tracking: Main agent only receives final result or error
- Resource usage: Each subagent consumes memory and tokens; monitor usage
Related
- Heartbeat System - Periodic task checking
- Cron Service - Scheduled task execution