The Agent OS Nobody Asked For (Yet)
You are building agent infrastructure. So are we. Here is what we found.
This is a technical architecture piece, not a pitch. We are going to show you code, explain design rationale, and be honest about where things work and where they do not. If you are building agent frameworks, runtimes, or platforms, some of these problems are probably keeping you up at night too.
The isolation problem
Every agent platform eventually hits the same wall. Your agent needs access to credentials (API keys, OAuth tokens, database passwords). Your agent also needs to execute arbitrary code (tools, skills, plugins). Your agent also ingests untrusted content (user prompts, web pages, other agents’ messages). Security researchers at Palo Alto Networks have named this combination a lethal trifecta. The problem is not that any one of these is dangerous – it is that all three coexist in the same process.
OpenClaw runs everything in a single Node.js process. The gateway, the skills, the credentials, the memory – one address space. Cisco, GitGuardian, and Malwarebytes have all published analyses of the attack surface. Moltbook’s breach (1.5M API tokens, 35K emails, plaintext credentials in DMs) happened because the entire database was a single trust domain with no row-level security. Two SQL statements would have fixed it. But the architecture made the mistake invisible until it was catastrophic.
The standard response is defense in depth: input validation, output sanitization, permission checks, sandboxing at the application layer. These are necessary. They are not sufficient. Every one of them is a policy that can be bypassed, misconfigured, or forgotten. The question we asked fifteen months ago: is there an architectural approach where the dangerous code paths simply do not exist?
Three-isolate architecture
BentOS runs on a virtual machine with three isolation levels. This is not a metaphor – these are separate Dart isolates with no shared mutable state.
+------------------+
| KERNEL | nanoben kernel: process table, VFS, syscall dispatch
| (Isolate 1) | Owns: file descriptors, process hierarchy, /dev tree
+------------------+
|
System Bus (message passing only)
|
+------------------+
| FIRMWARE | Device drivers: NativeCpuFirmware, storage, network
| (Isolate 2) | Owns: API keys, model endpoints, hardware access
+------------------+
|
CpuPort (interrupt channel only)
|
+------------------+
| USERLAND | Agent code: skills, tools, automation, your code
| (Isolate N) | Owns: nothing privileged. One isolate per task.
+------------------+Each userland task is a separate isolate spawned by the CPU firmware. The agent’s code runs in userland. API keys live in firmware. There is no shared memory between them. There is no code path from userland to firmware credentials. This is not a permission check – it is a property of the Dart isolate model. Isolates do not share heap memory. Period.
The only channel from userland to the outside world is a CpuPort – a thin wrapper around a Dart SendPort that constrains communication to a sealed interrupt protocol:
class CpuPort {
final SendPort _port;
void interrupt(CpuInterrupt interrupt) {
if (interrupt is SyscallInterrupt) {
_port.send({
'type': 'SyscallInterrupt',
'data': interrupt.toJson(),
'responsePort': interrupt.responsePort,
});
} else {
_port.send(interrupt);
}
}
Future<Result<T>> syscall<T>(int number, List<dynamic> args) async {
final responsePort = ReceivePort();
interrupt(SyscallInterrupt(number, args, responsePort.sendPort));
final message = await responsePort.first;
responsePort.close();
// Deserialize Result from kernel response...
}
}Userland issues syscalls. The kernel decides whether to honor them. The firmware never sees the request unless the kernel explicitly routes it through the system bus. An agent that has been compromised through prompt injection can send whatever syscalls it wants – but it cannot escalate beyond the syscall interface, because there is nothing else. No reflection. No shared references. No escape hatch besides the one we built.
This is the same pattern real operating systems use. Userland does not get to touch hardware. The kernel mediates all access. The novelty is applying this to AI agent runtimes, where the “hardware” includes API keys and model endpoints.
The CPU Protocol
The CPU Protocol (BCpP) is the contract between the nanoben kernel and whatever execution substrate runs agent code. It follows a client-dispatcher pattern with a URI-based addressing scheme:
cpu://{host}:{port}/task # spawn, spawnUri
cpu://{host}:{port}/task?id={id} # terminate, pause, resume, query
cpu://{host}:{port}/tasks # list all
cpu://{host}:{port}/system/stats # resource utilization
cpu://{host}:{port}/interrupts # register interrupt handlersThe verb set is intentionally small:
enum CpuVerb {
spawn, // Shared code (Isolate.spawn) -- kernel extensions
spawnUri, // Isolated code (Isolate.spawnUri) -- userland programs
terminate,
pause,
resume,
query,
register, // Interrupt handler registration
}Two spawn verbs matter architecturally. spawn creates an isolate that shares code with the kernel – used for trusted system processes. spawnUri creates an isolate from a URI with no code sharing – used for arbitrary userland programs. The difference maps directly to Dart’s Isolate.spawn (same code, different heap) versus Isolate.spawnUri (different code, different heap). A spawnUri task physically cannot call kernel functions because the symbols do not exist in its isolate.
// Kernel-trusted process (shares kernel code)
final taskId = await cpuClient.spawnTask(myKernelExtension);
// Userland program (isolated code, no kernel access)
final taskId = await cpuClient.spawnTaskUri(
Uri.file('/path/to/agent_program.dart'),
['--config', '/etc/agent.conf'],
);Task lifecycle is explicit: spawning -> running -> terminated, with paused as a reachable state from running. Pause returns a Capability token (Dart’s built-in isolate pause mechanism) that is required for resume – you cannot resume a task you did not pause.
The interrupt system
Communication from userland to kernel uses a sealed class hierarchy for type safety:
sealed class CpuInterrupt {}
final class SyscallInterrupt extends CpuInterrupt {
final int number; // Syscall number (e.g., SYS_WRITE, SYS_OPEN)
final List<dynamic> args; // Syscall arguments
final SendPort responsePort; // Where kernel sends the result
}
final class ExceptionInterrupt extends CpuInterrupt {
final Exception exception;
final StackTrace? stackTrace;
}
final class ErrorInterrupt extends CpuInterrupt {
final Error error;
final StackTrace? stackTrace;
}The sealed keyword is load-bearing. Dart’s sealed classes enable exhaustive pattern matching at compile time. When the CPU firmware dispatches an interrupt, the compiler guarantees every variant is handled:
switch (interrupt) {
case SyscallInterrupt():
port.send((taskId, interrupt) as CpuInterruptHandlerArgs);
case ExceptionInterrupt():
port.send((taskId, interrupt) as CpuInterruptHandlerArgs);
case ErrorInterrupt():
port.send((taskId, interrupt) as CpuInterruptHandlerArgs);
}No default branch. No “this should never happen” comments. If someone adds a new interrupt type, the code does not compile until every dispatcher handles it. This is the kind of guarantee dynamic languages cannot provide, and it matters when the interrupt boundary is your entire security surface.
The kernel registers interrupt handlers via SendPort, so interrupts dispatch into the kernel’s isolate where they can directly modify kernel state (process table, file descriptors, signal handlers). This avoids the serialization overhead of routing through the system bus for high-frequency operations like syscalls.
Why this matters for multi-language runtimes
The CPU Protocol is abstract. NativeCpuFirmware implements it using Dart isolates. But the protocol does not require Dart isolates. It requires:
- An execution substrate that can spawn tasks with an entrypoint
- Lifecycle control (pause, resume, terminate)
- A message channel for interrupt delivery
- Heap isolation between tasks
A JavaScript runtime could satisfy these constraints using Web Workers or Node.js worker threads. A WebAssembly runtime could satisfy them using WASM modules with linear memory isolation. The protocol does not care. It defines the contract; the firmware implements the physics.
This is the mechanism by which BentOS becomes a multi-language platform. JsCpu would implement the CPU Protocol using V8 isolates or worker threads. WasmCpu would implement it using WASM sandboxes. The kernel remains the same. The system bus remains the same. The security model remains the same. Only the firmware layer changes.
We have not shipped JsCpu yet. The protocol is designed for it; the implementation is not written. We mention it because the abstraction boundary is real and tested (the protocol has its own conformance test suite), and because multi-language interoperability feels like a problem the ecosystem needs to solve collectively.
POSIX in a virtual machine
BentOS userland implements POSIX.1-2024 syscalls. Not a subset chosen for convenience – the actual specification, implemented methodically. The current syscall table includes open, close, read, write, mkdir, rmdir, chdir, chroot, chmod, pipe, dup, dup2, symlink, rename, unlink, fsync, ftruncate, getpid, getppid, setsid, setpgid, and more. There is a POSIX shell (not a toy – it has a proper lexer, parser, AST, and execution engine for pipelines, redirections, compound commands, and builtins).
Why POSIX? Because it is the most battle-tested process model in computing history. Instead of inventing a new way for agents to manage files, processes, pipes, and signals, we implemented the one that Unix got right fifty years ago. An agent running on BentOS manages files the same way any POSIX program does. When we eventually expose this to agents, the semantics are already defined and documented – by the IEEE, not by us.
The virtual filesystem is layered: each process has its own file descriptor table, the kernel maintains a global inode table, and device files (/dev/llm/, /dev/tty/) map hardware abstractions through the VFS layer. LLMs are accessed as device files – open('/dev/llm/claude') returns a file descriptor. The model is infrastructure. The agent is software running on that infrastructure.
Bounded composition
Every agent platform faces the capability packaging problem. OpenClaw has 49 bundled skills plus ClawdHub. The natural trajectory is npm: unbounded registry, anyone publishes, discovery degrades with scale, quality is uneven, and you end up with left-pad incidents.
We have been experimenting with bounded composition. The idea: capabilities exist in a finite coordinate space along five axes (craft, discipline, domain, tools, meta). Each coordinate has at most one canonical package. Instead of discovering packages by searching keywords, you navigate a coordinate system.
The composition model uses two binding forces: requires (hard dependency – will not function without) and attracts (compositional affinity – works better together). These are declared in XML package definitions:
<atom name="technical-writing" kind="skill" axis="craft" path="craft/writing/technical">
<coordinate axis="craft" path="craft/writing/technical" />
<attracts axis="domain" path="domain/software/*" />
<requires axis="tools" path="tools/instruments/quest-forge" />
</atom>The theoretical property: network effects compound with participation rather than degrading with volume. When someone improves the package at craft/writing/technical, every agent using that coordinate gets the improvement. Discovery does not degrade because coordinates are finite and navigable – there is no “page 47 of search results” problem.
We are honest about the limits: we do not have enough users to know whether this works at scale. The unbounded-registry model has well-documented failure modes, and we think bounded alternatives deserve exploration while the ecosystem is young enough to try them. But “deserves exploration” is not “proven at scale.”
The communication problem
Every agent framework has its own message format, identity model, and capability description scheme. The bridging cost grows quadratically with the number of incompatible protocols. We are adding new ones monthly.
Over a year ago we designed ACCP (Agent Communication and Context Protocol) as an open standard. Key design decisions:
- Capability-based identity: agents present what they can do, not tool function signatures. An agent’s identity is its capabilities, not its API surface.
- Fabric-based architecture: social boundaries define interaction scope, inspired by Matter protocol’s fabric model. Agents join fabrics; fabrics define trust.
- Transport agnosticism: the protocol specifies message semantics, not delivery. Implementations bind to transports (HTTP, WebSocket, MQTT, messaging apps).
- GPG security model: cryptographic identity, signed messages, encrypted communications at the protocol level.
- No human/AI distinction: the protocol does not differentiate between human and AI agents. Both are agents with capabilities.
We designed ACCP for the ecosystem, not for BentOS specifically. The spec explicitly invites collaboration. We raise it because the communication standardization problem is going to get worse before it gets better, and having a concrete proposal on the table (even an imperfect one) seems more useful than waiting for consensus to emerge organically.
What we have not shipped
Architectural depth without honesty about gaps is just marketing with extra steps. Here is what does not exist yet:
No public release. BentOS is proprietary. The open-core model (runtime open, enterprise proprietary) is intent, not reality. Fifteen months of infrastructure work, zero users. OpenClaw shipped in six weeks and found 147,000.
No JsCpu. The CPU Protocol is designed for it. The implementation is unwritten. The JavaScript ecosystem – the largest developer community in the world – cannot build on BentOS today.
No first-run UX. There is no npm install, no brew install, no app store listing. The Flutter distribution advantage is theoretical until there is software to distribute.
No community. Zero contributors. Zero stars. Zero external feedback. Every design decision has been validated only by the founding team. That is a fragility, not a strength.
Skill breadth. OpenClaw ships 49 skills and a community registry. The bounded composition model is architecturally interesting and practically empty. Network effects require a network.
We mention these not as false modesty but because platform engineers evaluate infrastructure on what ships, not what designs well. We know the difference.
The convergence observation
We built BentOS over fifteen months without knowing OpenClaw existed. When we finally compared architectures, we found seven independent convergence points: transport agnosticism, agent-as-citizen, communication/execution separation, proactive behavior, persistent identity, persistent memory, model agnosticism.
Both projects, independently, chose file-based persistent identity. Both separated communication from execution as distinct architectural concerns. Both concluded that the LLM is a swappable brain, not the agent’s self. Both designed for proactive agents that reach out before being asked.
Seven convergence points from independent designs is not two teams copying each other. It is convergent evolution under identical selection pressures. These are not arbitrary design choices. They are responses to fundamental properties of the problem space.
Where the designs diverge is at the infrastructure layer. OpenClaw is an application-level agent framework – a gateway daemon with a skill plugin system, well-suited to rapid iteration and community contribution. BentOS is an operating-system-level runtime – a virtual machine with process isolation, a kernel, and a syscall interface, better suited to the security and composition problems that emerge at platform scale.
These are complementary, not competing. The stack needs application frameworks. The stack also needs secure runtimes. The stack also needs communication standards. No single project covers all three.
An invitation
If you are working on any of these problems – agent isolation, multi-language runtimes, capability composition, communication protocols – we would like to hear from you. Not because we think we have the answers, but because solving them independently and in parallel is a luxury the ecosystem probably cannot afford.
The CPU Protocol conformance test suite could validate alternative firmware implementations. The ACCP spec could evolve through multi-party input. The bounded composition model could benefit from real-world stress testing we cannot do alone.
We have been building quietly for over a year. The architecture is real, tested, and – we think – worth examining. The market has validated the thesis that people want persistent, proactive, secure AI agents. The question now is how to build the infrastructure that makes that possible at scale, safely, across languages and platforms.
That is not a question any one team answers alone.
The code and specs are available for discussion. Reach out.