The posting
BUILD THE EXECUTION LAYER FOR THE AGENT ERA.
Runta builds runtime infrastructure for long-running AI agents: efficient execution, enforceable access controls, and complete execution records.
We’re a small, well-funded team based in the San Francisco Bay Area and Singapore. High talent density. High ownership.
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 core runtime and isolation teams.
