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.
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.
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.
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
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.
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.
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.
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
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.
","descriptionPlain":"BUILD THE EXECUTION LAYER FOR THE AGENT ERA.\n\nRunta builds runtime infrastructure for long-running AI agents: efficient execution, enforceable access controls, and complete execution records.\n\nWe’re a small, well-funded team based in the San Francisco Bay Area and Singapore. High talent density. High ownership.\n\n\nABOUT RUNTA\n\nRunta 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.\n\nWe’re a small, well-funded team, moving fast.\n\n\nTHE ROLE\n\nThis 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.\n\nRunta 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.\n\nThis 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.\n\n\nWHAT YOU’LL DO\n\n - Design and build snapshot/resume/branch mechanics for long-running agent processes: memory capture, copy-on-write strategies, restore latency on the critical path\n\n - Build crash recovery for stateful execution units: agents that run for days will see every failure mode the platform has\n\n - Own the microVM execution layer: guest lifecycle, device model decisions, boot/restore time optimization\n\n - Make execution recordable: the hooks and guarantees that let us reconstruct exactly what an agent did\n\n - Work at the boundary between the runtime and the isolation layer: what state is safe to persist, what must be re-established on resume\n\n - Set the technical bar for the systems team as an early engineer\n\n\nTHE PROBLEMS YOU’D BE SOLVING\n\n - 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?\n\n - An agent resumed on a different machine after three days: what invariants must hold, and how do you verify them cheaply?\n\n - Branching one execution into N: how do you share pages and storage so N branches don’t cost N× resources?\n\n - A crash mid-snapshot: how do you make the whole pipeline atomic enough that recovery is boring?\n\nIf you read those and started sketching answers, we want to talk to you.\n\n\nWHAT WE’RE LOOKING FOR\n\n - 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)\n\n - 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\n\n - You can reason about copy-on-write, page sharing, and dirty tracking from first principles\n\n - Comfort working close to the metal in Rust, C, or C++\n\n - Staff level: you’ve also owned the architecture of such a system and made trade-offs you can defend years later\n\nNice to have: CRIU or live-migration experience, io_uring, experience making cold starts fast at scale.\n\n\nYOU SHOULD GENUINELY CARE ABOUT AI\n\nThe 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.\n\n\nTHIS ROLE IS PROBABLY NOT FOR YOU IF\n\n - 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.\n\n - You’ve optimized and operated engines others built, but haven’t designed the state machine yourself\n\n - You want a settled architecture to work within; here you’d be defining it\n\n\nHOW WE WORK\n\nSmall 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."},{"id":"0c97aa17-fdd3-414c-bd0a-d31989b11092","title":"Member of Technical Staff - Product Engineering","department":"Engineering","team":"Engineering","employmentType":"FullTime","location":"San Mateo","secondaryLocations":[],"publishedAt":"2026-09-21T15:23:32.706+00:00","isListed":true,"isRemote":false,"workplaceType":"OnSite","address":{"postalAddress":{"addressRegion":"California","addressCountry":"United States","addressLocality":"San Mateo"}},"jobUrl":"https://jobs.ashbyhq.com/runta/0c97aa17-fdd3-414c-bd0a-d31989b11092","applyUrl":"https://jobs.ashbyhq.com/runta/0c97aa17-fdd3-414c-bd0a-d31989b11092/application","descriptionHtml":"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.
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.
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.
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
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.
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 LLM APIs.
The developers you serve are agent builders. If you’re one yourself, you’ll know what they need before they file the issue. The best fit is someone who uses AI tools daily, has built things with agents on their own time, and has opinions about why today’s agent frameworks are frustrating.
Your product experience is primarily end-user web or mobile apps, and developer tools would be a career change rather than a return to form
You need a PM to hand you specs. Here you’d write them
You see documentation and error messages as someone else’s job
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.
","descriptionPlain":"BUILD THE EXECUTION LAYER FOR THE AGENT ERA.\n\nRunta builds runtime infrastructure for long-running AI agents: efficient execution, enforceable access controls, and complete execution records.\n\nWe’re a small, well-funded team based in the San Francisco Bay Area and Singapore. High talent density. High ownership.\n\n\nABOUT RUNTA\n\nRunta 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.\n\nWe’re a small, well-funded team, moving fast.\n\n\nTHE ROLE\n\nOur runtime team builds the engine. Our infrastructure team makes it scale. You decide what it feels like to use.\n\nRunta 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.\n\nThis 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.\n\nYou’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.\n\n\nWHAT YOU’LL DO\n\n - Design and build Runta’s SDK and CLI: the primary surface through which developers run, snapshot, branch, and replay agents\n\n - Make API design decisions with long consequences: what to expose, what to hide, what to name things\n\n - Build the examples, quickstarts, and reference docs that take a developer from curiosity to a running agent\n\n - Turn runtime capabilities into product language: translating “microVM snapshot semantics” into things agent builders immediately want\n\n - Feel every rough edge first and fix it: error messages, failure modes, onboarding friction\n\n - Represent the developer inside the company: your feedback shapes what the runtime team builds next\n\n\nTHE PROBLEMS YOU’D BE SOLVING\n\n - 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?\n\n - A resume fails three days after the snapshot was taken. What error message does the developer see, and what can they do about it?\n\n - 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?\n\n - 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?\n\nIf you read those and started sketching answers, we want to talk to you.\n\n\nWHAT WE’RE LOOKING FOR\n\n - You’ve built developer-facing product surfaces: an SDK, a CLI, a public API, or a devtools product people chose to use\n\n - Exceptional API taste, with opinions you can defend about what to expose, what to hide, and what to name things\n\n - You write clearly. Docs, examples, and error messages are product surfaces here, not chores\n\n - 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\n\n - You genuinely enjoy solving user problems and get satisfaction from someone else’s “oh, that was easy”\n\nNice to have: open source maintainership with a reputation for good DX, developer advocacy or technical writing experience, experience building with AI agents or LLM APIs.\n\n\nYOU SHOULD GENUINELY CARE ABOUT AI\n\nThe developers you serve are agent builders. If you’re one yourself, you’ll know what they need before they file the issue. The best fit is someone who uses AI tools daily, has built things with agents on their own time, and has opinions about why today’s agent frameworks are frustrating.\n\n\nTHIS ROLE IS PROBABLY NOT FOR YOU IF\n\n - Your product experience is primarily end-user web or mobile apps, and developer tools would be a career change rather than a return to form\n\n - You need a PM to hand you specs. Here you’d write them\n\n - You see documentation and error messages as someone else’s job\n\n\nHOW WE WORK\n\nSmall 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."},{"id":"b332c6d5-ce17-4ae7-ab85-5072e031a22a","title":"Member of Technical Staff - Cloud Infrastructure","department":"Engineering","team":"Engineering","employmentType":"FullTime","location":"San Mateo","secondaryLocations":[],"publishedAt":"2026-09-18T18:19:12.539+00:00","isListed":true,"isRemote":false,"workplaceType":"OnSite","address":{"postalAddress":{"addressRegion":"California","addressCountry":"United States","addressLocality":"San Mateo"}},"jobUrl":"https://jobs.ashbyhq.com/runta/b332c6d5-ce17-4ae7-ab85-5072e031a22a","applyUrl":"https://jobs.ashbyhq.com/runta/b332c6d5-ce17-4ae7-ab85-5072e031a22a/application","descriptionHtml":"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.
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.
Our runtime team builds the execution engine. You build the cloud platform it runs on: the production infrastructure that serves paying customers. You are the person accountable for it working, scaling, and not bankrupting us.
Runta does three things: run, govern, record. This role makes run economical at scale, gives record a storage layer that’s cheap at volume and fast on restore, and owns the network boundaries that make govern enforceable in production. You decide ECS vs. EKS, when Spot instances make sense, how snapshot storage should be tiered, and what the architecture costs at 10x load.
You’ll also own the infrastructure-as-code layer that makes our platform reproducible and portable. Writing Terraform is table stakes here. The job is designing modules other engineers consume, managing state at scale, and building abstractions that keep multi-cloud on the table without over-engineering for it today.
This is an ownership role, not a support role. The infrastructure layer is part of the product: customer-facing, versioned, reproducible.
Design and operate Runta’s production infrastructure on AWS: compute, networking, storage, observability
Own the IaC layer: Terraform modules, state management, CI/CD for infrastructure changes
Design cross-cloud abstractions that don’t lock us into a single provider
Own the infrastructure side of snapshot/resume/branch: snapshot graph storage, control plane / data plane separation, local ↔ cloud state consistency
Make cost-aware architecture decisions: instance strategy, Spot fleet design, storage tiering, rightsizing
Shape the infrastructure roadmap as an early technical leader, working directly with the founder
A workload runs anywhere from 2 seconds to 2 hours, unpredictably. How do you size, schedule, and price the fleet under it?
Agents checkpoint constantly. Snapshot storage must be cheap at petabyte volume but restore in seconds. What’s the tiering design?
An agent job fans out 50 concurrent sub-tasks, then the whole fleet goes idle for 10 minutes. Autoscaling policies tuned for web traffic fall over. What replaces them?
Agents retry non-deterministically on failure. Where must the infrastructure itself be idempotent, and where is eventual consistency a silent-corruption risk?
The same platform needs to deploy identically across environments, and someday across clouds. What do you abstract, and what stays provider-specific?
If you read those and started sketching answers, we want to talk to you.
You’ve designed and operated production AWS infrastructure you were accountable for, not just worked within someone else’s
Deep Terraform (or equivalent IaC) experience: complex modules built for other engineers to consume, state management at scale, infra CI/CD
Multi-cloud or cross-cloud experience: provider-spanning abstractions, workload migrations, or internal platforms built on IaC
Experience running serverless or container platforms at scale (Lambda, Fargate, ECS, EKS)
A cost-optimization track record you can talk through in specifics: RI strategy, Spot fleet design, rightsizing with real numbers
Solid distributed systems fundamentals: consistency models, replication, consensus
You understand orchestration platforms at the why level, not just the kubectl level
Nice to have: background in AI/ML infrastructure, agent frameworks, or LLM serving.
Our customers are AI builders. The decisions you make (cold-start latency, snapshot frequency, concurrency limits) determine what AI products are possible to build on Runta. The best fit is someone who already uses AI tools daily, tinkers with agents on their own time, and has real curiosity about where agentic systems are going. If AI is “just another workload” to you, this probably isn’t the right role.
Your infrastructure experience is primarily operating clusters others designed
Your orchestration background is enterprise application workflow (BPMN, Spring-based orchestration) rather than execution infrastructure
You’re looking for a role where the architecture is already settled and the job is keeping it running
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.
","descriptionPlain":"BUILD THE EXECUTION LAYER FOR THE AGENT ERA.\n\nRunta builds runtime infrastructure for long-running AI agents: efficient execution, enforceable access controls, and complete execution records.\n\nWe’re a small, well-funded team based in the San Francisco Bay Area and Singapore. High talent density. High ownership.\n\n\nABOUT RUNTA\n\nRunta 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.\n\nWe’re a small, well-funded team, moving fast.\n\n\nTHE ROLE\n\nOur runtime team builds the execution engine. You build the cloud platform it runs on: the production infrastructure that serves paying customers. You are the person accountable for it working, scaling, and not bankrupting us.\n\nRunta does three things: run, govern, record. This role makes run economical at scale, gives record a storage layer that’s cheap at volume and fast on restore, and owns the network boundaries that make govern enforceable in production. You decide ECS vs. EKS, when Spot instances make sense, how snapshot storage should be tiered, and what the architecture costs at 10x load.\n\nYou’ll also own the infrastructure-as-code layer that makes our platform reproducible and portable. Writing Terraform is table stakes here. The job is designing modules other engineers consume, managing state at scale, and building abstractions that keep multi-cloud on the table without over-engineering for it today.\n\nThis is an ownership role, not a support role. The infrastructure layer is part of the product: customer-facing, versioned, reproducible.\n\n\nWHAT YOU’LL DO\n\n - Design and operate Runta’s production infrastructure on AWS: compute, networking, storage, observability\n\n - Own the IaC layer: Terraform modules, state management, CI/CD for infrastructure changes\n\n - Design cross-cloud abstractions that don’t lock us into a single provider\n\n - Own the infrastructure side of snapshot/resume/branch: snapshot graph storage, control plane / data plane separation, local ↔ cloud state consistency\n\n - Make cost-aware architecture decisions: instance strategy, Spot fleet design, storage tiering, rightsizing\n\n - Shape the infrastructure roadmap as an early technical leader, working directly with the founder\n\n\nTHE PROBLEMS YOU’D BE SOLVING\n\n - A workload runs anywhere from 2 seconds to 2 hours, unpredictably. How do you size, schedule, and price the fleet under it?\n\n - Agents checkpoint constantly. Snapshot storage must be cheap at petabyte volume but restore in seconds. What’s the tiering design?\n\n - An agent job fans out 50 concurrent sub-tasks, then the whole fleet goes idle for 10 minutes. Autoscaling policies tuned for web traffic fall over. What replaces them?\n\n - Agents retry non-deterministically on failure. Where must the infrastructure itself be idempotent, and where is eventual consistency a silent-corruption risk?\n\n - The same platform needs to deploy identically across environments, and someday across clouds. What do you abstract, and what stays provider-specific?\n\nIf you read those and started sketching answers, we want to talk to you.\n\n\nWHAT WE’RE LOOKING FOR\n\n - You’ve designed and operated production AWS infrastructure you were accountable for, not just worked within someone else’s\n\n - Deep Terraform (or equivalent IaC) experience: complex modules built for other engineers to consume, state management at scale, infra CI/CD\n\n - Multi-cloud or cross-cloud experience: provider-spanning abstractions, workload migrations, or internal platforms built on IaC\n\n - Experience running serverless or container platforms at scale (Lambda, Fargate, ECS, EKS)\n\n - A cost-optimization track record you can talk through in specifics: RI strategy, Spot fleet design, rightsizing with real numbers\n\n - Solid distributed systems fundamentals: consistency models, replication, consensus\n\n - You understand orchestration platforms at the why level, not just the kubectl level\n\nNice to have: background in AI/ML infrastructure, agent frameworks, or LLM serving.\n\n\nYOU SHOULD GENUINELY CARE ABOUT AI\n\nOur customers are AI builders. The decisions you make (cold-start latency, snapshot frequency, concurrency limits) determine what AI products are possible to build on Runta. The best fit is someone who already uses AI tools daily, tinkers with agents on their own time, and has real curiosity about where agentic systems are going. If AI is “just another workload” to you, this probably isn’t the right role.\n\n\nTHIS ROLE IS PROBABLY NOT FOR YOU IF\n\n - Your infrastructure experience is primarily operating clusters others designed\n\n - Your orchestration background is enterprise application workflow (BPMN, Spring-based orchestration) rather than execution infrastructure\n\n - You’re looking for a role where the architecture is already settled and the job is keeping it running\n\n\nHOW WE WORK\n\nSmall 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."}],"apiVersion":"1"}