Amika lets coding agents keep their VMs between pull requests

Why it matters

Agent infrastructure is moving beyond one disposable sandbox per task. Persistent workstations can preserve useful state, but they make identity, secrets and VM lifecycle controls central product requirements.

Dylan Mikus (@dbmikus), co-founder and CEO of Amika, argued in a September 13th thread on X that cloud coding agents should be able to reuse persistent virtual machines rather than rebuild a clean environment for every pull request.

"Forcing cloud agents onto ephemeral VMs is wrong," Mikus wrote. His case centers on setup and continuity: agents often need repositories, credentials, development services, caches and temporary files that take time to reconstruct and may never be captured in the codebase.

Amika's answer is a cloud workstation called a "Rig." A Rig is a VM loaded with repositories, development services and coding agents such as Claude Code, Codex or OpenCode. It can remain available as a persistent development box, disappear after a task or be cloned when work needs to branch. Multiple agents and people can share the same Rig.

That design gives Amika a specific position in the crowded agent-infrastructure market. Many sandbox products optimize for creating one isolated machine for one agent session. Amika is betting that developers also need durable workstations where related tasks can inherit the same running state.

The case for reusable state

Mikus said related agent tasks sometimes depend on temporary state that is absent from the base environment. An agent may install a dependency, start a service, generate an artifact or make coordinated changes across public and private repositories. Reusing the machine preserves that work without requiring Amika or the developer to define a separate artifact system for every intermediate output.

Amika does not treat persistence as the correct choice for every workload. The open-source Amika repository says Rigs can be short-lived or persistent. Developers can also split agents across isolated VMs when simultaneous processes would collide over ports, databases or files.

That produces a two-level model: related work can share one workstation, while independent jobs can receive separate machines. VM clones provide another option, allowing a new task to inherit an existing environment before diverging from it.

Amika's architecture follows the thesis Mikus and co-founder Jakub Cichon published in the Fixpoint axioms: an agent should operate inside a real computer with a filesystem, shell and network, rather than depend entirely on narrow tool interfaces. The pair describes the future unit of software as a bundle containing a micro-VM, an AI agent and the software available inside that machine.

Mikus and Cichon previously built Fixpoint around staffing and managing expert data-labeling teams. They pivoted the company to Amika, which joined Y Combinator's Fall 2025 batch. A Y Combinator profile lists Mikus as a Carnegie Mellon computer science and machine learning graduate and identifies both founders as two-time YC founders.

Agent infrastructure is splitting by workload

The persistent-workstation approach serves a different operating pattern from systems built for huge bursts of isolated tasks. Google's AX orchestrator, for example, runs on Kubernetes and Agent Substrate, and Google says it is designed to manage billions of agent tasks within a cluster. AX defines separate task, workspace, network gateway and model resources, and supports suspending and resuming an agent's state.

Google's system targets organizations prepared to operate Kubernetes, a container registry, Redis and the Agent Substrate control plane. Amika is pitching a developer-facing layer that can provision Rigs on hosted infrastructure, external cloud providers, Kubernetes clusters and, as support develops, computers owned by the customer.

The distinction is becoming less about whether agent state exists and more about who controls its lifecycle. Batch workloads, evaluations and parallel experiments favor disposable machines that can be created in large numbers. Coding projects often contain a chain of dependent tasks that benefit from preserving services, caches and uncommitted artifacts.

Persistence also raises the stakes for access control. A reused VM can retain credentials, processes and files across sessions, so identity, network policy and secret handling become part of the product rather than cleanup after the fact. Amika's current product page labels hidden-secret handling and controls for inbound and outbound network requests as "coming soon."

That gap is central to Amika's bet. Reusing a workstation can remove the setup tax that makes cloud agents cumbersome, while safe reuse requires Amika to define which state survives, who can inherit it and what an agent can reach. The easier Amika makes persistence, the more important those boundaries become.