Why Agents are Driving Software Development to the Cloud
Zach Lloyd, CEO of Warp, explains why the future of software development is moving from local, interactive agents to cloud-native, collaborative systems. He discusses the flaws in the "dev box" sandbox model, the decline of traditional SaaS interfaces in favor of "just-in-time apps," and how platforms like Warp's Oz are providing the necessary orchestration, observability, and access control for teams to effectively deploy AI agents at scale.
The paradigm for using AI coding agents is undergoing a fundamental shift from a “solo sport” on local laptops to a “team sport” in the cloud. This transition is essential for building cumulative memory, enabling asynchronous workflows, and providing the transparency and governance that engineering teams require.
Cloud-Native Agents vs. Local Sandboxes
There’s a common misconception that moving agents to the cloud simply means setting up a “cloud dev box” and letting an agent run loose inside it. A more effective and secure paradigm is to treat agents as cloud-native teammates, each with its own specific set of permissions and a dedicated workspace. This approach mirrors the serverless model of Lambdas or cloud functions rather than long-running virtual machines.
This granular, least-privileged model is crucial because different agents perform different tasks. For example:
- An agent automating CRM tasks shouldn’t have access to the production codebase.
- An agent checking for fraud might need access to a production database but not other systems.
By defining agents with specific roles and access controls, teams can avoid “agent chaos” where an agent with too much context uses the wrong tool or accesses sensitive data unnecessarily.
The Shift to a Collaborative, Cloud-First System
The real value of moving agents to the cloud lies in creating a centralized, collaborative system. Last year was about interactive agents on laptops; this year is about building a system where agent activity is tracked, knowledge is accumulated, and collaboration is seamless.
Warp’s cloud orchestration platform, Oz, is built to facilitate this. It allows teams to:
- Gain Transparency: See what all agents on the team are doing, including reviewing the full history of how a pull request was generated—the plan, the conversation, and the verification steps.
- Accumulate Knowledge: Create and share “skills” across the team. For instance, a data team can create a skill that allows any engineer (or even non-engineer) to use an agent to query the data warehouse, with the agent understanding the schema and tables.
- Enable Asynchronous Work: Agents can run tasks even when a developer’s laptop is closed.
This centralized approach, much like the shift from Microsoft Word on individual desktops to Google Docs in the cloud, makes agents a shared, visible, and continuously improving team asset.
Core Principles for an Agentic System
For enterprises to trust agents with production work, the underlying platform must provide a robust set of capabilities. These are the foundational pillars for any scalable agent system:
- Auditability and Provenance: A complete audit trace is non-negotiable for debugging, security, and compliance. You must be able to see exactly how an agent arrived at a particular result.
- Observability and Steering: Teams need the ability to see what an agent is doing in real-time and intervene to change its direction if necessary.
- Handoff and Steering: Agents are not infallible. The system must support a seamless handoff from an agent to a human developer to pick up, review, or complete a task.
- Access Control: Granular permissions are essential to limit what agents can access and prevent unintended consequences.
- Cumulative Memory: The system must have a mechanism for memory, allowing agents to improve over time by building on past interactions and shared context.
- Evals: You need the ability to measure agent performance to understand what’s working and drive improvement.
- Flexible Deployment: Companies need agents to run within their existing environments and infrastructure without requiring a massive “forklift” migration of code.
- Programmability: Every function should be API-first. An SDK should be available for launching agents, retrieving artifacts, and integrating agentic workflows into other systems.
The Future of SaaS and “Just-in-Time Apps”
The way we interact with software is changing. The era of specialized, long-lived SaaS applications with complex UIs is giving way to a new model centered on a single “meta-app” or “browser for agents.” Instead of learning how to use dozens of different tools, a knowledge worker will simply state their intent to an agent, which will then perform the task or even generate a temporary, purpose-built interface—a “just-in-time app.”
For example, rather than building a presentation in Figma or Google Slides, you can ask an agent to create a website based on your brand manual. The agent handles the code, styling, and structure, going directly from intent to outcome.
While systems with deep, complex business logic (like Stripe) will remain, many applications that are essentially a simple UI on top of a database are at risk of being disintermediated. The value is shifting from the user interface to the underlying data, schemas, and skills that an agent can use.
Re-evaluating GitHub and Developer Workflows
The traditional developer workflow, with its distinct “inner loop” (local development) and “outer loop” (GitHub for code review), is inefficient for agent-driven development. It’s a “ridiculous flow” to have an agent write code, push it to GitHub, use a separate code review UI, and then pull it back down.
Collaborative code review, a hero feature of GitHub, should happen directly within the agent’s workbench as the code is being written. This shift is already happening, with more functionality moving from platforms like GitHub into the agentic development environment itself. While Git is deeply entrenched and unlikely to be replaced soon, its suitability for tracking agent metadata and workflows is an open question. Ultimately, platforms like GitHub are at risk of disruption if they don’t pivot to treating agents, not just humans, as their primary customer.
Strategy and Multi-Agent Orchestration
In a market where large labs can subsidize token costs, the strategy is to be a complementary workbench that offers choice and prevents vendor lock-in. By supporting multiple agent harnesses (Warp’s own, Claude, Codex, Gemini, etc.), a platform can provide a superior, integrated user experience while giving companies the flexibility to use open-weight models and avoid being tied to a single provider.
The next frontier is multi-agent orchestration. Oz is being built with flexible primitives to support various patterns of agent collaboration, such as:
- A “team leader” agent that spins up multiple agents for a complex task.
- Parallel agents working on different parts of a problem.
- Adversarial patterns, where one agent writes code and another is tasked with finding bugs in it.
The optimal patterns for agent collaboration are still unknown, but building a flexible system allows for experimentation and the discovery of novel, highly effective workflows.