The Agent Behind the Curtain: Building the Oz Cloud Agent Platform — Safia Abdalla, Warp

For Safia Abdalla, eight years building developer tooling led to a practical design principle: tools should meet developers where they are and grow with them. Her work spans open-source notebook tooling, APIs and SDKs at Microsoft, and cloud agents at Warp. A tool used every day must accommodate existing habits while adapting as the work becomes more complex. 0:12

Preferences for a shell, language, harness or review process shape how developers think and build. Accommodating those preferences makes a tool more enjoyable to use—and matters beyond the individual developer. Useful developer tools have a compounding effect: helping builders do better work increases the amount of good software they can create.

Warp’s progression follows that changing work. It began as a terminal that fit existing command-line workflows. Local AI tools then made the terminal, IDE and editor places where agents could write software. The next demand was for work that ran longer and adapted to constraints beyond a developer’s laptop. Moving that work to the cloud created a new problem: somebody now had to manage a messier infrastructure stack. 2:12

The principle behind Warp’s cloud agent platform is that platforms should absorb complexity before it reaches the user. Cloud infrastructure still needs engineering. The platform’s job is to turn it into useful capabilities so builders can concentrate on the task rather than coordinate every supporting system themselves.

The first practical question is where an agent works. A sandbox supplies an isolated environment in the cloud, serving the role a working machine does for a developer. Warp supports both managed hosting and self-hosting. Managed compute offers an easy entry point because the user does not have to arrange where the workload runs. Teams with their own infrastructure also need agents to work on the machines they bring, including existing development boxes. 3:41

That choice follows from the team’s operating environment. Security concerns, deployment practices and established workflows can make managed hosting insufficient. Supporting infrastructure supplied by the team lets agent work fit those constraints while the platform presents a common way to work with it.

The next choice is the harness: the agent tooling a developer wants to use for the job. Claude Code, Codex, Warp’s own harness and custom harnesses represent different preferences and capabilities. Multi-harness support preserves that choice, but it creates a risk: each option could become its own disconnected experience, with different ways to resume work or retrieve outputs.

Warp addresses that fragmentation through shared platform behavior:

• Conversation state: Harnesses can store a conversation and rehydrate it—restore the saved state so work can continue.
• Artifacts: Pull requests, issues and generated files fit the same platform structure, whichever harness produces them.

The execution tool may differ, while the surrounding experience for continuing work and handling its results stays consistent.

A place to run and a preferred harness do not make a whole engineering workflow fit inside one prompt. Researching a problem, implementing a solution and validating the result can require separate agents. Those agents may use different harnesses and models to bring different approaches to the work, including an adversarial check. That diversity does not by itself establish that their conclusions will be independent or correct. 6:40

Prompt-based orchestration makes coordination accessible from the same interface used to request work. A user can invoke /orchestrate or ask for delegation in a prompt. The orchestrator then interacts with sub-agents, mediates their messages and tracks their work. The user supplies the task; the orchestrator handles the ongoing coordination that the task creates.

What coordination disappears behind that single prompt? The diagram places the orchestrator between the request and the participating sub-agents. Its branches show delegation and message handling, rather than a requirement that every workflow run all roles simultaneously.

An API opens a second route into these capabilities. A request can create a sub-agent attached to a parent agent using supplied configuration. APIs also expose agent creation, environment and compute management, and the artifacts agents produce. This lets a builder compose an experience around their own work instead of fitting everything into Warp’s UI. 8:10

The API’s value becomes concrete in tools built by non-engineering teammates at Warp. They used the SDK and API to create custom Slack bots. Developer relations teammates built tooling for managing incoming social mentions, placing agents inside an existing team workflow rather than asking the team to move its work into a coding interface. 9:09

Follow one incoming tweet or Reddit post through that tooling. It arrives as a social mention. An agent picks it up, analyzes sentiment and tries to understand what the user wants. The output becomes a proposed response for the social media team to use. The observable change is from an incoming post to a response suggestion that people can act on; the described workflow stops short of automatic posting.

Other internal uses include answering questions about how the product works and conducting competitive research. The common enabling mechanism is access to reusable platform operations through the SDK. People close to a task can assemble a tool around that task without waiting for the platform team to design every possible interface.

Opening Warp’s source made those platform operations useful at a different scale. Abdalla recalls GitHub stars growing from around 20,000 to over 60,000, alongside thousands of pull requests and hundreds of contributors. The repository needed a process for handling that influx while leaving room for humans to participate. 10:40

The first intervention happens before implementation. Filing a bug report or feature request triggers an agent that researches the codebase and repository context. If the request is too abstract, it asks questions. This addresses a familiar open-source bottleneck: a user knows something is wrong or wants a change, but the initial issue lacks enough detail to drive the work forward. Research and clarification help turn that intent into an actionable task. 11:39

Agents can then help draft initial specifications and implement tasks. Review is another explicit stage: every contributed pull request goes through an agent-managed process with multiple iterations. Warp does not ping its human reviewers until an agent has approved the pull request. That notification rule concentrates human attention on contributions that have cleared the automated review gate.

Where does the human handoff happen? The diagram separates issue clarification from the pull-request review loop and places the notification after agent approval. The reported benefit is a more manageable human review workload; the talk does not quantify the gate’s missed defects or rejected good contributions, so approval is a filtering step rather than a guarantee of quality.

The process also supplies material for improving the agent as more pull requests and code examples arrive. Abdalla identifies this feedback loop as important to the software development life cycle, without specifying how the agent is updated. The significant design decision is that the repository workflow itself evolves with the work it encounters.

That structure has a consequence beyond handling volume. Domain knowledge often belongs to the person using software in an interesting way, rather than the person building it. Warp’s developers happen to be building a developer tool, but many teams build for people whose expertise they do not share. Clarification, specifications, implementation support and review give those users a route from intent toward a product change. Extending that route to non-developers is the larger ambition.

The phrase “software factory” gives Abdalla pause because it loses sight of the people doing the work. Her alternative begins with a mug bought at a farmers market. Its maker had thought carefully about the handle’s curve, a dimple for resting a thumb and glazing at the top intended to catch overflow. Those details express judgments about how people will use the finished object. 14:39

The potter became even more animated when describing the workshop that supported those judgments. Different stations handled different components. Clay was sourced and prepared ahead of time. Verification checked components and determined where work should restart if something was wrong—for example, if the thumb dimple had the wrong size. In Abdalla’s account, this system supported dozens of apprentices and hundreds of handcrafted mugs per day.

The useful analogy is the relationship between craft and repeatability. A good idea becomes easier for others to realize when the workspace supplies prepared inputs, appropriate stations and checks that guide correction. The workshop can scale while remaining responsive to its workers and the objects they make. For software, that means giving a widening group of builders serious systems for turning ideas into code, with experienced engineers helping shape the support those systems provide.

The workshop analogy ends in concrete engineering requirements. Exposing primitives is only part of the job; the system also needs to respond to what happens during work. 18:07

• Event-driven automation: Agents should react to real-world events, as workers respond when a component breaks or equipment needs attention. The earlier issue-triage and social-mention tools show this pattern in software.
• Observability: People must be able to inspect the system and see how work proceeds. The potter watched people working and used those observations to refine the process.
• Improvement over time: The workspace must change with the goals of its users and the product it produces. Its initial arrangement is a starting point for continued adjustment.

Cost places another constraint on that improvement. Reducing broken mugs—or buggy software—must remain affordable. In an agent system, repeated work consumes tokens, so adding activity is not automatically progress. The goal is to improve what comes out while keeping the cost of producing it under control.

The work worth removing includes the difficulty of reproducing bugs and monitoring production systems. Those tasks require structure, not merely another code-generation prompt. Making them repeatable also makes them easier to transfer to people in nontechnical roles. The platform’s purpose is to remove toil and drudgery so more people can build, while the workshop keeps the people, their judgment and the evolving process in view.

For a conversation about these engineering philosophies, Abdalla closes by inviting builders to contact her. Her personal site provides the email contact she mentions, offering a practical way to follow up on the systems behind the platform.