Safia Abdalla (Warp) discusses building the Oz cloud agent platform around the principle that a platform should absorb complexity before it reaches users. Topics include running agents inside the repository process (issue triage, agent-managed pull request review), managed and self-hosted sandboxes, multi-harness support with consistent conversation state and artifacts, and sub-agent orchestration via prompt or an API exposing platform primitives — which non-engineering Warp staff used to build Slack tooling. She closes by critiquing the term "software factory" in favor of a potter's workshop metaphor. # Channel Presentation Observations ## Video Identity - **Title:** "The Agent Behind the Curtain: Building the Oz Cloud Agent Platform — Safia Abdalla, Warp" - **Speaker:** Safia Abdalla, presenting as a member of the Warp team ("how the team at warp built our cloud agent platform"). - No curated metadata was supplied; observations rest solely on title and transcript. ## Intended Audience (Observed) - **Software developers and developer-tool builders.** The speaker positions herself as one of them: "when I say we here, I mean the people building developer tools because that is the person that I am." - **Conference attendees, likely a developer/AI conference.** She references a live room: "who here has a preference for cloud code as a harness locally?" and closes with "you could stop by the warp booth... We're at UG20." - **Mixed technical audience including non-developers as an aspirational segment:** "the definition of who a builder is is expanding to non-developers." ## Claimed Scope (Creator Claims) - The talk describes **Warp's cloud agent platform ("Oz")**, covering: - Sandboxes: "we add support for not only managed hosting but also self-hosting." - Multi-harness support: "you can... integrate multi-harness support." - Agent orchestration: "You can orchestrate agents across the stack" via prompts and API. - Full API/SDK exposure: "everything in our surface area is exposed via API." - Claims about the company trajectory: "Warp started off as a terminal... it grew into an agentive development environment and about three months ago we decided to go open source," with stars going "from around 20,000 to over 60,000" and "thousands of PRs." - Internal-use claims: developer relations teammates "built out tooling to help us manage all of our social mentions" via the SDK; all PRs "go through an agent managed review process." ## Explicit Self-Description - **Speaker background (stated, not inferred):** "I've spent the past eight years building developer tooling," including the Jupyter Notebook Core team, maintainer on the "Interact project," and "my time at Microsoft helping build APIs and SDKs." Currently "bringing AI agents to the cloud at Warp." - **Contact identity:** "I'm Captain Sophia on all social media, GitHub, Twitter." ## Demonstrated Presentation Patterns (Observable) - **Educational talk format with philosophy framing.** Core stated principles: - "platforms should take on complexity before it reaches the user." - "self-improvement loops are really important" for the SDLC. - **Opinionated commentary:** "You might have heard this term of the software factory... I kind of actually hate it" — followed by the extended potter's workshop analogy as a counter-model. - **Marketing/promotional close:** invitation to the Warp booth, social handles, and email — indicating the talk doubles as product evangelism. - **Narrative structure:** personal background → why → how (platform components) → analogy → call to action. ## Claims vs. Demonstrated (Boundary Check) - **Claims:** open-source success metrics, internal SDK use cases, platform capabilities (APIs, self-hosting, agent review gates). - **Demonstrated:** the talk itself shows expertise in dev-tooling discourse, an opinionated engineering philosophy, and a speaker comfortable blending personal narrative with product storytelling. - No private motivations were inferred; all items above trace to quoted transcript passages. # Delivery Observation: Safia Abdalla — "The Agent Behind the Curtain" ## Overall Tone & Register - **Conversational, informal conference talk style.** Heavy use of filler words: "Um," "Uh," "like," "kind of," and "yada yada" appear throughout. > "Um, and now I'm working on bringing AI AI agents to the cloud at Warp." > "yada yada. and he got more even more animated" - **Warm and personal**, mixing engineering detail with anecdote (the potter story), while staying product-focused. ## Recurring Vocabulary & Phrases - **"Meet people/devs where they are"** — repeated framing device: > "really good dev tools meet devs where they are and grow with them" > "we want to meet people where they work" - **"Complexity"** as a recurring theme word: > "you adopt a lot of complexity" > "platforms should take on complexity before it reaches the user" > "We abstract complexity away from the user" - **"Primitives"** — used repeatedly for API/platform building blocks: > "every primitive models this philosophy of hiding complexity" > "exposing the primitives in a way that users can build on top of" - **"Workflows and preferences"** as a paired phrase: > "accommodate your workflows" > "their workflows and preferences on their team" - **"Build on top of"** — repeated multiple times around APIs/SDKs. - **"Harness," "sandbox," "agents and sub-agents"** as domain vocabulary throughout the technical middle section. ## Teaching Habits & Structure - **Why-before-how framing**, stated explicitly: > "before I talk about the how though, I want to talk about the why." - **Chronological narrative arc**: background → philosophy → platform components (sandbox → harness → orchestration → API) → open-source case study → extended analogy → closing principles. - **Rhetorical transitions via questions**: > "what if one agent isn't enough to do work?" > "where does the agent run if it's not running on a developer's machine?" - **Audience interaction**: at least one show of hands: > "who here has a preference for cloud code as a harness locally?" - **Recaps with "Okay, cool" / "So"** to consolidate progress: > "Okay, cool. So, we gave you a place for your agent to run and we gave you a choice for what harness you use" - **Concrete internal examples** to ground abstractions: DevRel team's Slack bots for social mentions, sentiment analysis, issue triage, agent-gated PR reviews. - **Extended analogy as a teaching device**: the farmers-market potter/mug/workshop story (~2 minutes) used to reframe "software factory" as "workshop," with explicit callback mapping ("the same way that a human in a workspace might need need to react to a real event"). ## Communication Patterns - **Direct stance-taking with hedged framing**: > "I kind of want to push back on this term a little bit. I kind of actually hate it... where's the people in this?" - **Enthusiasm markers**: > "this API is super magical" > "It was a huge success for us" > "this is where like things get buzzy" - **Numeric specificity for credibility**: > "catapulted from around 20,000 to over 60,000" - **Self-inclusive "we"** with a deliberate clarification: > "when I say we here, I mean the people building developer tools because that is the person that I am" - **Casual sign-off with multiple contact channels** (booth, Twitter, email). ## Uncertainty Notes - Transcript is auto-generated: filler density and disfluencies (e.g., "sub aents," "Smug") may be over- or under-represented; exact verbal mannerisms beyond wording (pacing, pauses, gestures) are not observable here. - The single "[snorts]" stage direction is an isolated moment, not evidence of a pattern. # Observation Record: The Agent Behind the Curtain — Building the Oz Cloud Agent Platform **Speaker:** Safia Abdalla, Warp (identified from video title metadata) ## Speaker Background - Eight years building developer tooling - Former maintainer on Jupyter Notebook Core team (Python/data science open source) - Worked at Microsoft building APIs/SDKs for web developers - Currently building AI agents for the cloud at Warp ## Core Philosophy ### Dev tools meet developers where they are - **Claim:** Good dev tools accommodate existing workflows and adapt as the nature of work changes. - **Reasoning:** People have strong preferences (shell, language, harness, review process); tools that adapt become part of how people think and build. - **Claim:** Dev tools have a **compounding effect** — software that helps builders magnifies the amount of great software in the world. ### Platforms absorb complexity - **Claim:** "Platforms should take on complexity before it reaches the user" — a good experience hides leaky complexity so users focus on their work. - Warp structured the cloud agent platform so every primitive models this principle. ## Platform Components (as described) ### 1. Sandboxes / where agents run - Initial approach: **managed/self-served sandboxes** for easy on-ramp. - Realization stated by speaker: teams doing serious work manage their own infrastructure and dev boxes, so managed hosting is "usually not sufficient." - Result: support for both **managed and self-hosted** sandboxes, abstracting infrastructure concerns (security, deployment practices, team workflows). ### 2. Multi-harness support - **Claim:** People are passionate about harnesses (Claude Code, Codex, custom harnesses); the platform should meet them where they work. - **Qualification:** Flexibility risks **fragmentation** if crammed in — experiences differ across harnesses. - Mitigation: platform provides **structure and guardrails** — consistent interaction with native experiences (storing/rehydrating conversation state, working with artifacts like PRs, issues, generated files). ### 3. Multi-agent orchestration - **Claim:** "Real engineering work rarely fits inside one prompt" — typical workflows need research/planning agents, implementation agents, validation agents, possibly with different harnesses and models for adversarial robustness. - Two modes: - **Prompt-based orchestration:** an orchestrator agent mediates between sub-agents behind the scenes. - **API-based orchestration:** everything exposed via API; users attach sub-agents to parent agents via configuration. ### 4. APIs/SDKs as the platform's key - **Claim:** Great APIs let people build beyond your UI/opinions — this is where **composability** becomes powerful. - Internal example: non-engineering teammates used the SDK to build custom Slack bots; DevRel built tooling where agents pick up tweets/Reddit posts, do sentiment analysis, and propose responses. - Other internal uses cited: product queries, competitive research. ## Open Source Experience - Warp went open source ~3 months before the talk (stated as: from terminal to "agentive development environment"). - Metrics claimed: GitHub stars rose from ~20,000 to over 60,000; thousands of PRs; hundreds of contributors. - **Design intent:** agents should participate meaningfully — triage, context, implementation, review — with humans still in the loop. - Workflow described: - New issues trigger an agent that triages, researches the codebase, asks clarifying questions when the report is abstract. - Agents help draft specifications and implementations. - All PRs go through an **agent-managed review process** with multiple iterations; human reviewers are only pinged after agent approval. - Humans handle only "high signal, high quality" PRs. - **Claim:** Self-improvement loops enhance the SDLC as more PRs/examples arrive. ## Broader Claims ### Expanding who can build - **Claim:** Agents providing structure and context let anyone "translate their intent into implementation" — including people with domain knowledge who aren't the software builders. - Warp noted its unusual position: developers building for developers. Most software is built for non-developers; with structures and guardrails, non-developers could ship serious software. ### Pushback on "software factory" - **Stated position:** The speaker "kind of actually hates" the term — "where's the people in this?" — it fails to convey the point. - **Counter-metaphor: the potter's workshop** (personal anecdote about a farmers-market mug and the potter's process): - Attention to craft details (handle curve, thumb dimple, catch-glazing). - Workshop organized into stations, clay-sourcing process, verification steps (restart process if the dimple wasn't right). - Scaled to dozens of apprentices and hundreds of handcrafted mugs per day. - **Interpretation offered:** Workshops are not quaint single-person spaces but "heavy duty systems for doing work" — malleable, reactive to signals, with a close human interaction loop. ### Requirements derived for agent systems - Automations that **react to real-world events** (like a human reacting to a broken handle or stray kiln). - **Observability** — inspecting how people work and refining the process doesn't come for free. - **Improvement over time** — not a static system. - **Cost effectiveness** — reduce broken mugs / buggy software "without spinning too many tokens." ### Shared goal - Build systems that **remove toil and drudgery** (bug reproduction, production monitoring) so more people can build, repeatably and transferably to non-technical roles. ## Qualifications and Tensions Preserved - Speaker explicitly holds contradictory stances on terminology: works on "software factory"-style systems while rejecting the term itself. - Managed hosting framed as both an easy on-ramp and insufficient for serious teams — resolved by supporting both models, not choosing one. - Flexibility vs. fragmentation tension acknowledged and only partially resolved via guardrails. - The mug anecdote is personal narrative; the generalizations drawn from it are the speaker's stated interpretation. # Speaker & Provenance Observation Record ## Video **Title:** The Agent Behind the Curtain: Building the Oz Cloud Agent Platform — Safia Abdalla, Warp **Video ID:** `01a15ca7-c4dd-7936-96d4-7059c71c9848` ## Speaker Inventory | Speaker | Role | Evidence | |---|---|---| | Safia Abdalla | **Sole speaker / presenter (creator-side, affiliated)** | Introduces herself and her background: ~8 years in developer tooling, Jupyter Notebook Core team (open source), maintainer on "Interact" project, former Microsoft (APIs/SDKs), currently at Warp building AI agents for the cloud. | - **No other speakers** appear in the transcript; no host, moderator, or guest. - Audience is referenced indirectly (speaker asks for a show of hands about harness preferences), but no audience member is identified. ## Referenced Sources & Third-Party Claims - **Warp** — employer/affiliation; claims about its products: - Warp Terminal, cloud agent platform ("Oz"), Warp's own harness ("warp zone harness" — as transcribed). - Claim: Warp went open source ~3 months prior; GitHub stars grew from ~20,000 to over 60,000; thousands of PRs; hundreds of contributors. *(Speaker's own unverified figures.)* - Claim: agent-managed issue triage and agent review gate for PRs on the Warp repo. - Claim: internal non-engineering teams (developer relations) built Slack bots via Warp's SDK/API for social-mention sentiment analysis. - **Third-party products mentioned (no claims made by third parties):** Jupyter Notebook, Microsoft, Claude (harness), Codex/Codeex (as transcribed), Slack, GitHub, Reddit, Twitter. - **Personal anecdote:** farmers-market potter story — first-person account, unverifiable. ## Promotional Segments (Flagged) - **Closing call-to-action:** speaker invites listeners to the Warp booth at "UG20" (as transcribed), to mention her on social media ("Captain Sophia"), or email her via her personal site. This is a **promotional/booth segment**. - The talk overall promotes Warp's platform and open-source repo, though the bulk is technical presentation. ## Curated Metadata - None supplied beyond the video title/transcript. ## Availability & Uncertainty - **Comment availability:** not indicated in source material — **unknown**. - Transcript contains disfluencies and possible mis-transcriptions (e.g., "current" for "curtain", "cloud code", "Codeex", "aents", "Smug", "UG20") — exact product/event names uncertain as transcribed. - No timestamps were provided; none recorded. Uh hi, welcome to this session. Uh it is mysteriously titled the agent behind the current. Um it's about how the team at warp built our cloud agent platform. Um before I talk about the how though, I want to talk about the why. Um and share a little bit about my own background. Um so I've spent the past eight years building developer tooling. Um I started off in open source in the Python and data science space um on the Jupyter Notebook Core team. I was a maintainer on the Interact project. That work continued in my time at Microsoft helping build APIs and SDKs for web developers. Um, and now I'm working on bringing AI AI agents to the cloud at Warp. And one of the lessons that I've learned in my time building developer tooling is that really good dev tools meet devs where they are and grow with them. Um, a tool that you're going to be using every day should accommodate your workflows, but also be really adaptable as the like complexity and the nature of the work changes. And it's important for us to build really great dev tools because dev tools have a compounding effect on the world. If you make a piece of software that helps a developer or a builder do great work, your ability to magnify how much great software exists in the world increases. So I think it is super important that these dev tools accommodate people's workflows. And people's workflows are important because they love their preferences. You might have a preference for a shell, a language, a harness, a review process, and something that adapts to your workflows and preferences is going to be more enjoyable to use and more enjoyable to build software with. And it also becomes like a part of how you think and build. Um, so it's super important to be attuned to that. And this notion of tools meeting developers where they are and growing with them comes to light really clearly in the progression of AI tooling in this space. So this is the story for Warp specifically, but it's also the story for a lot of developer tools. Pre-AI era, we had the Warp Terminal, which kind of met people in their command line workflows that they were used to. And then this fantastic thing happened where AI got introduced to developers and now you had a whole new set of tools that was available to you locally on your machine. And a lot of people started to interact with agentic coding patterns in their terminal, in their IDE, in their editor. And then eventually we realized that we had kind of reached the limits of what we could do on our laptops. And we wanted agents to do work that was more longunning, that was adaptive to different constraints. and that work needed to happen in the cloud. Um, and whenever you send anything to the cloud, you adopt a lot of complexity. Um, because running things in the cloud requires us to navigate a much messier stack of infrastructure concerns. And when I say we here, I mean the people building developer tools because that is the person that I am. And it gets at one of the things that are like a core principle in how we think about unlocking capabilities here and building good developer tools is that platforms should take on complexity before it reaches the user. A really good experience should not expose anything of the leaky complexity that it handles to you. Um, and when we think about building our cloud agent platform, we try and structure it so that every primitive models this philosophy of hiding complexity from the user so they can focus on the work that matters to them. Um, the first place that this shows up when you're building a cloud agent platform is where does the agent run if it's not running on a developer's machine? Um, it needs a place to do its work like any developer would and that place is typically a sandbox. It's an isolated environment in the cloud where agents do this task. When we started building these out for our cloud agent platform, our first intuition was to provide self-hosted sandboxes so that developers had a really easy on-ramp for getting into our cloud agent platform. You didn't have to think about where your compute lived. It was just there for you. But the reality is that for teams doing serious work, they're probably managing their own infrastructure. They probably have dev boxes that they need to interact with. And so something that is hosted or managed is usually not sufficient. You really need to be able to run agent workloads on infrastructure that people bring so it adapts to their like security concerns, their deployment practices, their workflows and preferences on their team. And so we add support for not only managed hosting but also self-hosting to the platform. And that is complexity that you abstract away from the user and how the behavior is modeled. Um the next kind of component is a little bit more personal to people and it's the harness that they want to use. As we talked about earlier, people are really passionate about the tools that shape their workflows. Um one of those tools is the harness. Um who here has a preference for cloud code as a harness locally? Codeex something else entirely, right? So much diversity in the room and we want to meet people where they work. So you want to integrate multih harness support that not only accommodates preferences but also gives people the ability to do the use the right tool for the job. And flexibility isn't something that should just be like crammed into a platform because a real risk you run if you cram it in is that it becomes fragmented. Your experience with working with claude is difference working with codeex versus a custom harness that you might have. And so one of the key properties is making sure that the platform provides structure and guard rails around the harness so that the experience is consistent. Um for us this means that harnesses can interact with all of the platform native experiences. So just being able to store conversation state and rehydrate it being able to interact with the artifacts and outputs that are produced by agents whether they're PRs issues new files that are generated. All of that should kind of be structured the same way. Okay, cool. So, we gave you a place for your agent to run and we gave you a choice for what harness you use, including warp zone harness and any other harnesses that you want to bring. Um, what if one agent isn't enough to do work? That's the reality of most software engineering. I wish that I could just send off one prompt and solve all of the problems that exist in my software, but the reality is that real engineering work rarely fits inside one prompt. In a typical workflow, you might need one agent to go research a problem and plan a solution. You might need another agent to implement it. And you might need to bring in a third to validate it. And you might want each of these agents to use different harnesses and different models in order to have a real adversar adversarial and robust approach. So we have built-in support for that. You can orchestrate agents across the stack. Um with a lot of agent-based experiences, this orchestration happens via a prompt. So I say /chestrate or I cue the agent via prompting that I want it to delegate work across multiple sub aents for a task that I have here. And this orchestrator agent will do all of the messy complexity of interacting with sub aents, mediating messages between them and tracking the work that's happening for me behind the scenes with a single prompt. We abstract complexity away from the user by giving them this experience. This sort of like promptbased model for interacting with agents and sub aents is really powerful. An even more interesting one is the notion of interacting with agents and sub aents via the API. So everything in our surface area is exposed via API and I can fire off a request to say that I want to run a sub agent that is attached to a parent agent um via configuration that I provide. And this API is super magical because this is the key component of a platform. Um, it's exposing the primitives in a way that users can build on top of. Um, the thing about great APIs and SDKs is people can build on top of them, which means that they're not restricted to your UI or your opinion of how a particular experience should look. This is where like composability becomes really powerful. And so we're trying to be intentional about exposing an API for every key component of the stack. So this is APIs for spinning up agents and sub aents for managing the environments and compute that these agents are running in for working with the artifacts that they produce. All of that is exposed in an API that you can build on top of. Um, and this ability to build on top of these primitives that are exposed via an API becomes really useful because anyone can build tools that overlap on top of these agentic experiences. \[snorts\] Um, like interesting phenomena that's happened for us internally is we have a bunch of non-engineering teammates at warp who have been able to use our SDK and API to build custom Slack bots to do a bunch of things. Um, so we have folks in our developer relations team who have actually built out tooling to help us manage all of our social mentions. Um, so as tweets and Reddit posts and things are coming in, we have agents that will pick them up, do some sentiment analysis on them, try and understand what the user wants, and then propose a response that um, folks on our social media team should use and um, response to the original tweet or Reddit post or what have you. And all of this is enabled by our SDK. And you see like a plethora of these types of experiences um internally at Warp. Um we have people who have used them to help answer queries about how our product is working, do competitive research, all sorts of interesting things. Um and these primitives became a really big deal for us specifically when we decided to go open source. Um as I mentioned earlier, Warp started off as a terminal. Um but it grew into an agentive development environment and about three months ago we decided to go open source. Um this was like much anticipated long awaited. It was a huge success for us. Um the number of like GitHub stars that we had I think catapulted from around 20,000 to over 60,000. We had thousands of PRs. I'll talk a little bit more about how we've been managing that. and hundreds of contributors who had been longtime users of the platform and were finally getting a chance to build on top of it. And when we went open source, we wanted to be really thoughtful about how we could use agents to help us manage the repository. We didn't want this to be the kind of thing where agents are just writing code and firing off PRs. We want them to participate kind of meaningfully in the structure that we use to triage issues that came into the repo, provide context around them, do implementation, do reviews, but still have a space for humans to participate in this loop. And we did that. So if you go to the warp open source repo right now, you'll notice that if you file a new issue with a bug report or a feature request, an agent will kick in and start to triage the issue automatically. It'll do research across the codebase and context in the repo to understand what you're trying to propose. It might ask you questions if it feels like your original query was a little abstract to get more information. And it will kind of do the work that's historically been very hard for open source, which is somebody has a problem or a bug that they want fixed. They don't give you enough details and it's hard to get to the clarity that you need to get to to like drive the work forward. So, we can use agents to help us meaningfully in that way. They can also help draft initial specifications and work for tasks, do implementation and provide a review gate. So all PRs that get contributed to warp go through an agent managed review process and it goes through multiple iterations and we don't actually ping any of the human reviewers on our team until an agent has approved our PRs. Um, which helps manage the workload a lot for the team. So all of those thousands of PRs, the things that humans actually have to manage are only the high signal, high quality ones. And one of the key principles is that we improve the agent as um we get more PRs in the repo and we see more examples of code. One of the things that we believe is that self-improvement loops are really important way for you to enhance the overall SDLC life cycle that you're seeing. So we did this and we had a light bulb moment because it unlocked something huge. We had this like structured process that could accommodate a big influx of issues and PRs on the repo. Um and the agents were there to support anyone in bringing their idea or their bug request bug feature request or bug report to Oz or to warp and then getting it through to the actual product. Um that key insight of agents providing like structure and context was a really big thing for us because it meant that it could anyone could kind of participate in translating their intent into implementation. Um and often times the people who have really interesting intents and goals are the ones who are using software in interesting ways. And it's not always the person that's building it. It's the person who's kind of got domain knowledge in the space. And we're we're lucky because we're developers building a developer tool and that's a really unique niche to fill in. But most software is developers building tools for non-developers um or PE in situations where they don't have domain expertise. If we provide these structures and guardrails though, people who are non-developers can have the necessary tools to like ship serious software because the infrastructure to support them exists. Oh, this is where like things get buzzy. You might have heard this term of the software factory. People talk about it a lot as far as like automating how software gets built, providing these systems for doing work. Um, all of these fun things. Um, I kind of want to push back on this term a little bit. I kind of actually hate it because I don't think it gets the point across and it feels a little where's the people in this? Um, so I want to tell a story. um before I share what I think is actually the better word. So, this is a mug that I have. I bought this mug about two summers ago from a farmers market. And I stopped by this booth at the farmers market and you could just tell the person who had crafted this, the potter was just someone who was like really passionate about their work and what they do. And so, he was telling me about all of these interesting details in the mug, the specific like curve of the handle and the way he had structured it to accommodate different people's hands. He had this like specific dimple at the top of the handle where you could rest your thumb because he felt like that was like a key ergonomic detail of the Smug. He had this glazing at the top so if like your cup overflowed it wouldn't dribble down the sides the glazing would kind of catch it. So we just spent so much time thinking about the details of this mug and crafting it. And then I was kind of talking to him about his workshop like how many potters do you have? How many of these mugs are you making? yada yada. and he got more even more animated and he started talking about his workshop setup and how he had set up different stations for different components of the mug. He had talked about how he had a specific process for sourcing clay and preparing ahead of time. He talked about how he actually incorporated verification for different components of the mug. If the dimple wasn't the right size, what would you do? What part of the process would you restart? All of this thought that he had put not into the mug itself, but how the workshop existed to support the creation of the mug and how he was able to scale this to dozens of apprentices in his shop and like hundreds of mugs handcrafted per day, which is pretty impressive. And this got me thinking, I love what he did with his workshop. um he had this really great idea and he developed a serious and repeatable system that allowed anyone to take the idea of a perfect mug and turn it into the like actual existence of a perfect mug. You know, some people might think like workshops are this quaint thing where it's like a workspace for a single individual, but I think the story really shows that they're actually heavy duty systems for doing work and that they're malleable and that they react to signals and how people are interacting with the thing they're building in the space they're building it. Um, and it also underscores the like really close interaction loop that humans have with the spaces they work in and the outputs that are produced. I'm synthesizing all of these ideas and I think this is what really we're driving at when we talk about building software factories. We want to give more builders and the definition of who a builder is is expanding to non-developers serious systems for turning their ideas into code. Um, and we as individuals who've been building dev tooling or have been in software engineering for a long time have an understanding of what that serious system looks like and what kind of support it needs to give into individuals. Um, we break this down into the same techniques that my Potter friend had and the same methodologies that I talked about earlier about exposing primitives. Um, we expose things like the ability for these agents to implement automations that react to events in the real world the same way that a human in a workspace might need need to react to a real event of, you know, a kiln um being astray or a handle being broken. We need to make these systems observable. My Potter friend talked about how he actually watched the way people worked in his space and refined the process over time. That doesn't come for free. Your system has to actually be something that you can inspect and look into. And it has to improve over time. The workspace is not the static component that doesn't change ever. It needs to react to what's going on and modify itself to amend to like the goals of the people that are working in it and the product that it's producing. And it needs to be coste effective. Uh you want to reduce the number of broken mugs that come out the other end. You want to reduce the amount of buggy software that comes out of the other end of your bug of your factory. Um and you want to do this without compromising on cost without spinning too many tokens. Um, all of these principles work to achieve a shared goal. And that shared goal is building systems that remove toil and drudgery from our software process so that more people have the ability to build. We've seen the way like toil and drudgery have manifested. It could be all of the difficulty you might have reproducing a bug, the challenges of monitoring a production system. Those are things that are really hard to do. Um, and we can finally start to think about the structure of how we do them and building systems that allow us to do them repeatably um, and transferably to people who are in nontechnical roles. Um, if these ideas excite you about how we can build these robust and reliable systems for anyone to ship software, um, you could stop by the warp booth to come talk to me and the crew. We're at UG20. Um, you can also mention me on Twitter. I'm Captain Sophia on all social media, GitHub, Twitter, all of that fun stuff. Um, or just drop me an email. You can find my email on my personal site. Um, thanks for coming to this presentation. I hope you learned something interesting about some of the engineering philosophies that are driving um, the next set of work we do as far as agents, developers, and AI.