Zach Lloyd argues that agents should run as cloud-based teammates with separate permissions, workspaces, and roles rather than as unrestricted cloud computers.
2
He expects agents to become the main interface for knowledge work, generating just-in-time apps and replacing many long-lived software interfaces.
3
He says agent platforms need audit trails, handoff, access control, memory, evaluations, flexible deployment, programmability, and live observability before companies can use them at scale.
Summary
Zach Lloyd argues that coding agents should move off individual laptops and into a shared cloud system. He compares agents to teammates or cloud functions, each with its own permissions, workspace, memory, and task. Warp's Oz platform records agent plans, conversations, verification steps, and outputs so teams can review work, reuse knowledge, steer agents, and keep data in company-controlled infrastructure. Lloyd also expects agents to change how people use software. Instead of learning many SaaS interfaces, users may ask one agent to query data, build a spreadsheet, create a presentation, or produce a small interface when needed. He is candid about the costs: coordinating many agents creates mental load and context switching. He also thinks GitHub's collaborative code review is vulnerable because agent-written code can be reviewed inside the same workbench. Warp supports multiple coding harnesses, including Claude Code and Codex, since companies need choice and should avoid dependence on one model provider.
Agents need separate roles and permissions instead of one shared sandbox
Zach Lloyd distinguishes between putting an agent inside a cloud computer and running agents as cloud teammates. Each agent should have its own role, workspace, and least-privilege access. At Warp, one agent can touch the CRM, while another checks for fraud and needs access to a production database. Those permissions should not be shared automatically with the codebase or with every other system. Lloyd compares this design to Lambda functions or cloud functions, which run specific tasks instead of behaving like long-lived servers. He is not opposed to sandboxes, but he thinks the cloud-computer analogy leads teams toward the wrong technical model.
Teams need centralized agents with shared history and reusable knowledge
Lloyd says coding agents are moving from a solo activity to a team activity. Local agents often start from scratch, while a centralized system can retain cumulative memory, run when a laptop is closed, and show what agents are doing. In Oz, he can inspect an agent's plan, conversation, and verification steps while reviewing a pull request. Warp also lets teams create shared environments and skills. One data-team skill understands the company's data warehouse and dbt tables, allowing engineers and go-to-market staff to perform data analysis without rebuilding that context each time.
Agent knowledge needs controlled distribution to avoid overload and mistakes
Demetrios Brinkmann asks how companies should manage skills, prompts, rules, and operating procedures as usage grows. Lloyd says organizations cannot expose everything to every agent. That creates agent chaos, lets agents perform unwanted actions, and overwhelms their limited context. He compares the need to organize agent knowledge with the industry's long investment in SaaS for human knowledge workers, although the underlying primitives are different. Agents need understandable data schemas, permitted actions, and a way to report artifacts. The challenge is deciding what belongs with a team, what belongs across a company, and how those skills are stored and governed.
Agents may become the main interface for knowledge work
Lloyd describes Warp, Claude Code, and Codex as examples of a meta app or agent browser. A user asks one agent to perform a task instead of opening a separate application for every kind of work. He gives data analysis as an example: Warp can create a spreadsheet, formulas, tables, and charts on demand. He also asks agents to create websites instead of building presentations manually in Google Slides or Figma Slides. He expects many simple applications that place a database behind a fixed interface to lose value. Systems with complex, durable business logic, such as Stripe, still have a reason to exist.
Just-in-time apps can replace software that people must learn
Demetrios describes building an Electron app for creating podcast clips, then realizing that an agent could perform the same process from a skill. The workflow can extract a transcript, use Remotion, and create the clip without a drag-and-drop interface. Lloyd agrees that teams can encode this knowledge in a skill and ask one agent for the result. When an interface is useful, the agent can generate a small just-in-time app during the interaction. Lloyd expects long-lived applications that require users to learn their controls to become less common, although data, code, and deterministic business processes will remain necessary.
Clear communication and iteration become central skills
Lloyd says agents can follow expressed intent, but they cannot yet read a user's mind. People often discover what they want only after seeing an initial result, so useful work depends on repeated correction and refinement. He considers the ability to communicate clearly, write well, think precisely, and express intent an important skill for future knowledge workers. This differs from learning to program, although the abilities are related. Demetrios agrees that articulating an internal idea so an agent can turn it into an outcome is becoming more valuable. Lloyd's own workflow involves asking for a shape, rejecting the first version, and iterating toward something useful.
Agent platforms need traces, controls, memory, evaluations, and live access
For Oz, Lloyd lists several requirements for a scalable agent system. It should keep an audit trace, support handoff when an agent cannot finish, enforce granular access control, retain cumulative memory, and measure performance through evaluations. It should run in existing company environments and expose APIs and an SDK so agent work can be launched and retrieved programmatically. Observability adds another layer: people should be able to open a link, see what an agent is doing, and steer it from anywhere, including a phone. These records support debugging, compliance, context management, and handoff between agents and developers.
Multi-agent orchestration should remain flexible and support multiple harnesses
Warp is building orchestration above individual coding harnesses. Oz can coordinate patterns where a lead agent assigns work to several agents, with others designing or verifying the result. Lloyd does not believe there is one correct structure, such as a hierarchy or a peer team, so Warp plans to provide flexible composition plus some ready-made patterns. Warp can also run Claude Code, Codex, and other harnesses. Teams can compare their performance, token efficiency, and pull request throughput. Lloyd advises companies not to lock their stack to one frontier lab, since open-weight models may change the economics and reduce dependence on a single provider.
Agent-written code moves review into the development workbench
Lloyd thinks GitHub's inner-loop and outer-loop workflow is inefficient for agent-written code. Sending work to GitHub, reviewing it there, and pulling it back into the development environment creates unnecessary movement. Warp keeps iterative code review beside the agent's work while still using Git for source control and checkpointing. Lloyd expects collaborative code review, one of GitHub's defining features, to move into agent workbenches. He also dislikes Git's model and says Google used a Perforce-based system when he worked there, but he expects Git to remain because so much tooling and scripting depends on it. The larger risk is that GitHub may need to treat agents as its primary customer.
"I think that the primitive that makes more sense to me is actually like imagining your agents as sort of like teammates who run in the cloud."Zach Lloyd01:35
Who should watch
You are deciding whether coding agents should run on developer laptops, shared cloud infrastructure, or isolated task environments.
Your team is trying to manage agent permissions, shared skills, execution history, or handoffs across several users and workflows.
You are building an agent platform and need a concrete list of observability, deployment, orchestration, and API requirements.
