Ron Efroni on giving agents a deterministic place to run
Flox CEO Ron Efroni talks to Michael Grinich at the AI Engineer World's Fair about Nix, hermetic agent sandboxes, and shipping code to a conviction bar.
At the AI Engineer World's Fair in San Francisco, Michael Grinich sat down with Ron Efroni, CEO of Flox and President of the NixOS Foundation, to talk about the layer most agent conversations skip. Everyone at the conference was building agents. Almost nobody was talking about where those agents actually run.
Efroni's position fits in one line: an agent is a piece of software, and software needs somewhere deterministic to run. Most of the conversation followed from that.
The environment as the unit
Flox is built on Nix, so start there. The idea is 23 years old, and Efroni counts north of 10,000 active monthly contributors. The premise is recursive: architect all software on one base architecture, so if your company is packaged in Nix, every one of your dependencies has to be packaged in Nix too, all the way down.
Flox itself came out of the D. E. Shaw group, where Efroni's co-founder brought Nix into the firm about five years ago, scaled it up, and built the internal platform that became the product. Flox describes that deployment as one of the largest enterprise Nix rollouts anywhere. Efroni came to it from Meta, where he ran the developer products team supporting a 20,000-person engineering organization.
Grinich framed the underlying problem the way most engineers have lived it: reproducible build artifacts have always been the goal, because what gets built on someone's laptop differs from staging, which differs from production.
Flox's answer is a declarative manifest locked to cryptographically pinned, content-hashed inputs, so the same lockfile resolves to the same packages on every supported system, drawing on the 120,000+ packages in Nixpkgs. The quick start in the Flox README shows what that looks like at a shell:
You step in, the tools exist. You step out, they're gone.
Efroni calls this the cryptographic layer for every bit of software a firm needs in order to run, closer to a calculator than a model. You don't need inference to compute 5 × 5.
He'll also say Flox sometimes replaces Docker and sometimes replaces a container, which is looser than how Flox's own docs draw the line. Those docs are explicit that Flox is not a container technology and not a Docker replacement: environments work identically on bare metal, in VMs, and inside containers, and flox containerize emits an OCI image with no Dockerfile. Packaging and isolation are separate problems. Flox handles packaging and leaves you your choice of isolation.
An agent is a piece of software
"an agent is a piece of software. If we can ensure that the environment that that piece of software needs to run is fully deterministic, why not?"
That reasoning is showing up in a few different places across Flox's customer base.
Teams spin agents up inside Flox environments directly. Flox also gets used to build the container an agent runs in, or the VM or microVM that serves as its sandbox. Efroni put the number of sandbox companies at over a hundred, a few of which use Flox at the core layer to define the environment they hand out.
Portability is the payoff there. With the environment as the core module there's no walled garden: the same agent runs on an Ubuntu box or a Mac, and when NVIDIA ships an optimization for some particular Linux version, you move to it.
Then there's containment. An agent confined to a hermetic environment has a much smaller surface to leak out into.
The pressure scales with usage. Efroni described a large customer building an always-on agent, where instantiation stops being the interesting problem and build time, runtime, and pulling state back to local start to dominate instead.
Flox ships tooling for this directly: an MCP server over stdio plus a library of seven skills covering environments, services, builds, containers, publishing, sharing, and CUDA. Because environment management goes through MCP tool calls, an agent doesn't need bash access to manage its own environment.
A known CVE has a file path
"if there's a known CVE, you know exactly where that is because of the file path name. You don't even need to scan"
Remediation is bumping the version up, or back down to the last one that worked.
This gets more valuable as the population of people writing software expands. Efroni's read is more software, more chaos, unless more of it sits on a shared base architecture. Flox's docs make the same claim from the supply-chain end: SBOMs, automated CVE patching, composition analysis, and auditable builds fall out of reproducibility rather than getting bolted on afterward.
Rolling back a ten-year-old server
Grinich raised the enterprise system nobody wants to touch: running for a decade, and the team isn't confident it would come back up if restarted.
Efroni's answer starts with conversion rather than rewriting. Moving an existing project onto a Nix-based architecture is now close to fully automated, and Flox plans to launch a service that does it. Conversion by itself doesn't modernize anything; it pins the current behavior so it reproduces. That's what buys the next step: you can start making changes with conviction, because a break means a rollback.
"worst case you literally have a side-by-side environment that works on any type of machine so that stack never has to go anywhere"
He was candid about the ceiling. Flox counts tier-one banks among its customers, and Efroni's own assessment is that he can't solve their legacy problems, because those firms have spent roughly twenty years layering band-aids on top of each other. What conversion can do is create a core nucleus you're willing to iterate on.
Context you can compartmentalize
The part I keep thinking about is how Flox builds its own product. Efroni put the inflection point around November and December of last year, when models started producing substantial value inside the company.
Two changes did the work. The first was context. An engineer proposed centralizing the company's knowledge and then fragmenting it along the same Nix-based lines, so each agent could be handed the slice relevant to its problem. They called it Forge and open sourced part of it.
"the context of everything doesn't actually help you. It's the ability to compartmentalize what's important for the task"
The test he described: does a decision a team lead made a month ago still bear on the decision an agent is about to make? Skip that filter and you get sprawl.
Shipping to a conviction bar
The second change was conviction. Flox instructs its agent to decompose a feature request into smaller and smaller chunks until a subset clears a defined confidence bar, then automate the pieces that clear it. Anything that can't clear it gets offloaded to a human in the loop.
The bar moves with blast radius. Web UI work ships at 50% or better: launch it, let CI find out. Anything in the package catalog, at the environment layer customers depend on, is held at 80%. Efroni credited the mechanism with building the team's psychological trust in automated shipping as much as its technical confidence.
The practical effect is unbundling work that used to be all-or-nothing. He described a hundred-hour job an agent could finish in ten, where 10% of it was architecturally critical, historically a reason to do all hundred hours by hand. Now the agent takes the 90% and a senior engineer owns the 10%.
The conversation didn't cover the failure side: how often a 50%-confidence ship actually breaks in CI, or what specifically lands in that architecturally critical 10%. Those are the two numbers I'd want before copying the policy.
What thirty people do with the difference
"our team has 50x output in 6 months without growing the engineering base"
Output multipliers from a founder deserve the usual scrutiny, and "output" is carrying weight in that sentence. The staffing counterfactual is easier to check: Flox is around 30 people, and Efroni estimated it would need 10 to 15 more engineers to serve its current customers without the internal agent tooling. The engineers it freed up are building more.
It changed how the company meets customers too. Efroni's example was a customer with oversized images who needs something stripped out and a shim in its place, the kind of request that can now go out behind a feature flag in 90 minutes instead of into a research cycle to decide whether it's worth building at all. The shipped proof of concept then generates real usage data about what deserves to graduate into the product.
Flox is running its own argument on itself. It sells determinism at the environment layer, and it uses determinism at the environment layer to let agents ship code with a known blast radius. Whatever "50x" means, the headcount math is the harder number to fake, and the conviction threshold travels even if Nix doesn't. Pick a confidence bar per surface, decompose the work until pieces clear it, and keep your senior people on the pieces that never will.
This interview was recorded at the AI Engineer World's Fair 2026 in San Francisco.