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 s.
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:
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
:
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:
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:
// 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.