# The Agent Behind the Curtain: Building the Oz Cloud Agent Platform Safia Abdalla, Warp | AI Engineer | 20:51 Source: https://www.youtube.com/watch?v=L173Z8DpaJg Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/the-agent-behind-the-curtain-building-the-oz-cloud-agent-platform Published: 2026-08-22 Tags: agents, deployment, developer-experience, multi-agent ## TL;DR - Warp's cloud agent platform hides infrastructure complexity while supporting managed or self-hosted sandboxes and multiple agent harnesses. - Agents can delegate research, implementation, and validation to subagents through prompts or APIs, so developers can compose their own workflows. - Warp uses agents inside its open-source repository to triage issues, ask for missing detail, draft work, and filter pull requests before human review. ## Summary Safia Abdalla explains how Warp built a cloud platform for agents around a simple principle: the platform should absorb complexity before it reaches the user. Agents need isolated sandboxes, so Warp supports both managed infrastructure and self-hosted environments. Developers can bring different harnesses while conversation state and artifacts follow a consistent structure. Since engineering work rarely fits one prompt, agents can delegate research, implementation, and validation to subagents. Warp exposes these capabilities through prompts and an API, which allowed non-engineering teammates to build Slack tools for social mentions and other internal tasks. Abdalla then describes how Warp applied the same ideas to its open-source repository. Agents triage issues, ask for clarification, help implement changes, and review pull requests before human reviewers are notified. She dislikes the phrase "software factory" because it leaves out the people doing the work. Her alternative is a potter's workshop, a system with stations, verification, observation, and continuous refinement. ## Key ideas ### Developer tools should adapt to existing workflows [00:01](https://www.youtube.com/watch?v=L173Z8DpaJg&t=1s) Abdalla has spent eight years building developer tools, including work on Jupyter, Interact, and APIs and SDKs at Microsoft. She says good tools meet developers where they are and grow as their work changes. Developers bring strong preferences about shells, languages, harnesses, and review processes. A tool used every day should accommodate those choices rather than force a new way of working. She also argues that developer tools have a compounding effect because software that helps one builder can increase the amount of useful software that gets made. Warp's move from a terminal to local AI tools and then to cloud agents follows this progression. ### Cloud platforms should hide infrastructure complexity [02:43](https://www.youtube.com/watch?v=L173Z8DpaJg&t=163s) Agents eventually need to perform work that runs longer and must adapt to constraints beyond a laptop. Moving that work to the cloud introduces infrastructure concerns that users should not have to manage directly. Abdalla's platform principle is that a good experience absorbs this complexity before it reaches the user. Sandboxes provide isolated cloud environments for agents. Warp first offered managed sandboxes, then added self-hosting because serious teams often have their own infrastructure, dev boxes, security requirements, and deployment practices. The platform therefore supports both managed hosting and infrastructure brought by the customer. ### Multiple harnesses need shared platform structure [05:18](https://www.youtube.com/watch?v=L173Z8DpaJg&t=318s) Developers may prefer different harnesses, including Claude Code, Codex, Warp's harness, or a custom option. Abdalla wants the platform to accept these preferences without creating a separate experience for each one. The platform provides structure and guard rails around every harness. Conversation state can be stored and rehydrated consistently, and agents can work with the same kinds of artifacts and outputs, such as pull requests, issues, and generated files. This lets developers choose the right tool for a task while keeping the surrounding workflow coherent. ### Software work usually needs several agents [06:59](https://www.youtube.com/watch?v=L173Z8DpaJg&t=419s) Abdalla says real engineering rarely fits inside one prompt. A typical task may need one agent to research and plan, another to implement, and another to validate the result. Those agents may use different harnesses and models, which can create a more adversarial review process. Warp supports orchestration across the stack. In the prompt-based experience, an orchestrator handles communication with subagents, passes messages between them, and tracks their work. The user can ask for this delegation without managing each interaction directly. ### The API exposes primitives for custom agent systems [07:53](https://www.youtube.com/watch?v=L173Z8DpaJg&t=473s) Warp also exposes its agent platform through an API. A caller can request a subagent attached to a parent agent and provide the configuration for that relationship. Abdalla describes this as a central property of a platform because users can build on primitives instead of being limited to Warp's interface or assumptions about how an experience should work. The API covers agent and subagent creation, environments and compute, and the artifacts agents produce. This makes the platform composable for teams that need workflows the default product does not provide. ### Non-engineers can build useful tools on the SDK [09:33](https://www.youtube.com/watch?v=L173Z8DpaJg&t=573s) Warp's API and SDK enabled non-engineering teammates to create internal tools. Members of developer relations built Slack tooling for social mentions. Agents collect tweets, Reddit posts, and other incoming references, analyze sentiment, infer what a person wants, and propose a response for the social team. Other internal uses include answering questions about product behavior and doing competitive research. Abdalla uses these examples to argue that people with domain knowledge can contribute to software projects when the system supplies enough structure and guard rails. ### Agents can filter open-source work before humans see it [11:16](https://www.youtube.com/watch?v=L173Z8DpaJg&t=676s) When Warp open sourced its project, Abdalla says GitHub stars rose from around 20,000 to over 60,000, alongside thousands of pull requests and hundreds of contributors. Warp placed agents inside the repository process rather than having them simply write code and open pull requests. An agent triages new issues, researches the codebase, asks questions when a request is too abstract, drafts specifications, helps with implementation, and reviews pull requests. Human reviewers are notified only after the agent-managed review process approves a pull request. Abdalla says this leaves people with the higher-signal work and gives the agents more examples from which to improve. ### A workshop is a better model than a software factory [14:44](https://www.youtube.com/watch?v=L173Z8DpaJg&t=884s) Abdalla dislikes the phrase "software factory" because it makes the people involved disappear. She describes a potter who designed a mug's handle around how different hands hold it, added a thumb dimple, and used glazing to catch an overflow. The potter also described workshop stations, clay sourcing, preparation, and checks for whether each component met the intended size. Abdalla uses this workshop as a model for agent systems. They should react to real events, remain observable, improve from how people use them, and reduce defective output without wasting tokens or cost. ## Notable quotes - "Platforms should take on complexity before it reaches the user." (03:16) - "Real engineering work rarely fits inside one prompt." (06:51) - "All PRs that get contributed to Warp go through an agent managed review process." (12:28) - "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?" (14:50) - "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." (17:41) ## Tools & references mentioned - Warp - Warp Terminal - Jupyter Notebook Core team - Interact - Microsoft - Claude Code - Codex - GitHub - Slack - Reddit ## Who should watch - You are designing an agent platform and need to decide what infrastructure, harness, and orchestration details users should manage themselves. - Your team wants agents to work inside an existing engineering or open-source process, with human review reserved for higher-signal changes. - You want to expose agent capabilities through an API so people outside the core engineering team can build task-specific tools.