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

Nice to have: CRIU or live-migration experience, io_uring, experience making cold starts fast at scale.

You Should Genuinely Care About AI

The runtime you build determines what agents can do: how long they can think, how cheaply they can explore in parallel, how trustworthy their history is. The best fit is someone who uses AI tools daily, has strong opinions about why agents fail today, and finds the intersection of systems engineering and agentic AI to be the most interesting problem available right now.

This Role Is Probably Not for You If

Your systems experience is at the orchestration layer (Kubernetes operators, service mesh, eBPF-based observability) rather than inside a kernel, VMM, or engine. Adjacent vocabulary isn’t the same as having built one.
You’ve optimized and operated engines others built, but haven’t designed the state machine yourself
You want a settled architecture to work within; here you’d be defining it

How We Work

Small team, high trust, high ownership. We value people who are hungry, humble, and sharp. We look for clear communicators who hold strong opinions loosely and use AI-native workflows in their daily engineering. You’ll work directly with the founder, alongside the isolation and cloud infrastructure teams.

Member of Technical Staff - Core Runtime