Multi-host remote operations with AI agent orchestration.
A structured workflow for managing multiple Linux servers through OpenClaw — with sub-agent dispatch, model tiering, safety barriers, and a self-learning host cache system.
Instead of running every SSH command in your main chat context (bloating tokens, mixing concerns), Host Ops dispatches remote tasks to isolated sub-agents with focused prompts. Each sub-agent:
- Has its own clean context (no pollution from your chat history)
- Can use a cheaper model for routine tasks (flash) or a smarter one for complex work (pro)
- Auto-discovers server paths and caches them for next time
- Reports back structured results that the main agent verifies before showing you
You: "Check my blog server"
↓
Main agent matches template → spawns health-check sub-agent (flash, $0.003)
↓
Sub-agent reads host cache → skips path discovery → runs checks → reports
↓
Main agent verifies → shows you the report
Copy and paste this to your OpenClaw instance:
"Please install the host-ops skill from https://github.com/Jees996/openclaw-host-ops. Clone it into my skills directory, then configure it for my servers. Ask me for the hostname, IP, SSH port, username, and key path for each server I want to manage. Create the host inventory and cache files based on my answers."
OpenClaw will:
- Clone this repo into
~/.openclaw/workspace/skills/host-ops/ - Ask you about your servers one by one
- Fill in
references/host-inventory.mdwith your details - Create initial cache files for each host
- Run a test health check to verify connectivity
# Clone into your OpenClaw workspace skills directory
cd ~/.openclaw/workspace/skills
git clone https://github.com/Jees996/openclaw-host-ops.git host-ops
# Or if you use a different workspace path:
# cd <your-workspace>/skills
# git clone https://github.com/Jees996/openclaw-host-ops.git host-ops- Edit
references/host-inventory.md— replace the template with your actual servers:
### my-blog-server
- **Role:** Personal blog
- **SSH:** `ssh -p 2222 -i ~/.ssh/id_ed25519 admin@1.2.3.4`
- **OS:** Ubuntu 24.04
- **Sudo password:** `yourpassword` — **must ask before any sudo**- Create cache files — copy
references/host-cache.example.mdfor each host:
cp references/host-cache.example.md references/my-blog-server-cache.md-
Adapt task templates — if your blog publishing workflow uses a specific tool, update the
blog-publishtemplate inreferences/task-templates.mdto reference your script or API. -
Test — just say "check my blog server" to your OpenClaw. It should trigger the host-ops skill and run a health check.
skills/host-ops/
├── SKILL.md ← Main skill definition (loaded on trigger)
└── references/
├── host-inventory.md ← Your server list (you edit this)
├── task-templates.md ← Prompt templates for sub-agents
└── <host>-cache.md ← Auto-discovered paths (sub-agents maintain)
| Step | Who | What |
|---|---|---|
| Intent parsing | Main agent | Match keywords to host + template |
| Prompt filling | Main agent | Fill template with user's values |
| Model selection | Main agent | flash for routine, pro for complex |
| Task execution | Sub-agent | Isolated context, focused prompt |
| Cache update | Sub-agent | Append new discoveries to host cache |
| Result verification | Main agent | Check URL reachable, diff correct, etc. |
| Task | Model | Why |
|---|---|---|
| Publish article, health check | flash | Routine, low risk, cheap (~$0.003/task) |
| Edit server files, install software, audit | pro | Precision matters, high risk (~$0.04/task) |
- sudo barrier: Sudo passwords never auto-passed to sub-agents — user must approve
- Backup-first: All file edits create
.bakbefore writing - Command preview: Destructive commands previewed before execution
- Verification layer: Sub-agent output checked before reaching user
- Isolated context: Sub-agents have zero knowledge of main chat history
- Not an SSH client. Uses your existing SSH setup (
~/.ssh/config, key pairs). - Not a replacement for blog publishing skills. It orchestrates them — your blog skill still handles the actual API calls.
- Not a monitoring daemon. It runs on-demand when you ask. Pair with cron for scheduled checks.
Host Ops is generic by design. The blog-publish template expects you to have a blog publishing tool (script or API). Here are common patterns:
Update the template to point to your publish script:
1. Run: python3 skills/my-blog-skill/scripts/publish.py new --title "..." --content "..."
1. POST https://yourblog.com/wp-json/wp/v2/posts with auth header
1. Write markdown to content/posts/
2. Run: cd /path/to/site && hugo && rsync public/ user@host:/var/www/
- Add to
references/host-inventory.md - Copy
references/host-cache.example.md→references/<host-id>-cache.md - Add or adapt task templates
- Update host matching keywords in SKILL.md Step 1
Host Ops auto-discovers:
- Service names and log paths
- Database type and location
- Open ports and panel software
- Web root and config directories
These are cached so subsequent tasks skip the discovery phase.
Q: Why sub-agents instead of SSH in the main session? A: Isolated context prevents token bloat. Main session stays clean. Sub-agents use cheaper models.
Q: What if the sub-agent fails? A: Main agent reads the sub-agent's session history, diagnoses the issue, retries with pro model if needed, or escalates to you.
Q: Can I run commands on multiple servers at once? A: Yes. Host Ops supports parallel sub-agent dispatch. "Check all servers" spawns one sub-agent per host.
Q: Does this store my passwords? A: The host inventory file stores SSH connection info, but authentication relies on your existing SSH keys. Sudo passwords are only passed to sub-agents with your explicit approval per task.
MIT © Lee