BoxAgnts Runtime (6) — Rust + WASM, Local-First

BoxAgnts has built a local-first AI agent runtime using Rust and WebAssembly, prioritizing privacy, low latency, and offline capability over cloud-dependent architectures. The runtime compiles into a single statically-linked binary that runs entirely on the user's machine, with all tool execution sandboxed through WebAssembly modules for security. By replacing Python-based tool chains with Rust's memory-safe, concurrent execution and WASM isolation, BoxAgnts enables agents to operate on local files and systems without sending data to external infrastructure.

Over the past decade, software infrastructure has moved decisively toward cloud-native architectures. AI agents followed the same path—cloud-hosted models, remote APIs, centralized orchestration. But as privacy demands grow, infrastructure costs climb, and offline scenarios emerge, a question once considered settled is being re-examined: Should AI agents always run in the cloud? The answer is becoming less obvious. Local-first AI systems demonstrate irreplaceable value in healthcare, finance, government, and enterprise compliance scenarios. BoxAgnts chose this path from the very beginning. Privacy : Many agent workflows need access to source code, internal documentation, databases, and proprietary business processes—sending these to external infrastructure means compliance risks and security concerns. Latency : Agent systems frequently perform file operations, code analysis, and repository navigation—routing every action through remote APIs introduces unnecessary latency. Offline : Cloud-first systems assume reliable network connectivity—real-world environments frequently violate this assumption. Developers need offline coding assistants, edge-computing agents, and private infrastructure automation. BoxAgnts' solution is direct: put the runtime on the user's machine; choose local or cloud models as needed. Open a browser to http://127.0.0.1:30001 —all agent interaction happens locally. Most AI tooling uses Python—fast iteration, rich libraries, research-friendly. But runtime infrastructure has different priorities: predictable performance, memory safety, efficient concurrency, low resource overhead, portable deployment. Rust excels in all these areas. BoxAgnts chose Rust for several engineering reasons: Memory safety : Agent runtimes maintain execution state, tool registries, context stores, and orchestration graphs—as complexity grows, memory safety is no longer optional. Rust provides strong guarantees without GC pauses. Concurrency : Modern agents execute parallel tool calls, concurrent retrieval, multi-agent coordination, and async orchestration—Rust's async/await + Tokio ecosystem naturally matches these workloads. Deployment simplicity : Python environments need dependency resolution, package management, runtime configuration—Rust compiles to a single binary : No pip install, no conda, no Docker boxagnts --workspace-dir /path/to/workspace --port 30001 BoxAgnts' entire Cargo.toml workspace compiles all modules into a statically-linked executable—download, extract, run. Three steps. Tool execution is one of the hardest security challenges in AI agents. The traditional path—Agent → Python → Shell → Host System—carries enormous risk. BoxAgnts replaces the entire execution chain with WebAssembly: Agent Decision ↓ Tool Trait Interface unified abstraction ↓ WasmTool Wrapper ↓ Wasmtime Sandbox RunOption constraints ↓ WASM Module Execution isolated environment Look at how all tools are registered in boxagnts/tools-manager/src/lib.rs : php pub fn all tools - Vec<Box<dyn Tool { vec // Built-in tools Box::new AskUserQuestionTool , Box::new BriefTool , Box::new EnterPlanModeTool , Box::new ExitPlanModeTool , Box::new SleepTool , Box::new SkillTool , Box::new ToolSearchTool , // WASM tools all wrapped via WasmTool Box::new WasmTool::new "read", "file-read-component.wasm", ... , Box::new WasmTool::new "write", "file-write-component.wasm", ... , Box::new WasmTool::new "edit", "file-edit-component.wasm", ... , Box::new WasmTool::new "glob", "file-glob-component.wasm", ... , Box::new WasmTool::new "bash", "bash-component.wasm", ... , Box::new WasmTool::new "web fetch", "web-fetch-component.wasm", ... , // ... } Each WASM tool compiles once, runs cross-platform—macOS, Linux, Windows—with identical behavior. This portability is enormously important for AI ecosystems—agent tools shouldn't be fragile "works on my machine" artifacts. BoxAgnts' most important runtime abstraction is the Tool trait—every tool looks identical from the agent's perspective: php pub trait Tool: Send + Sync { fn name &self - &str; fn description &self - &str; fn permission level &self - PermissionLevel; fn input schema &self - Value; async fn execute &self, input: Value, ctx: &ToolContext - ToolResult; } The runtime doesn't care whether a tool is native Rust, WebAssembly, MCP-compatible, or a remote service—a unified interface means unified governance. All tools' permission level is checked by the same permission system; all WASM tools' execute goes through the same sandbox pipeline. Context management is one of the hidden pain points of agent systems. Most discussions focus on "context window size," but the runtime needs to think about more: context creation, persistence, compaction, expiration, sharing. BoxAgnts manages these through the boxagnts/workspace/ module. Sessions are stored as JSON files in the local workspace: php // boxagnts/gateway/src/api/chat session.rs pub async fn get sessions - Result<Vec<Session { let sessions dir = saved dir.join "sessions" ; // Read all JSON session files // Sort by creation time, newest first } Session history is entirely local—not uploaded to the cloud, not controlled by third-party services. Privacy and latency benefit simultaneously. BoxAgnts' Managed Agent mode implements the Manager-Executor architecture: Planner Agent Manager ↓ ┌──────────┬──────────┬──────────┐ │Executor 1│Executor 2│Executor 3│ │WASM Sandbox│WASM Sandbox│WASM Sandbox│ │Independent │Independent │Independent │ │capabilities │capabilities │capabilities │ └──────────┴──────────┴──────────┘ In boxagnts/query/src/managed orchestrator.rs , the system prompt defines the Manager's workflow: Each Executor has independent max turns , independent tool sets, and optional Git worktree isolation— runtime-level fault isolation, not prompt-level suggestions. BoxAgnts enforces multi-layer resource control through the WASM sandbox: | Dimension | Mechanism | Purpose | |---|---|---| | Time | wasm timeout | Prevents long-running execution | | Memory | wasm max memory size | Prevents memory bloat | | Stack | wasm max wasm stack | Prevents stack overflow | | Compute | wasm fuel | Instruction count limit | | Network | allowed outbound hosts | Outbound allowlist | | Network | block networks | IP range blocklist | | Files | work dir / map dirs | Directory access control | Without this governance, highly autonomous agents eventually become operational liabilities. BoxAgnts' skill system is a lightweight capability extension mechanism. Skills are defined as Markdown files in app/extensions/skills/ : skills/ ├── code-review/SKILL.md ← Code review ├── css-refactor-advisor/SKILL.md ← CSS refactoring advice ├── current-weather/SKILL.md ← Weather query ├── front-component-generator/SKILL.md ← Frontend component generation └── weather-forecast/SKILL.md ← Weather forecast Each SKILL.md uses YAML frontmatter to declare name, description, trigger conditions, required tools, and parameters. SkillTool loads and expands these templates, injecting results into the LLM context. Skills can be shared, composed, and reused across workspaces—capability security manifested at the application layer. AI agents are evolving from conversational apps into infrastructure systems. Local-first architecture provides privacy, low latency, and offline capability. Rust provides performance, safety, and portability. WebAssembly provides sandboxing, capability isolation, and portable execution—together, they form a powerful foundation for next-generation agent runtimes. BoxAgnts proves one thing: the future of AI agents need not be entirely cloud-native—in many scenarios, it should be local-first, capability-driven, and sandboxed by default.