In a Nix-based architecture, every dependency is pinned to a file path. So a known CVE already has a known address. You look it up, see exactly where it lives, and remediate by bumping the version up or down to the last one that worked. Ron Efroni, CEO of Flox and President of the NixOS Foundation, calls this the "cryptographic layer" of software: deterministic, reproducible, and hardened by construction. We covered this and how Flox runs agents and 100+ sandbox platforms inside portable, hermetic environments.
Transcript
Hey everybody. We are back here at the AI Engineer World Fair Conference, San Francisco, and I'm super excited to be here with Ron from Fox. So I'll be here as well. Alright. So what is Flox? People probably know Nicks. Yeah. Give give the quick story of the company. Yeah, happy to. I mean, if if folks don't know Nicks, Right. So Nicks is one of the largest package managers in the world, one of the larger open source communities. I think the whole idea behind Nicks is 23 years ago. It's kind of it's it's past legal age now. The whole idea is like what happens if we can architect all of software in the same base architecture, which is kind of like a cyclical chicken and egg, right. Because if work OS is packaged in Nicks, it means that. Of work OS dependencies needs to be packaged in Nicks and cyclically all the way down. But 20 something years later in north of 10,000 active monthly contributors. We are the biggest package manager now we can do things like that where we can take any project out there and package it with the Knicks based architecture. And once you have that running, there's just a ton of benefits right. It's fast, it's lightweight it's secure the whole concept of an environment or a or a whatever you need for their software to run. Having it run on anything like that's kind of the concepts behind Nicks and yeah, Flocks started, actually. By my cofounder back at DE Shaw, one of the larger hedge funds about five years ago, and he brought Nixon to the firm, scaled it up, built a platform. That platform became flocks with the whole idea of if we want to take Nicks or the principles of Nicks and the values of IT and scale into the workplace, into the enterprise, there's a bunch of things that you have to do. We do them and we allow a lot of the Fortune fives to like use Nicks at work. But bottom line, it's like we allow engineering teams to standardize the way that they run environments across the entire stack. Sometimes it replaces dockers, sometimes it replaces a container. And that's, you know, the 62nd version of standardized, you know, reproducible, durable kind of artifacts for like building software. It's kind of always the Holy Grail, you know, like you have before this stuff that's built on people's local machines. It's different than what's in your staging acceptance environment. That's different in production. So I understand Nicks is like kind of initially solving that enormous problem for the for the whole world. What's different about what's happening now with I like, like the relevance of this technology for this next era of software, maybe not even talking about agents yet, just like kind of the AI research and development and just like the acceleration of the use of software in the world. Yeah. So I think the whole concept is that. Going back to my next pitch at the beginning, which obviously I highly recommend folks check it out, it's that Knicks, the way I look at it, Nicks, flocks, whatever you're talking about is pretty much the cryptographic layer of any bit that your software inside of the firm needs in order to run, right. And what I mean by cryptographic is that it's kind of like a calculator, right? You don't need a model to calculate 5 * 5 we have. You know, algorithms for that, we have like modules for that that can do that at 01 or oh, whatever. So to your question about AI, without saying agents yet, I think it's just that the explosion of who's a software developer, everyone's now developing software. How are we? You know, I think there's two ways to look at it. One, more software, more chaos. So if you can standardize more of that under one base architecture so that you can share it, run it on anything and it will work the same way. It did today. A year from now. There's also the other side of it where we're actually taking AI into kind of the security spaces and the software supply chain spaces as well, right? Where if I know everything that's running inside of my environment, inside of my software, my model, whatever it is at the info level, I have a lot more assurances and also I can create a lot more benefit because I'm only bringing in what's needed. I know exactly where everything is, and one of the most recent examples is. Obviously Mythos has been kind of scary for some, but. If there's a known CV, you know exactly where that is because of the file path name, you don't even need to scan right? So if you have like a light LLM vulnerability or whatever came up more recently. We can show you that in OHH One. There it is. Now all you have to do to either remediate that is bump it up or bump it down to the last version that worked. And that's where the reproducibility aspect and the hardest aspect really comes in. Is there an element of this too? That's. You know, needing something like Nicks in order to quickly roll out changes for organizations. You know, if you think about it, just know there's all these like big enterprise systems where they don't want to touch it. They like the server has been running for 10 years. We don't even know if you can restart it. How does that kind of stuff. And like the modernization of maybe even going back a little bit further modernization of legacy IT systems. Yeah. So I think the core aspect is that first, you can just. Flocked to fire Nixa fire right, so you can take that thing and you can turn it into the next based architecture, which is now super easy like I think it's today it's almost fully automated to the extent that I have a domain buying problem. I'll address this and you know this closed forum in A6000 person conference with you. So it's like we now have we're now going to be launching soon like flocks me, which again, it's just like the models are pretty good. They're good enough to be able to. Actually do a lot of this work for folks. So I think in terms of the legacy products like folks can actually move that off to be based on Unix based architecture stack which you've solved there. Is that how it's working today? Now I can reassure you that it would always work that way. Now in order to, you know, modernize it, that's kind of a different paradigm where now that we have it running in the next based architecture, now we can start making changes, but with assurance, almost like with conviction, right? So now if something. Breaks. We just rollback. So it's almost like we create this atomic unit for the firm and then hopefully, you know, I can't solve the major tier one banks like legacy problems because they've been building Band-aids of like 20 years of software. But hopefully we can. What we're doing is we're creating that core nucleus that now you can iterate on. Break it, try something more modern, but 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. Pretty much love it. Let's talk about agents. So. Agents are being used to write software and then they're also changing the way organizations operate because they're running agents inside, you know, we have sandboxes. There's like other types of agentic systems that are taking over menial tasks for people. How is Nicks being used? I'm curious for both of those, both the software authoring part and then also kind of the like business process automation. Yeah. So I think today, I mean, I can speak more to it on the flock side just because of the customers and the user base that are coming in that we have visibility. But at the end of the day. It's being used in a few different areas. 1 is that folks are using flocks to just spin up agents because again, 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, right? So a lot of folks are using flocks to spin up their agents. There's now a large customer that's like building an always on agent, right? So not only are we solving this like instantiating problem, but also the whole build time runtime pulling him back to local, right? Those things start kind of, I guess. Getting bigger and bigger as you're running more agents across the stack or in the cloud. So for us on the flocks and nick side, it's just that you can actually use it to create a container that has an agent. You can actually use it to create a VM or a micro VM that you can then use as a sandbox. A few of the sandboxes companies, I don't know how many are out there now you're keeping count. Yeah, a few of them actually use flocks at the core layer to define the environment, because once you do, you have no walled garden. Agent can be running on Ubuntu Linux box. You can be on a Mac. Right tomorrow morning you might find that NVIDIA did optimization for. Whatever version of Linux. You can move around and you have that full portability layer using the environment as your core module. But I think that's a little bit of what's happening with agents. The other side of it is just that you can actually, when you pretty much ensure that the agent has to operate within an enclosed kind of hermetic environment built by like Unix based architecture, you actually minimize the the scope of where it can actually leak out into and you actually create a much more hermetic. I would say. Closure around it, and then again, you can push it into a container, into the cloud or whatever you want, but you're not forced to just use it in that one. Yeah, awesome. The development of flocks, you know, and, and maybe Nick's more broadly changing with AI, like the ability to use AI to write code. I feel like there's a lot of people maybe at this conference too that are building kind of front end software experiences. They're vibe coding, they're shipping things very fast. Code review or the lack thereof is like a very popular topic, but with with flocks. This is kind of underlying very important substrate that runs on top of. I'm curious like how you're applying AI to that, that way of doing engineering so internally or kind of in the product itself more and more internally. Yeah, as as you're developing this. So are you a customer saying we want your code to be small batch, handcrafted, written by humans still because. Yeah, I mean, do you have customers that they might be it could be like. But I think there is always this question of like, you know, the automation allows you to accelerate so fast. Yeah. Where are surfaces where if something's easily reversible, the blast radius is either minimized or nonexistent, that you can just ship quickly behind feature flags. And then where are areas where, like, this actually needs to be extremely scrutinized and battle tested and, you know, hardened before anybody gets. I mean, I would say that the biggest change for us, I don't know how you felt. It came around November, December of last year. I think that's where, I mean we were eight, I pilled before that, but I think that's where the models were actually creating substantial value inside of the firm. And one of the first things we did that had the most amount of impact is one of our engineers came in and said that. And I feel like now this is quite common, like I'm hearing actually a few companies that spin up around this concept alone. Pretty much that we had, we had to have a way to centralize the company's knowledge so that we can also fragment that off into Unix based, almost Fox based architecture to then be able to provide context for the different agents that are actually solving problems inside of blocks. So I think that was a big move for us. We called it Forge and I think we even open source part of it because we were like this pretty cool use it. But the entire concept is that we have an entire brain inside of the firm that is has the context of everything. But the context of everything doesn't actually help you. It's the ability to compartmentalize what's important for the tasks that an engineer, product person, a designer, a customer is asking for. And then tying it back, right. Like what decision did Bill, the software team lead make a month ago? Is that still meaningful to what decision? I'm going to make her build as part of my agent. Otherwise, you're getting sprawling chaos. So I think that was meaningful. The second thing that really took us over the curve was. Pretty much the ability for the agent, like instructing it to break down the tasks until they reach a certain level of defined conviction. Why? A that allowed us to also build more like human psychology trust right with with this like automated mechanism of like shipping software cause I think our team has 50X output in six month without growing like the engineering base. But what that does is that we can then toggle. Where what level of conviction we're willing to entertain for a fully automated end to end delivery of a of a of a module of a feature of a fix of a self improvement mechanism, right. If it's like on the web UI, I'm OK with you being 50 plus percent conviction. Launch it, see if it fails as I see what happens. But because flocks is so infra and instrumental, kind of like at the package management environment layer, right things on our catalog we're like 80%. So what the agent does is like. It takes the test, takes a feature request, and then continuously breaks it up into smaller and smaller chunks of work until that subset meets the bar of conviction, and then it automates them. So if it can't automate it, meaning that the bar is like lower or higher, then it will offload off to like a human in the loop. But that gave us a lot of ability because there was some things that we were getting bottlenecked on, right? Where it's like, oh, this thing is, I don't know, it's 100 human hours of work. An agent can do it in 10. But 10% of it is really architecturally critical. So we're just gonna do 100 human hours of work, and now what the engine is doing is like it's taking the 90%. Completing that work and leaving the 10 to one of our, you know, senior engineers to kind of like be human in the loop one of those engineers do with their remaining time they're building more stuff. They said they're accelerating. You're doing just doing more sitting across the board. So I think it's we're just thinking about the way that we're building software very differently inside of the company. Ah. Either amount of the our ability to actually add with a, with a, you know, we're like a 30 person team today. Our ability to like address the level of customers that we have wouldn't have been where it's at without all of this internal tooling around agents and AI based like flows and automation, right. So we would have probably needed to hire at least 10 to 15 more engineers on the team today. I think the other ways is completely changing how we're approaching the customer problems. His mother. Ron, this is really exciting. Thanks so much for stopping by. It's great to see you chat more about blocks.Flox very interesting 🤔
To view or add a comment, sign in
Hi Ron Efroni the 'known CVE has a known address' framing is excellent. This solves trust for the environment layer, deterministic, verifiable by construction. I'm working on the same problem one layer up with ModGate (modgate.io): when agents inside those hermetic sandboxes start calling MCP servers or spawning sub-agents, 'who authorized this action' needs the same by-construction verifiability, signed agent identity, scoped permissions, cryptographic delegation chains. A hermetic sandbox running an unidentified agent is a very secure room with an unlocked door. Environment integrity + agent identity feels like the full trust stack for the agentic era.