TigrimOS v1.1.0 and Tiger CoWork v0.5.0 released with remote agent swarms and configurable governance
TigrimOS v1.1.0 and Tiger CoWork v0.5.0 released today bring remote agent swarm communication and configurable governance protocols to the open-source multi-agent platform.
Two Editions for Different Environments
TigrimOS v1.1.0 is a standalone app for Mac and Windows with a built-in Ubuntu sandbox that requires no Docker or cloud dependencies. Tiger CoWork v0.5.0 is Linux-native with the same feature set but designed to run directly on servers without VM overhead.
Remote Agent Swarm Communication
The headline feature enables swarm-to-swarm communication across networks. Each TigrimOS instance runs its own internal agent swarm, and in v1.1.0, these swarms can communicate with each other. The orchestrator reads the persona and responsibility of each remote node, picks the right swarm for the job, and delegates the entire task. Agents on different physical machines communicate as if they're on the same box.
This allows users to attach cloud GPU nodes for heavy inference, database servers for large-scale retrieval, while keeping a laptop as coordinator, addressing the constraint of running VMs on limited desktop hardware.
Configurable Governance Protocols
Five governance topologies are available, configurable per session:
- Star/Hub: Single orchestrator with agents executing tasks. Deterministic with no negotiation. Good for well-scoped tasks requiring predictable output.
- Blackboard: Orchestrator posts tasks, agents bid based on skill and availability. Classic distributed auction system. Good for mixed-specialty teams.
- Pipeline: Sequential handoff between agents (A finishes, passes to B). Good for structured workflows like research → draft → review → deliver.
- Mesh: Fully decentralized with any agent delegating to any other directly. No central authority. Good for open-ended research or creative tasks benefiting from multiple perspectives.
- Bus: Broadcast to all agents simultaneously, with whoever can handle it picking it up. Good for parallelizable workloads.
Additional Features
- Each agent can use a different LLM backend (Claude Code, Codex, GLM, Minimax, local Ollama, etc.)
- Sandbox isolation by default — agents cannot touch the host filesystem unless folders are explicitly mounted
- Long-running sessions with checkpoint recovery and context compression
- MCP server integration for external tooling
- Minecraft-style task monitor showing live agent activity with inter-agent interactions for debugging multi-agent flows
Upgrading from v1.0.0 requires no VM rebuild — SSH in and run a few commands.
📖 Read the full source: r/openclaw
👀 See Also
APEX Testing Benchmark Results: Qwen 3.5 Performance on Real Coding Tasks
APEX Testing benchmark results show Qwen 3.5 models' performance on 70 real GitHub coding tasks, with the 397B version dropping to 1194 ELO on master-level tasks while GLM-4.7 quantized leads local models at 1572 ELO.
OpenClaw as Infrastructure-as-Code Interface for Home Lab Management
OpenClaw transforms from AI gadget to primary computer interface for home lab management, executing tasks like configuring Traefik containers, creating Dashy configurations, and setting up Tailscale access with direct machine access.
Claude-First Analytics MCP Server: Giving AI Agents Direct Access to Web Analytics Context
A developer rebuilt their web analytics tool as an MCP server, exposing simple web analytics, trackable links, and product insight tools directly to Claude, enabling AI agents to leverage site data alongside code and database context.
80-line Python script uses Claude to auto-generate internal link suggestions, cuts linking time from 2 hours to 8 minutes
A Reddit user built an 80-line Python script that feeds an article draft and sitemap to Claude, returning relevant internal link targets with suggested anchor text — reducing manual linking time from 2 hours to 8 minutes per article.