About the role
Level: Mid-level (2–5 years experience) Location: SF Bay Area/Singapore About Runta Runta builds runtime infrastructure that lets AI agents execute reliably over long time horizons: run agents efficiently, govern what they can reach, and record what they did. Workloads that run for hours or days break the assumptions web infrastructure is built on. An agent can fan out fifty sub-tasks in a second and then go idle for ten minutes, must survive instance recycling mid-run, and needs to snapshot, resume, and branch its execution state the way developers branch code. We’re building the substrate that makes this possible. We’re a small, well-funded team, moving fast.
The Role This is the foundation of Runta. You will build the execution engine itself: the layer where agent processes actually run, get snapshotted, get resumed on different hardware, and recover from crashes without losing state. Runta does three things: run, govern, record. This role owns run and builds the mechanisms that make record trustworthy. When we say an agent’s execution can be paused for a week and resumed byte-for-byte, or branched into three parallel explorations, or replayed to audit exactly what happened, the machinery behind those guarantees is what you build. This is kernel-and-VMM-layer work, not orchestration-layer work. The problems live at memory layout, syscall boundaries, context switch costs, and crash recovery, not at the Kubernetes API. What You’ll Do Design and build snapshot/resume/branch mechanics for long-running agent processes: memory capture, copy-on-write strategies, restore latency on the critical path Build crash recovery for stateful execution units: agents that run for days will see every failure mode the platform has Own the microVM execution layer: guest lifecycle, device model decisions, boot/restore time optimization Make execution recordable: the hooks and guarantees that let us reconstruct exactly what an agent did Work at the boundary between the runtime and the isolation layer: what state is safe to persist, what must be re-established on resume Set the technical bar for the systems team as an early engineer The Problems You’d Be Solving A snapshot of a running agent must capture memory, file descriptors, and in-flight state. What can be made copy-on-write, what must be flushed, and what’s the restore-latency budget? An agent resumed on a different machine after three days: what invariants must hold, and how do you verify them cheaply? Branching one execution into N: how do you share pages and storage so N branches don’t cost N× resources? A crash mid-snapshot: how do you make the whole pipeline atomic enough that recovery is boring? If you read those and started sketching answers, we want to talk to you. What We’re Looking For You’ve built systems at the engine level: an OS kernel, a hypervisor or VMM (KVM, Firecracker, cloud-hypervisor, Xen), a database storage engine, or a language runtime (JVM, Go runtime, V8 internals) Muscle memory for memory layout, syscall boundaries, context switch costs, and crash recovery: you’ve debugged problems where timing and state transitions mattered, not just logic You can reason about copy-on-write, page sharing, and dirty tracking from first principles Comfort working close to the metal in Rust, C, or C++ Staff level: you’ve also owned the architecture of such a system and made trade-offs you can defend years later
