Joseph Wang of Emulated discusses building training data and high-fidelity simulation environments for fully autonomous software engineering agents. Drawing on network infrastructure backgrounds, he argues that current post-training environments fail to capture real production incidents, which involve fifty to a hundred turns of handling live traffic amid node failures, config conflicts, and unforeseen mid-incident problems. Emulated instead simulates whole companies, letting agents act as engineers inside cloud and infrastructure settings — provisioning VPCs, subnets, and security groups, meeting cost and deployment requirements, and keeping services alive as they scale. Wang contends that domain expertise plus faithful simulation is what enables agents to learn the end-to-end reality of infrastructure work. # Channel Presentation Observations: "Emulated" — Joseph Wang & Sid ## Explicit Self-Description (Creator Claims) - **Company identity:** Joseph introduces the venture directly: > "Emulated is a data lab focused on increasing the reliability and autonomy of AI agents." - **Founders' stated background:** > "Our backgrounds are in network infra, distributed databases, and sandbox infra." - **Mission framing (Q&A):** Emulated's goal is enabling agents to > "own systems like this, maybe beyond systems, entire companies, by emulating the real world with full fidelity." - **Recruiting intent:** The talk closes with an explicit pitch: > "If you're a distributed systems engineer… if you've trained models before… we'd love to talk." - **Stated motivation for disclosure:** > "We think they're very fun… we want to share these challenges with you in case you're interested in working on them as well." ## Claimed Scope of Work - **Simulated company environments:** "We've taken software engineering companies and we've put them into containerized environments… projects, incidents, customer conversations." - **Distributed-cluster simulation:** A demo of "an etcd consensus cluster that a typical production service might rely on," simulating "flapping nodes, lagging learners in a single sandbox." - **Multi-node sandbox / "cloud in a box":** "A multi-node sandbox with access to real infra, real cloud resources." - **Post-training pipeline work:** Mentioned but not elaborated — "we might be running a little low on time." - **Strategy:** Start vertical on infrastructure, then scale horizontally: > "Lessons learned… going really vertical on a single domain like infrastructure do translate into other horizontal domains." ## Intended Audience (Observable) - **AI/ML engineers familiar with agent benchmarks:** References to "SweBench Pro, Terminal Bench, Frontier Code and Deep Sweep" assume an insider audience. - **Conference talk format:** Opening ("I appreciate the intro"), time pressure, audience Q&A ("what's your primary goal with emulator?"), and a next speaker indicate a live event. - **Potential hires with distributed-systems expertise:** Direct appeal to people with "really niche opinions… at etcd," Kubernetes, auto-scaling. - **In-jokes signaling a practitioner crowd:** "Somebody had Viceroy open on their laptop. Um fun times." ## Demonstrated Presentation Patterns - **Co-founder dual delivery:** Two speakers (Joseph and Sid) alternate sections; Joseph narrates while Sid presents slides ("So what Sid is describing here…"). - **Technical depth with informal tone:** Serious infra content mixed with casual asides ("No shade, right?", "maybe I'm just lying, who knows"). - **Evidence-driven argumentation:** Claims grounded in real incidents, e.g., the DynamoDB outage affecting US East 1, and MVCC corruption as a root cause. - **Openness about open problems:** Lists unsolved challenges — hours-long stack spin-up, cost management, and the "sim-to-real gap." ## Notes on Evidence Limits - No curated metadata was supplied; all observations derive from the title and transcript. - The video demonstrates a **single founder talk**, not the channel's full content pattern; no channel-wide claims (e.g., posting frequency, series structure) can be drawn from this material. # Delivery Observation: Joseph Wang — "Emulated" ## Speakers & Format - **Two-person co-presented talk**: Joseph and co-founder Sid alternate segments, marked by transcript handoffs (`>>`). The bulk is delivered by Joseph, with Sid contributing the mid-talk framing sections. - The talk ends with a live **audience Q&A**, handled by Joseph. ## Tone - **Casual and conversational**: frequent fillers — "uh," "um," "right?" — throughout: "So, like with everything in NML, uh the gap in models is usually a gap in data." - **Playful, self-deprecating humor**, especially near the end: > "Uh and we think that you guys are cool people, uh or maybe I'm just lying, who knows." > "Um, in 2026, all of us are on an infra's comeback, and it's very sexy." ## Recurring Linguistic Habits - **"Uh" and "um" fillers** are constant and stable across both speakers, including in Q&A answers — this is a consistent pattern, not a single moment. - **"Right?" as a rhetorical check-in**, repeated: "it led to a pretty uh natural question, right?", "You can't really like go without these things, right?", "No shade, right?" - **Filler repetition under pressure**: "the the the the the the agent has to reason through in real time" — an isolated stumble, not a pattern. - **"Like" as a discourse marker**: "maybe that's like, 'Oh, Kubernetes.'" — frequent in the closing recruiting pitch. ## Vocabulary & Framing - **Engineering-domain jargon used without softening**: MVCC, etcd (transcribed "SCD"/"CDO"), clock skew, blast radius, VPCs, subnet flapping nodes, sim-to-real gap. He assumes an expert audience: "Um I did see I think a couple people at AWS. Somebody had Viceroy open on their laptop." - **Recurring metaphor of scale/liveness**: "software is living" appears as a core motif: "Um, but software is living and you probably need some sort of software deployment component as well." - **Concrete product name-dropping** to ground abstractions: AWS, GCP, Azure, DataDog, Vercel, Supabase, Modal, DynamoDB. ## Teaching / Communication Patterns - **Rhetorical question → answer structure**, used repeatedly: > "So, with that being said, what is the data gap then?" > "Why are you leaking all of this alpha, right?" - **Verbatim audience/character voicing** — he acts out hypothetical speakers with quoted dialogue: > "Oh, give me this shiny piece of software." Or, "I don't want it anymore. It cost too much. I'm going bankrupt. Delete it, please." > Investors: "Oh, you wrote it. You're done." - **Motivational teaser at the open**: "we're going to touch on some pretty cool things. Uh so, look out for them." - **Building an argument step-by-step through an example** — the "shiny piece of software → provisioning → API → deployment → monitoring" walkthrough is delivered incrementally, with "Um and" as the connective tissue. - **Recruiting close**: the ending pivots to an explicit hiring pitch ("we'd love to talk") and invites "really niche opinions." ## Uncertainty Notes - Only one transcript is available; **sid-level patterns vs. Joseph-level patterns** cannot be fully separated since speaker attribution is inferred from `>>` markers. - The Q&A section is brief, so tone shifts there ("very sexy," "maybe I'm just lying") may reflect a consistent persona or just end-of-talk loosening — insufficient repetition to confirm. # Position Record: "Emulated: The Data for Fully Autonomous Software Engineers and Companies" — Joseph Wang & Sid ## Speaker Identification - Curated metadata names Joseph Wang in the title; transcript confirms **Joseph** and **Sid** as co-founders of **Emulated**, described as "a data lab focused on increasing the reliability and autonomy of AI agents." - Attribution below follows explicit transcript cues (">>" speaker switches); some passages cannot be cleanly disambiguated between the two. ## Core Claims ### The capability gap is a data gap - **Claim:** "the gap in models is usually a gap in data. Models typically are only as good as data is." (attributed to Joseph's presentation flow) - Supporting claim: "Model capability has never regressed whenever you introduce more high-quality data." - Both founders' backgrounds: **network infra, distributed databases, sandbox infra** — mission-critical workloads. - Evidence cited: the **DynamoDB failure** that took down "US East 1 and half the internet," with a root cause including something like **MVCC on a database engine** leading to corruption. ### Current benchmarks are too narrow - Claims about benchmarks (SweBench Pro, Terminal Bench, Frontier Code, Deep Sweep): tasks "only operate within the code base," spanning 50–100 turns producing a few-thousand-line PR. - Missing from these benchmarks, per the speakers: PM work (talking to customers), engineer exploration (performance testing), and **owning infra over years**, not months. ### Emulated's approach: simulated companies in containers - **Claim (Sid):** They have "taken software engineering companies and put them into containerized environments" including organizational context — projects, incidents, customer conversations. - Agents must handle scale-only issues: **network failures between distributed nodes, data corruption, clock skew**, plus reasoning about **operational blast radius** while serving live traffic. - Example environment: an **etcd consensus cluster** where the real challenge is everything surrounding the source code — tickets, postmortems, rolling deployments, failing/stale nodes, live traffic constraints. ### Single-node sandboxes are insufficient - **Claim (Joseph):** A single-node sandbox simulating a distributed cluster "can get you pretty far" but "this is not enough" — standard post-training pipelines are "kind of boring... homogeneous," while real infrastructure isn't. - Qualification preserved: deterministic simulation of network failures "doesn't represent what you might run into if you're building an AWS-scale service." - Enumerated needs beyond one sandbox: resource/host provisioning (EC2/Cloud Run-like), VPCs/subnets/security groups, front-end APIs with **throttling, auth, authorization, CloudTrail**, deployment/rollback/version management, health monitoring aware of network partitions, DNS/cert management, admin consoles, telemetry, billing, scheduling. - **Conclusion (Sid):** "Beyond a certain threshold... sandboxing on a single node can only get you so far" — future environments should **provision real infrastructure** ("a cloud in a box"). - Mentioned but not elaborated (time constraint): effects on post-training pipelines; putting a post-training pipeline inside the sandbox; "cool stuff with model training and RSI." ## Stated Open Problems / Unresolved Tensions - Spinning up an entire stack like AWS Lambda "takes hours — how do you fit that into a post-training rollout?" - **Cost** management. - **Sim-to-real gap persists even with real resources:** still need live customer traffic and scale-dependent problems. ## Q&A Positions ### Primary goal - **Claim:** The real world is "very, very complex" and current industry emulation is "incredibly contrived and low fidelity." Emulated's goal is making agents own systems — "maybe beyond systems, entire companies" — by "emulating the real world with full fidelity." ### Why infra first - Reason 1: it "speaks to our background the most"; **domain expertise informs data quality**, especially given the "boutique nature of data nowadays." - Reason 2: infra has the **clearest problem statement** (e.g., Modal users want low-latency, low-cost GPU sandboxes without failed training runs), unlike a startup still seeking product-market fit. - Sid's addition: vertical depth in one domain "translates into other horizontal domains"; they're "exploring going deep into one and scaling out that way." - Acknowledged: there are other RL environment types / workflows beyond infra they want to capture. ## Noted Qualifications & Tone - Humor and self-deprecation ("maybe I'm just lying, who knows"; "Azure, too. No shade") — not substantive claims. - Motivation stated for sharing details: interest in the challenges and recruiting people (distributed systems engineers, model trainers, holders of "really niche opinions... at etcd"). # Video Attribution Record ## Video - **Title:** Emulated: The Data for Fully Autonomous Software Engineers and Companies — Joseph Wang - **Video ID:** `01a15ca8-09b3-7140-9d3e-4b2a63df5951` - **Type:** Conference/startup talk with audience Q&A (no curated metadata supplied) ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Joseph** | **Creator / presenter / co-founder** of Emulated | "my name is Joseph and this is my co-founder Sid" | | **Sid** | **Guest / co-presenter / co-founder** of Emulated | Introduced by Joseph as co-founder; delivers substantial portions of the talk | | **Audience questioner(s)** | **Other (unidentified audience members)** | Asks Q&A questions: primary goal of Emulated; infra vs. RL environments focus. Number of questioners not specified | ## Speaker Attribution Notes - Turn boundaries are marked by `>>` in the transcript; the alternation between Joseph and Sid is implied by dialogue flow ("what Sid is describing here…", "thank you, Sid, for speaking") but not every turn is explicitly labeled — some attributions are **inferred from context**, not stated. - Joseph self-identifies as speaker; no surname for Sid is given beyond "Sid." ## Referenced Sources & Third-Party Claims - **Benchmarks named:** SweBench Pro, Terminal Bench, Frontier Code, Deep Sweep — cited as examples of code-only task evaluation. - **Third-party claims/events referenced:** - A **DynamoDB outage** "a couple months ago" affecting US East 1 — attributed to the speakers' observation, with MVCC cited (by a speaker) as a root cause. - **Viceroy** — observed by Joseph on an attendee's laptop at AWS. - **Named products/companies (contextual references, not endorsements):** AWS (EC2, Lambda, CloudTrail, Cloud Run), GCP, Azure, DataDog, Vercel, Supabase, Modal, Kubernetes, NLB, DynamoDB, YC summer 2026 batch. - No external documents, studies, or published sources cited. ## Promotional Segments - **Flagged: recruiting/promotion segment** (end of talk): Joseph and Sid invite distributed systems engineers and people with model-training experience to "talk" with them — an explicit hiring/networking pitch. - Product promotion of **Emulated** ("data lab focused on increasing the reliability and autonomy of AI agents") runs throughout as the talk's framing; the "cloud in a box" / multi-node sandbox is presented as their work. ## Availability & Provenance Limits - **Comment availability:** Not specified — no curated metadata supplied. - **Timestamps:** None present in transcript. - **Uncertainty:** Which turns belong to Joseph vs. Sid is partly inferred; audience questioner(s) unidentified. 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 a 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 going to answer some of the questions of what this means for the data and model layers. Uh we're going to 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. We all saw a couple months ago that uh when something like DynamoDB goes down, so does US East 1 and half the internet. Um and working on these systems, we saw model capability gap when it came to operating and building these systems at scale at scale and thinking about uh the consequences of architecture and system 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 at 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. \>\> So, like with everything in NML, uh the gap in models is usually a gap in data. Models typically are only as good at 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 at any of the frontier or recent benchmarks, like SweBench Pro, Terminal Bench, or something like Frontier Code and Deep Sweep, 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 50 to 100 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 contexts like projects, incidents, customer conversations. Uh the agent also has to deal with issues that only appear at 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 task 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 SCD consensus cluster that a typical production service might rely on. So, an old environment uh might tended to operate and work primarily on that little blue square entitled SCD 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 you start with the tickets, projects, postmortems. What are the train wrecks? Why did they happen? How did customers feel about them? And often times 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 a kick kick off rolling deployments. Those deployment systems can often times be complicated, have conflicts, may not work. Um and all through that, when you're finally migrating off of from old hard onto new hardware, um you run into unforeseen problems which you did not sort of the the the the the the agent has to reason through in real time, just like 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 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 kind of boring. Uh it's kind of homogeneous. 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 at 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, Superbase. 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 service a single customer pretty well. Um, maybe it's running on your machine. If you're working for NLB, it should 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 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 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 going to want to do things like, "Oh, give me this shiny piece of software." Or, "I don't want it anymore. It cost too much. I'm going bankrupt. Delete it, please." Um, and so you're going to need some sort of front-end API. And if you have enterprise grade customers who really care about quality, then you're going to 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 your 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 our 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 is it scheduling? Yeah. Um \>\> I think the point is fairly clear at this point. Beyond beyond a certain threshold, there is a critical mass at 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 kind of 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 a question, uh this is all cool stuff, Joseph. Uh thank you, Sid, for speaking. Why are you leaking all of this alpha, right? 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 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 want to 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, spinning up the entire stack for something like AWS Lambda takes hours. 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 at a certain scale. So, you know, if you're a distributed systems engineer, um you know, if you know, this stuff if you train 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 kind of 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, at CDO. 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 emulator? \>\> Yeah, um that touches into why it's called emulate 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 goal is really how do you make these agents own systems like this, uh, maybe beyond systems, entire companies, by emulating the real world with full fidelity. Yeah, go ahead. \>\> Next question is, are you predominantly focused on like infra and you have a lot of containers, actually hardware kind of related stuff, or are you also like full RL environments like a digital twin? \>\> Yeah, of course. Like, the question is like, you know, infra is really cool. Um, in 2026, all of us are on an infra's comeback, 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 want to capture that aren't necessarily infra related. Uh, so the reason why we're starting with infra is, um, there's a couple. Well, 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 boutique nature of data nowadays. Um, and the second is that when we're simulating full companies, infra is the easiest to approach. Uh, if you think about like any infra company out there, whether it be Superbase 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 GPU sandbox, very low latency, very low cost. You don't want to 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 a company in the YC summer 2026 batch, you're probably still trying to find product market fit, right? \>\> Yeah. At 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 I thank you guys for listening. \>\> Appreciate it. \>\> \[music\]