Emulated: The data for fully autonomous software engineers and companies

[upbeat music] So I appreciate the intro.

Uh, my name is Joseph, and this is my co-founder, Sid. Emulated is a data lab focused on increasing the reliability and autonomy of AI agents. And if you've been an AI engineer, and you've watched the talks, seen the tracks, then there's probably one takeaway that all the talks have in common, and it's that we're headed towards a

future where agents are able to perform useful work over longer and longer horizons with little to no supervision. So today, we're gonna answer some of the questions of what this means for the data and model layers.

Uh, we're gonna touch on some pretty cool things, uh, so look out for them, um, like how to simulate a company within a sandbox or sandboxes for multi-node systems and distributed clusters.

Um, and if we have a little bit of time, we'll also go into some of the work that we're doing with post-training pipelines and how these new types of sandboxes are affecting post-training infra as well.

So where Sid and I come from, um, our backgrounds are in network infra, distributed databases, and sandbox infra, and these are all areas where the workloads are mission-critical. Um, we all saw a couple months ago that, uh, when do- something like DynamoDB goes down, so does us-east-one and half the internet. [chuckles]

Um, and working on these systems, we saw a model capability gap when it came to operating and building these systems as scale, [REDACTED:username] scale, and thinking about, uh, the consequences of architecture and sys-system design over the course of years.

Yeah, so it led to a pretty, uh, natural question, right? For such mission-critical services, why is it that my model or my agent is so proficient [REDACTED:username] handling the application layer but is-- struggles when it comes to reasoning through infrastructure complexities?

For example, things like MVCC on a database engine, which can lead to corruption issues, which is one of-- which was one of the roots of the DynamoDB failure a few months ago.

Yeah. So like with everything in NML, uh, the gap in models is usually a gap in data. Models typically are only as good [REDACTED:username]-- as data is. Um, and to really highlight this point, right, model capability has never, uh, regressed whenever you introduce more high-quality data.

Um, so with that being said, what is the data gap then? What does data look like right now, and how is this influencing the model capability gap here? So if you look [REDACTED:username] any of the frontier or recent benchmarks, like SWE-bench Pro, Terminal-Bench, or something like Frontier-Code and DeepSwe,

um, the tasks only operate within the code base. Uh, the agent is given a pretty large, uh, task, uh, and over the course of fifty to one hundred turns produces a couple-thousand-line PR.

Um, but it doesn't do all of the work that a human does. It doesn't do, uh, what a PM does with talking to customers, understanding their problems. What an engineer does with trying out different approaches, performing-- performance testing them, um, and owning the underlying infra for the code base over the course of not just months, but years.

And this is really the gap that we're closing. We've taken software engineering companies, and we've put them into containerized environments. So this includes, uh, include like organizational context, like projects, incidents, customer conversations.

Uh, the agent also has to deal with issues that only appear [REDACTED:username] scale, like network failures between distributed nodes, data corruption, and clock skew. And through all this, we also want the agents to reason about orchestrating through distributed clusters and also thinking about things like operational blast radius while solving live traffic.

And the result is that the tasks that these agents have to complete or we want the agents to learn is that environments are far more complex and long horizon than a simple code diff.

So let's just-- let's bring a picture into the mix because it tends to make things more interesting. Uh, here's an example we've built of an etcd consensus cluster that a typical production service might rely on.

So an early environment, uh, might, uh-- tended to operate and work primarily on that little blue square entitled etcd source code in the bottom right there. But a lot of the fun and the model capability gap that results from it is really in everything that surrounds it.

So you s- you start with the tickets, projects, postmortems. What are the train wrecks? Why did they happen? How did customers feel about them? And oftentimes, those aren't necessarily up to date.

Um, the agent has to incorporate all that when it's reasoning through the actual change that current environments have it make. After it makes that change, uh, you need to kick, kick off rolling deployments.

Those deployment systems can oftentimes be complicated, have conflicts, may not work. Um, and all through that, when you're finally migrating off of-- from old hi-hardware onto new hardware, um, you run into unforeseen problems which you did not sort of-- that, that, that the agent has to reason through in real-time, just like a, a human would, right?

You have, um- Failing nodes. You have stale deprecated nodes. And while all of this is happening, the service can't go down because there is a blast radius to serving live traffic.

You have to observe and monitor your service. All of these components in, in, in the system is really, uh, what sort of exemplifies, like, a full end-to-end infrastructure task.

So what Sid is describing here is an environment in a single-node sandbox where we're simulating, uh, a distributed cluster with multiple nodes, flapping nodes, lagging learners, um, in a single sandbox, and you can get pretty far with this, right?

Like, you can see that there's live traffic, there's a lot of operational issues that a real engineer would have to deal with, and you can make this pretty long horizon by just, say, doing multiple deployments instead of just one.

But really what we're seeing is that this is not enough. Uh, this fits into standard post-training pipelines in the sense that a standard post-training pipeline is kinda boring. Uh, it's kinda homogenous.

You know, everything just runs Harbor. Everything is a single sandbox, containerized. But real infrastructure, uh, doesn't work like this. Uh, this isn't how real companies run, and, uh, even though you can use something like deterministic simulation to simulate network failures, it doesn't represent what you might run into if you're building an AWS scale

service. So I did see, I think, a couple people [REDACTED:username] AWS, somebody had Viceroy open on their laptop. Um, fun times. Um, but let's imagine here that we are all AWS engineers, or GCP engineers, Azure too, no shade, right?

Um, and we are building a cloud service. Um, it can also be some infrastructure service like Datadog, Vercel, Supabase. Uh, all of these services run into the same problems.

You start off with a shiny piece of software, and this piece of software can serve a single customer pretty well. Um, maybe it's running on your machine. If you're working for NLB, this would be a load balancer, right?

If you're working for AWS Lambda, it'd be some sort of serverless runtime. But, uh, it needs to actually run somewhere. So if you're an infrastructure engineer, next step is you get into resource provisioning.

Um, and this is already where the single-node sandbox starts breaking down. How do you provision resources within a single sandbox? You can't exactly simulate something like EC2 or s- Cloud Run, right?

Um, so you get into this host provisioning. Uh, it also includes provisioning of other resources like VPCs, subnets, security groups. Um, and you need to expose this through some sort of API because your customers are gonna wanna do things like, "Oh, give me this shiny piece of software," or, "I don't want it anymore.

It costs too much. I'm going bankrupt. Delete it, please." Um, and so you're gonna need some sort of front-end API. And if you have enterprise-grade customers who really care about quality, then you're gonna have to meet certain bars like throttling, authentication, authorization.

You can't really, like, go without these things, right? Uh, if you're AWS, then that's CloudTrail too. Um, and then beyond this, uh, software is living. People forget this all the time, especially, like, investors, right?

Like, they'll be like, "Oh, you wrote it. You're done." Um, but

software is living, and you probably need some sort of software deployment component as well. Uh, something whenever you have an update to roll out, roll it out, um, and God forbid something goes wrong, roll it back.

Uh, you need to manage all the different versions and make sure deployments are gradual to limit your blast radius. And we're just kind of getting started with this. There's all sorts of things that you need to think about, like health monitoring with awareness for network partitions, uh, and then how do you communicate with your host so you

can change configs on the fly? Um, maybe your customer actually wants to call your endpoint, so you need DNS and cert management. And then, you know, your service grows a bunch.

You need to keep track of all your resources, what's going on, fraud and stuff. Then you need admin consoles, uh, telemetry, billing if you're making money, um, all sorts of things.

And with all of this ... I think there's, like, one more slide for-

Yeah

... was it scheduling? Yeah. Um ...

I think the point is fairly clear [REDACTED:username] this point. Beyond, beyond a certain threshold, there is a critical mass [REDACTED:username] which sandboxing on a single node, uh, can only get you so far, and that's why we envision the, the future being, going towards a world where environments do provision real infrastructure.

Yeah. So what this is is, um, a multi-node sandbox

with access to real infra, real cloud resources. Uh, we kinda put a cloud in box, so cloud box could be another name for this. Um, and as you can imagine, changing the sandbox type so drastically here affects post-training pipelines as well which, um, I think we might be running a little bit low on time, so we won't

get, like, too much into it. Um, but yeah, like, uh, one really cool thing too is, like, you can put a post-training pipeline in the sandbox, um, and there's some cool stuff with model training and RSI that you can get into there.

Um, so, you know, then this begs the question, uh, this is all cool stuff, Joseph. Uh, thank you, Sid, for speaking. Why are you leaking all of this alpha, right? [laughs]

Why are you, like, telling all your organizational secrets and telling everybody, like, oh, okay, you know, how do you build a system like this? Um, it's because, uh, we're really interested in these challenges here.

We think they're very fun. Uh, um- You know, we think they're really cool. We think that you guys are cool people, uh, or maybe I'm just lying. Who knows?

Uh, and we wanna share these challenges with you, uh, in case you're interested in working on them as well. As you can imagine, there's a lot of different problems that we haven't touched on here.

Like for example, sc- spinning up the entire stack for something like AWS Lambda takes hours. [laughs] Um, how do you fit that into a post-training rollout? Uh, and then there's cost as well.

How do you efficiently manage this? How do you make sure the sim-to-real gap, even with real resources, it still exists, right? You still have to have live customer traffic.

You still have to have, uh, problems that only appear [REDACTED:username] a certain scale. So, you know, if you're a distributed systems engineer, um, you know, if you know this stuff, if you've trained models before, um, if you think that this stuff is cool, uh, then, you know, we'd love to talk.

Uh, we'd love to talk, uh, kinda like see where your opinions are, uh, hear what you've worked on. Maybe that's like, oh, Kubernetes, and you have, like, opinions. Well, everybody has, like, opinions on, like, auto-scaling and rolling deployments and whatever, but, like, really niche opinions, right?

Like [REDACTED:username] CD. Um, yeah, we'd love to talk to you and hear what you have.

Thank you. Yep.

Um, what's your, like, primary goal with Emulated?

Yeah. Um, that touches into why it's called Emulated in the first place, right? Uh, the real world is very, very complex. Um, and how we, as a industry, emulate the real world is incredibly contrived and low fidelity.

So Emulated's goal is really how do you make these agents own systems like this, um, maybe beyond systems, entire companies, by emulating the real world with full fidelity.

Yeah, go ahead.

Next question is, um, are you pr- predominantly focused on, like, infra and, um, DevOps, containers, you know,

um, effectively hardware kind of related stuff? Or are you also looking [REDACTED:username], like, full RL environments, like a digital twin?

You know.

Yeah, of course. Like, the question is, like, you know, infra is really cool. Um, in 2026, all of a sudden infra's come back, and it's very sexy. Everybody wants to work on it, right?

But there's other types of RL environments as well. Um, there is, uh, other workflows that you really wanna capture that aren't necessarily infra related. Uh, so the reason why we're starting with infra is, um, there's a couple.

One-- The first, most important one is it speaks to our background the most. Um, we think that domain expertise is something that informs how high quality your data can be, uh, especially with the boutique nature of data nowadays.

Um, and the second is that when we're simulating full companies, infra is the easiest approach. Uh, if you think about, like, any infra company out there, whether it be Supabase or Modal, uh, or any dev tools company,

the problem statement is pretty clear. Uh, engineers kind of know what they want. If you are working for Modal, you know that your users want a GPU sandbox, very low latency, very low cost.

You don't wanna h- fail halfway through your training run. Um, that's what you care about. So the problem statement becomes much easier, whereas if you are, you know, a company in the YC Summer 2026 batch, you're probably still trying to find product market fit, right?

Yeah. [REDACTED:username] the same time, there's also lessons learned that going really vertical on a single domain like infrastructure do translate into other horizontal domains. So we're also, um, exploring going deep into one and scaling out that way.

All right. Uh, really appreciate it. Uh, appreciate the questions. Um, we'll probably step out, and we can, like, take a couple more, uh, outside just to make sure the next speaker has room.

Um, yeah, uh, thank you guys for listening.

Appreciate it. [audience applauding] [upbeat music]