The Multi-Runtime Architecture

Part 3 of the VIMS Blog Network. VIMS unifies nine agent runtimes.

---

The Runtime Problem

Most agent frameworks are monolithic: they ship one runtime, one way of executing agents, one language ecosystem. If that runtime does not fit your use case, you fork it or you leave.

But agents are not one-size-fits-all. A Rust-based runtime offers memory safety and binary portability. A Python runtime gives you the entire ML ecosystem. A TypeScript runtime plugs into the Node.js package universe. A Go runtime compiles to a single static binary with zero dependencies. Different languages, different strengths, different deployment profiles.

VIMS solves this by being runtime-agnostic. It ships nine agent shells (each a distinct runtime with its own language, tool ecosystem, and isolation model) unified under a single fleet manager. You pick the right shell for the job. You can run multiple shells simultaneously. And you can coordinate them.

The Nine Shells

Shell	Language	Strength
OpenClaw	TypeScript / Node	Full-featured agent with plugin ecosystem, pnpm-based
VIMSBot	In-process (WebSocket)	Lightweight, runs inside the VIMS daemon, no Docker needed
ZeroClaw	Rust	Memory-safe, compiled binary, minimal footprint
NanoClaw	TypeScript / Node	Lightweight, built on the Claude Agent SDK
NemoClaw	Python (NeMo)	NVIDIA's generative AI framework, deep ML integration
MiroFish	Python (PyInstaller)	Multi-agent swarm intelligence simulation engine
PicoClaw	Go	Single static binary, zero runtime dependencies, ideal for edge devices
Hermes	Python (pipx)	Personal agent with CLI and messaging gateway
OpenFang	Rust (Tauri)	Agent operating system with WASM tool sandboxing and fuel metering

Each shell has different characteristics that make it suitable for different tasks:

Rust Shells: ZeroClaw and OpenFang

Rust runtimes compile to native binaries: no interpreter, no runtime dependency, no garbage collection pauses. ZeroClaw is a minimal-footprint agent that runs anywhere a binary can execute. OpenFang is a full "agent operating system" with WASM-based tool sandboxing and fuel metering: tools execute in a WebAssembly sandbox with computational resource limits, adding an extra layer of security beyond what VIMS's OS-level governance provides. (Blog 03: Security First)

Python Shells: NemoClaw, MiroFish, and Hermes

Python runtimes plug into the ML ecosystem natively. NemoClaw is built on NVIDIA's NeMo framework: it has deep integration with GPU-accelerated inference, fine-tuning pipelines, and the broader NVIDIA AI stack. MiroFish is a multi-agent swarm intelligence simulation engine: it models emergent swarm behavior, where agents share observations and self-organize. Hermes is a personal agent with a CLI and messaging gateway, designed for conversational interaction.

TypeScript Shells: OpenClaw and NanoClaw

TypeScript runtimes leverage the Node.js ecosystem. OpenClaw is a full-featured agent with a plugin architecture and pnpm-based dependency management; it is the most extensible shell, with a rich tool catalog and community plugin support. NanoClaw is a lightweight alternative built on the Claude Agent SDK: minimal overhead, fast startup, ideal for ephemeral tasks.

Go Shell: PicoClaw

Go compiles to a single static binary with zero runtime dependencies. PicoClaw is the edge-device shell: it runs on ARM boards, SBCs, and embedded systems where installing a Node.js or Python runtime is impractical. If you need an agent on a Raspberry Pi or a K3s edge node, PicoClaw is the answer.

In-Process Shell: VIMSBot

VIMSBot runs inside the VIMS daemon itself, communicating via WebSocket. No Docker container, no separate binary, no IPC overhead. VIMSBot is the default shell for agents that need to be always-on with minimal resource usage. When you mint an agent on the marketplace and bind it to a VIMS instance, VIMSBot is the default. (Blog 10: Agent Marketplace)

Cross-Runtime Coordination

The power of multiple runtimes is coordinating them. VIMS's fleet manager treats all shells uniformly: every instance, regardless of shell type, has a unique ID, a status, a gateway URL, and a set of registered tools. The operator layer abstracts away the differences.

This means you can build a pipeline where:

• A Hermes instance receives a user request via its messaging gateway and does initial intent parsing
• Hermes dispatches a subtask to a ZeroClaw instance for high-performance data processing
• ZeroClaw's output is sent to an OpenClaw instance that uses a plugin to generate a visualization
• OpenClaw posts the result to a team room via the channel API (Blog 11: Flow and Teams)

Each agent runs in its native runtime, uses its native tools, and communicates via the unified gateway protocol. The fleet manager handles the routing: you dispatch tasks by instance ID, not by shell type.

The Fleet Manager

The fleet manager tracks every running instance across every shell. It provides:

• Unified status: see all instances, their shells, their statuses, and their resource usage in one view
• Lifecycle control: start, stop, pause, resume, and delete any instance regardless of shell
• Fleet-active selection: set a default instance that user-level chat and hotkeys route to
• Cross-shell dispatch: send a task from one instance to another, even across different shells
• Broadcast: send a message to all instances of a specific shell type, or to all instances period

The fleet manager is the control plane. The shells are the data plane. You manage from one place; execution happens everywhere.

Per-Instance Model Control

Every agent instance can use a different inference provider. This is critical: the shell type and the model are independent choices.

• Instance A (OpenClaw) runs on your local vLLM serving a 70B model, free, private, on your GPU
• Instance B (NanoClaw) runs on a frontier cloud API via an API key, for GPT-4-class reasoning
• Instance C (Hermes) runs on Ollama with a 7B quantized model, lightweight, CPU-only, for simple tasks
• Instance D (ZeroClaw) runs on a different cloud provider, for redundancy or specialized capabilities

You assign the right model to the right agent for the right task, and manage them all from one place. That is what makes mixed-model fleets practical.

Runtime Distribution: github.com/HelloVIMS/Runtimes

VIMS runtimes are built, signed, and distributed from a public repository: github.com/HelloVIMS/Runtimes. It is a binary distribution pipeline.

How It Works

Every week, GitHub Actions clones each upstream shell repository, builds it for five targets (darwin-arm64, darwin-amd64, linux-amd64, linux-arm64, windows-amd64), and publishes the binaries as SHA-keyed releases. Each release tag is <shell>-<sha12>, where <sha12> is the first 12 characters of the upstream commit. Every binary is traceable to an exact commit: you can reproduce any build from its tag.

Per-shell SHA-keyed caching means re-runs against unchanged upstreams are near-instant. If OpenClaw had a new commit but ZeroClaw did not, only OpenClaw is rebuilt. This keeps the pipeline efficient even with nine upstreams.

Shipped With VIMS

Every VIMS update ships the latest versions of all runtimes. When you update VIMS, you get the newest builds of every shell, with no separate runtime update step and no manual binary management. The runtimes are embedded in the VIMS binary and extracted at startup.

This ensures runtime-version compatibility. The VIMS team verifies that each runtime version works with the VIMS operator layer before shipping. You never end up with a runtime that is incompatible with your VIMS version: if it shipped, it works.

Trust Model

Binaries are reproducible from the commit SHA referenced in the release tag. Build provenance is recorded in each release's notes: CI run URL, timestamp, and build environment. You can independently verify that a binary was built from a specific commit by rebuilding it yourself.

Swarms

Some tasks are too complex for a single agent. VIMS supports swarms: coordinated groups of agent instances that work together on a problem.

Swarm Topologies

VIMS supports eight swarm topologies, each suited to a different coordination pattern:

• Star: one coordinator fans out to N workers, collects results. Best for parallelizable tasks with a clear decomposition.
• Mesh: all agents talk to all others. Best for small swarms where cross-communication is essential.
• Pipeline: sequential chain A → B → C. Best for multi-stage processing where each stage's output feeds the next.
• Ring: circular message passing. Best for consensus, voting, and iterative refinement.
• Hierarchy: tree structure with manager layers delegating to sub-teams. Best for large swarms that need organizational structure.
• Broadcast: one leader broadcasts to all; agents work independently, results merged. Best for parallel exploration.
• School: MiroFish-optimized emergent swarm; agents share observations and self-organize. Best for research and discovery tasks where the optimal decomposition is unknown.
• Map-Reduce: split work into parallel map tasks, then reduce/aggregate results. Best for data-parallel workloads.

Swarm Roles and Composition

A swarm has roles (coordinator, worker, specialist), each backed by one or more agent instances. A role specification includes the shell type, the number of replicas, and the prompt that defines the role's behavior.

This is where multi-runtime swarms shine. A research swarm might have:

• An OpenClaw coordinator that decomposes the research question
• Three ZeroClaw workers that do high-performance data gathering
• A NemoClaw specialist that runs ML-based analysis on the gathered data
• A Hermes summarizer that synthesizes the results into a report

Each role uses the shell best suited for its task, and the swarm topology defines how they communicate. The fleet manager handles the dispatch; the swarm controller orchestrates the lifecycle. (Blog 11: Flow and Teams)

Swarm Deployment

Swarms can deploy in three modes:

• Direct: agents run as native processes on the host. Fastest, least isolated.
• Docker: each agent runs in its own container. Isolated, reproducible, slightly slower.
• Kubernetes: agents run as pods. For large-scale swarms that need orchestration, auto-scaling, and cross-node scheduling.

The deployment mode is per-swarm, not per-instance. A swarm can start in direct mode for development, switch to Docker for testing, and deploy to Kubernetes for production, without changing the swarm definition.

Swarm Presets

VIMS ships with built-in swarm presets: research teams, code review swarms, moderator-plus-judges configurations. You can create custom swarms by specifying member specs explicitly or by modifying a preset. Swarms scale (add workers, add reviewers) without restarting.

Swarms and Security

Every swarm member's actions are governed by its own security policy and HITL gates. A swarm extends the security model. The coordinator's dispatches are logged, each member's tool calls are audited, and high-risk actions hit approval gates regardless of whether they came from a single agent or a swarm member. (Blog 03: Security First)

Swarms and Identity

Each swarm member carries its NFT identity into the swarm. When a swarm is dispatched across a team roster, members join the team room as identified participants: their actions are attributable, their reputation is on-chain, and their earnings (if any) flow to their TBA wallets. (Blog 08: Agent Identity, Blog 09: Agent Wallets)

When to Use Swarms

Swarms are not always the answer. For simple tasks (a single question, a single tool call, a single document summary), a single agent is more efficient. Swarms add coordination overhead.

Use swarms when:

• The task is decomposable: it can be broken into independent or semi-independent subtasks
• The task requires diverse capabilities: different agents with different tools and different models
• The task benefits from parallelism: multiple agents working simultaneously reduces wall-clock time
• The task needs cross-checking: multiple agents reviewing each other's work improves quality

For everything else, a single agent instance, running on the shell that fits the task with the model that fits the budget, is the right choice.

The Runtime Contract

The multi-runtime architecture is a contract:

1. Right tool for the job. Nine shells, each with different strengths; pick the one that fits your task.
2. Coordinate across runtimes. The fleet manager unifies all shells under one control plane.
3. Per-instance model control. Each agent uses its own inference provider, local or cloud, no forced coupling.
4. Always up to date. Runtimes ship with VIMS updates, SHA-keyed for reproducibility.
5. Swarms compose runtimes. Multi-runtime swarms put the right shell on each role.

This is what makes VIMS agents production-grade. They run on the shell that fits, powered by the model that fits, coordinated at the scale that fits, all governed, all audited, all unified under one operating system.

---

Previous: Local-First AI Next: Security First: HITL Governance and Sandboxing