Multi-Runtime Direction
The long-term architecture target, and what is true today.
CoreLayer runs as one Node.js daemon that hosts six registered runtimes in-process. The long-term target is a Rust/Tauri core supervising multiple managed runtimes through explicit permission, audit, update, and runtime protocols.
This page separates what exists from what is planned, because the two have been mixed up in earlier versions of the docs.
Today
Tauri Desktop Shell (Rust)
└─ Node.js daemon (Hono)
├─ agent (registered)
├─ tool (registered)
├─ coding (registered)
├─ memory (registered)
├─ voice (registered)
└─ scheduler (registered)
computer-control (implemented modules, NOT registered)The runtime host already provides registry, lifecycle, and status, and GET /api/runtime/components reports the health of each registered runtime. That is in-process supervision, not process isolation.
Target
Tauri/Rust Core
├─ Runtime supervisor (spawn, restart, resource limits)
├─ Runtime Protocol over IPC
├─ agent / tool / coding / memory / voice / scheduler as managed processes
└─ Computer control (Rust, native OS capability)Each managed runtime would:
- run as its own process, restartable independently
- communicate only through
@jarvis/runtime-protocol - have its own resource envelope
- be granted capabilities explicitly, never implicitly
Migration path
- Current — single daemon, module boundaries enforced by import tests and per-runtime
public-api.tsfacades - Next — extract runtimes whose failure domains already diverge (coding, voice)
- Then — move the supervisor from the Node daemon into the Rust core
- Finally — computer control behind a real native capability, not a stub
Each step keeps the HTTP contract stable, so the frontend does not change.
Why not a full Rust rewrite
The daemon's authority is not CPU-bound: it is orchestration, policy, and persistence. Rewriting it in Rust would buy little throughput and cost the iteration speed that matters while the governance model is still evolving. The places where Rust earns its keep are the supervisor and native capabilities — which is where the target puts it.
What would make this page wrong
If computer control is registered and backed by a real capability, or if a runtime starts running as a separate process with its own lifecycle, update this page in the same change. Documentation that describes the target as current is the failure mode this page exists to prevent.
Next Steps
- System Overview — what runs today
- Runtime Boundaries — the current isolation model
- Executor Governance — the closest thing to runtime supervision that exists now