Agents
Two instances, seven sub-agents
OpenClaw runs as two independent instances -- Max and Eva -- on separate physical machines, operated by different people. Each instance has its own set of specialized sub-agents for specific tasks.
Agent Topology
Machine 1
Max
mainmail-readerkickoff-codingbridge-readerbridge-voiceMachine 2
Eva
mainbridge-readerMax
Dedicated Mac, 8GB RAM
mainCentral orchestrator. Handles Telegram commands, task delegation, system management.
mail-readerIsolated email processing. Exec in allowlist mode, only mail-extract script authorized.
kickoff-codingWeb project deployment. Receives client briefs, generates code, deploys to hosting.
bridge-readerDisposable sanitizer for inter-agent messages. Zero tools, 60s timeout, rewrites everything.
bridge-voiceHandles voice messages from the bridge. Transcription + processing in isolation.
Eva
Dedicated Mac, 8GB RAM
mainCentral orchestrator. Handles messaging commands, task management.
bridge-readerDisposable sanitizer for inter-agent messages. Same zero-trust pattern as Max.
With EasyClaw v2, an agent's personality, capabilities, and rules are defined in a standard Markdown file with YAML frontmatter. No more server code needed: everything is done in a readable, version-controllable file. Modifying an agent becomes as simple as editing a document.
How it works
- 1Create a Markdown file with standardized sections: identity, personality, instructions, tools, rules, limits.
- 2EasyClaw reads the file at startup and builds the system prompt from its contents.
- 3An agent can inherit from another by referencing its file. Only redefined sections are replaced.
- 4Modifications are detected and hot-reloaded without interrupting ongoing sessions.
EXEMPLE
# Agent: Analyst ## Personality Rigorous and methodical. ## Tools - search, calculator ## Limits - No investment advice
| 07:00 | Weather briefing |
| 07:05 | News digest |
| 07:10 | Email processing |
| 2x/day | Memory distillation |
| 2x/day | Autonomous reflections |
| Every 3h | Memory shepherd cycle |
| Hourly | Memory extraction + reindex |
Long-running operations (codebase analysis, migration, regression testing) run in the background. The agent confirms the launch, then continues responding. The user can check status, pause, or cancel a task at any time.
Task lifecycle
- 1The agent identifies a long-running operation and creates a task with a unique identifier.
- 2The task runs in the background. The agent remains available.
- 3Real-time progress: percentage, current step, estimated time.
- 4Results are stored and accessible via /task status, even after session changes.
An iMessage monitoring daemon continuously polls the system database. Each incoming message spawns a fresh one-shot sub-agent with minimal permissions and a strict 300-second timeout. The sub-agent processes the request, responds, then terminates. No persistent sessions exist between messages.
One message = one agent = one session. Complete isolation.
ACP dispatch is disabled on both instances. All routing is handled through direct skills and cron jobs.
The Coordinator pattern breaks down complex tasks into sub-tasks, delegates them to the most qualified agents on different machines, and synthesizes results. The bridge ensures routing, rate-limiting, and traceability for each delegation.
Coordinator flow
- 1The coordinator receives the request and analyzes the involved domains.
- 2The task is broken into independent sub-tasks with clear success criteria.
- 3Each sub-task is assigned to the most qualified specialized agent.
- 4Results are collected, contradictions resolved, and a unified synthesis is produced.