Research·2026-03-12·Synerthink
The ABI Behind Replayable Compute
Why Dotlanth starts with a tiny register VM, a versioned syscall ABI, and recorded events
Why Dotlanth starts with a tiny register VM, a versioned syscall ABI, and recorded events
AI systems fail in ways that ordinary request handlers do not. A single run can read state, call tools, emit logs, serve traffic, and make decisions that depend on timing and prior effects. When something goes wrong, the hard question is usually not whether the code path exists. It is what actually happened in that specific run.
Most modern runtimes are poorly shaped for that question. Side effects can come from anywhere: a framework starts a listener, a library writes to stdout, a helper opens a socket, a callback mutates shared state. Logs and traces help, but they are reconstructions. They describe a run from the outside after the fact. They do not define the run.
If the goal is reliable infrastructure for AI agents and autonomous systems, that is not enough. You need an execution model that makes the boundary between computation and side effects explicit, narrow, and recordable.
Dotlanth is trying to build replayable compute for AI-native systems. That sounds like a determinism problem, but the first failure mode is usually simpler: the system cannot explain where the world was touched.
In a conventional stack, computation and effects are interleaved across the process.
That works for throughput-oriented software because the dominant concern is serving requests, not replaying them. But for autonomous systems, replayability matters much earlier.
An agent run is not just a stateless function call. It has intent, intermediate state, and external effects. It may inspect prior history, route a request, decide on an action, and persist the result. If a run behaves incorrectly, you need more than "we have some logs." You need a durable, ordered account of the effects that crossed the runtime boundary.
The deeper issue is not which instruction set should we use. It is where the ABI between compute and the outside world lives, and whether that boundary is narrow enough to record and replay with confidence.
The key insight behind DotVM is that replayable infrastructure does not start with a large instruction set or a perfect sandbox. It starts with a narrow contract: computation stays inside the VM, side effects cross one syscall boundary, and every crossing yields a structured event.
That changes the mental model of the runtime. Instead of treating logging, networking, and response handling as ambient host behavior, Dotlanth treats them as explicit operations invoked by the VM. The interpreter can stay small. The host can stay separate. The event stream becomes the durable record of what the run did at its effect boundary.
Mental model
program -> VM instructions -> syscall boundary -> host effect
|
v
structured event
|
v
DotDBA register VM fits that model well. Registers make operand flow explicit. Syscall arguments and results can move through a stable ABI without hidden host callbacks or a large compiler surface. For an early system, that matters more than sophistication.
Dotlanth does not require strict determinism everywhere in v26.1. It requires that the parts of execution which touch the outside world become visible, typed, ordered, and recordable.
Tiny example
r0 = "0.0.0.0:8080" syscall HttpServe, r0 -> r1 r2 = 200 r3 = "Hello from Dotlanth" syscall HttpRespond, r1, r2, r3 -> r4 halt
In record mode, those calls do not just produce host behavior. They also yield structured events that can be persisted, inspected, and eventually replayed with much stronger guarantees than conventional logs.
For v26.1, DotVM is a small interpreter with a deliberately tiny ABI and instruction surface.
The initial instruction set is intentionally narrow: load constants, move values between registers, invoke a syscall, and halt or return. That is enough to run a tiny program for hello-api and route requests, which is exactly the point. This release is not trying to prove a full general-purpose runtime. It is trying to validate the architectural seam.
The syscall ABI is equally constrained. Syscalls are identified by a small, versioned enum. Arguments and results move through registers. Each syscall emits a structured event, and record mode persists those events to DotDB.
This decision also clarifies the security model. Capabilities are checked at syscall invocation, not at arbitrary instruction execution points. That keeps policy enforcement aligned with the only place where policy materially matters: where the VM asks to touch the outside world.
The tradeoff is that some rough edges are accepted early. A tiny ISA makes the system easier to stabilize, but more complex routing and templating will feel awkward until the instruction set grows. That is a reasonable cost for a first architecture pass.
A stack machine would simplify some compiler paths, especially for very small programs. But it weakens the explicitness of the ABI boundary. For Dotlanth, register passing is not cosmetic. It makes syscall inputs and outputs visible in a way that maps cleanly to event recording and future inspection.
WASM is powerful, portable, and mature. It is also the wrong starting point here. Embedding a WASM runtime would introduce a large semantic surface before Dotlanth has validated its own execution model. The problem was not how do we execute arbitrary code safely. The problem was how do we make a tiny amount of computation legible enough to record and replay.
The fastest demo would have been to skip the VM entirely and route requests directly through host code. That would also have undermined the architectural question the project is trying to answer. Without a VM boundary, syscalls stop being a runtime contract and become ordinary conventions.
This decision has clear benefits.
It also creates real obligations.
A small syscall ABI does not look like much on paper. But it opens the door to a more reliable class of systems.
Reliable AI agents will need more than observability dashboards. They will need execution artifacts that can explain what happened, why a capability was used, what state was observed, and which external effects were produced. That starts with an ABI that treats effects as explicit events rather than incidental behavior.
Before a deterministic distributed system can coordinate many machines, it has to make one run understandable.
A narrow syscall boundary, a recorded event model, and a runtime that can show its work: those are some of the first practical building blocks toward deterministic AI infrastructure.