Member of Technical Staff - Product Engineering

Runta Start free trial All open roles Product Engineering Member of Technical Staff - Product Engineering Design the SDK, CLI, APIs, docs, and developer experience that make Runta's runtime primitives easy to use. San Francisco Bay Area on-site full-time Level: Mid-level (2–5 years experience) Location: SF Bay Area 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 Our runtime team builds the engine. Our infrastructure team makes it scale. You decide what it feels like to use. Runta does three things: run, govern, record. Underneath, that’s microVMs, snapshot graphs, and audit machinery. Your job is to make sure developers never have to think about any of that. They should think “I can pause my agent, branch it into three versions, and resume the best one,” and the SDK, CLI, docs, and examples you build are what makes that thought possible. This role decides whether Runta is an impressive piece of infrastructure or a platform people build on. Powerful primitives with a bad interface lose to weaker primitives with a great one. You own the interface. You’ll be the developer-zero for every capability the runtime team ships: the first person to use it, the person who decides what gets exposed and what stays hidden, and the person who makes the 5-minute quickstart actually take 5 minutes. What You’ll Do Design and build Runta’s SDK and CLI: the primary surface through which developers run, snapshot, branch, and replay agents Make API design decisions with long consequences: what to expose, what to hide, what to name things Build the examples, quickstarts, and reference docs that take a developer from curiosity to a running agent Turn runtime capabilities into product language: translating “microVM snapshot semantics” into things agent builders immediately want Feel every rough edge first and fix it: error messages, failure modes, onboarding friction Represent the developer inside the company: your feedback shapes what the runtime team builds next The Problems You’d Be Solving Branching a running agent is a new primitive with no established mental model. What’s the API shape, and what metaphor makes it click in 10 seconds? A resume fails three days after the snapshot was taken. What error message does the developer see, and what can they do about it? The runtime exposes 40 knobs. Which 5 belong in the quickstart, which 35 belong behind an escape hatch, and how do you keep the escape hatch from becoming the front door? A developer’s first 5 minutes decide whether they come back. What does the ideal zero-to-running-agent path look like, and what’s currently in its way? If you read those and started sketching answers, we want to talk to you. What We’re Looking For You’ve built developer-facing product surfaces: an SDK, a CLI, a public API, or a devtools product people chose to use Exceptional API taste, with opinions you can defend about what to expose, what to hide, and what to name things You write clearly. Docs, examples, and error messages are product surfaces here, not chores You can read the systems underneath: you don’t need to build a hypervisor, but you need to understand what one is, so your abstractions don’t lie You genuinely enjoy solving user problems and get satisfaction from someone else’s “oh, that was easy” Nice to have: open source maintainership with a reputation for good DX, developer advocacy or technical writing experience, experience building with AI agents or...