Cloud-Based Agent Orchestration Platform for Multi-Agent Coding Workflows

warp · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Cloud orchestration for AI coding agents

Warp built Oz because teams running many coding agents locally hit laptop capacity, offline execution, poor visibility, security, team coordination, and long-task limitations as development shifted from writing code by hand to prompting agents.

Constraints:

Architecture

Oz provides cloud-hosted coding-agent runs with environment definitions, sandbox hosting, support for multiple agent harnesses, automatic run tracking, artifact/conversation capture, human handoff, programmable APIs/SDK/CLI, named scheduled agents, and app-embedded launch points such as issue triage.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  developer-or-automation-trigger["developer or automation trigger"] --> oz-api-sdk-cli["Oz API SDK CLI"]
  developer-or-automation-trigger --> named-agent-scheduler["named agent scheduler"]
  developer-or-automation-trigger --> power-fixer-app["Power Fixer app"]
  power-fixer-app --> oz-api-sdk-cli
  named-agent-scheduler --> cloud-agent-environment["cloud agent environment"]
  oz-api-sdk-cli --> cloud-agent-environment
  cloud-agent-environment --> agent-harness["agent harness"]
  agent-harness --> artifact-store["artifact store"]
  cloud-agent-environment --> artifact-store
  oz-api-sdk-cli --> auto-tracking["auto tracking"]
  auto-tracking --> artifact-store
  auto-tracking --> team-visibility-dashboard["team visibility dashboard"]
  agent-harness --> human-handoff["human handoff"]
  artifact-store --> human-handoff
  human-handoff --> team-visibility-dashboard
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
developer or automation trigger Starts agent runs interactively, on a schedule, or from an internal app. Oz API SDK CLI, named agent scheduler, Power Fixer app
Oz API SDK CLI Programmable control surface for launching agents, configuring environments, and pulling artifacts/history. developer or automation trigger, cloud agent environment, auto tracking
cloud agent environment Defines toolchain, code access, sandbox, and hosting for a cloud agent run. Oz API SDK CLI, agent harness, artifact store
agent harness The coding-agent runtime, which may be Warp's agent or another harness. cloud agent environment, artifact store, human handoff
auto tracking Records links, artifacts, reasoning, and conversation history for each run. Oz API SDK CLI, artifact store, team visibility dashboard
artifact store Stores outputs, run artifacts, conversation history, and reasoning traces. cloud agent environment, agent harness, auto tracking, human handoff
human handoff Lets engineers inspect partial work, guide agents, and finish the last portion manually. agent harness, artifact store, team visibility dashboard
team visibility dashboard Shows agent runs across a team for coordination, review, and audit. auto tracking, human handoff
named agent scheduler Runs version-controlled skills as repeatable scheduled agents. developer or automation trigger, cloud agent environment
Power Fixer app Internal issue-triage app that uses Oz infrastructure to dedupe issues and launch fix agents. developer or automation trigger, Oz API SDK CLI

Data flow

A developer, schedule, or internal app launches an agent run through Oz; Oz provisions a cloud environment with selected code/tool access and an agent harness; the agent executes in the cloud while artifacts, reasoning, and conversation history are recorded; humans can watch, guide, or hand off partial work; APIs expose artifacts and history so other applications or agents can coordinate future multi-agent tasks.

3 supporting quotes
“these agents need to run on a computer somewhere in the cloud, and there's a bunch of things like maybe Daytona or E2B or Docker sandboxes or namespace.”transcript, stated
“no matter where you launch an Oz coding agent and how you launch it, you get a link to what it's doing. Um and all of the like artifacts of the agent run are automatically recorded. So if you want um to go back and see what an agent did, uh if you want to”transcript, stated
“like this is that you want it to be fully programmable. Uh and so what I mean by that is like you should be able to launch agents via API or SDK or CLI. You should be able to configure environments. You should be able to pull artifacts. You should be able to pull conversation”transcript, stated

Why this architecture

Warp moves agent work to cloud primitives because local laptop execution cannot support long-running, parallel, team-visible, programmable agent workflows without capacity, visibility, security, and coordination problems.

3 supporting quotes
“If agents are tied to your laptop, there's an issue that those agents can only run when your laptop is on and connected to the internet.”transcript, stated
“bring control to the chaos of like having multiple just like having everyone run all of their coding own coding agents on their laptops.”transcript, stated
“Um and you should do that not just for like human programmers to use, but this is actually these are the building blocks that will allow agents to actually orchestrate each other. And so our approach here has been like, you know, build this all in a very programmer-first way. So I'm going”transcript, stated

Models used: Warp coding agent · Claude Code · Codex · other agent harnesses

Scale

Alternatives considered (roads not taken)

Run coding agents only on individual laptops

Rejected because: Laptop-bound agents hit offline, capacity, visibility, and security limits as teams run multiple agents.

“multiple just like having everyone run all of their coding own coding agents on their laptops. Um And they're going to want to do this in a way that doesn't ruin the productivity gains. So you know, it's it's awesome right now that like developers are trying”transcript, stated
“Code, tools like Warp, Codex, etc. Um but it also is is creating an untenable situation, and it's also just a limiter on productivity. So you know, my prediction is this year there will be solutions for this. There's one other big important reason besides”transcript, stated

Use a single proprietary agent harness

Rejected because: Warp wants Oz to run any harness because coding agents have different strengths and teams use different tools.

“one of the things that we're working on with Oz is the ability to run any agent harness. Uh the harnesses have different pros and cons. You want something uh called like tracking. We we call this feature of Oz auto tracking, where no matter where you launch”transcript, stated
“one of the things that we're working on with Oz is the ability to run any agent harness. Uh the harnesses have different pros and cons. You want something uh called like tracking. We we call this feature of Oz auto tracking, where no matter where you launch”transcript, stated

Fully autonomous cloud jobs without human visibility

Rejected because: The speaker explicitly says cloud-agent systems should keep a human in the loop for visibility, guidance, and finishing partial work.

“you definitely, if you're going to build a system like this, want to build it so that there's still a human in the loop.”transcript, stated
“cloud uh even if they're running as part of automations or app backends so that you can uh you can guide them, you can step in if they only do 80% of the work, and make sure that you finish it off correctly. So we we just launched a product called Oz, which I'll demo in a bit, which”transcript, stated

Patterns

multi-agent-orchestration (agent-infrastructure)

Oz provides cloud primitives for running, tracking, scheduling, and eventually coordinating multiple coding agents on hard tasks.

“So this is another thing that's happening right now, and there needs to be infrastructure for it. So what are the use cases?”transcript, stated
“Um And so you're going to have a class of tasks that are amenable to multiple sorry, to multiple agents working on them at once. So this is another thing that's happening right now, and there needs to be infrastructure for it.”transcript, stated

human-in-the-loop-gate (agent-control)

Oz emphasizes visibility, handoff, and human intervention for cloud agents that only complete part of the task.

“You want handoff. So this is about human in the loop. So if an agent is you know, working uh in a cloud system and it can get only 80% of the way there, and you want an engineer to pick up what it did, that should be easy.”transcript, stated
“if an agent is you know, working uh in a cloud system and it can get only 80% of the way there”transcript, stated

observability-tracing (agent-ops)

Auto tracking records links, artifacts, reasoning, and conversation history so teams can inspect what cloud agents did.

“all of the like artifacts of the agent run are automatically recorded.”transcript, stated
“So if you want um to go back and see what an agent did, uh if you want to see how it reasoned, you get that information. You want handoff.”transcript, stated

durable-execution (cloud-agents)

Agents run away from the laptop in hosted environments and can continue while the developer is away or offline.

“you could be away from your computer. This is running in the cloud.”transcript, stated
“Superbase for cloud agents, where we're trying to make it super easy uh for developers and development teams to move these workflows off of their laptop. Um the primitives, I think this is interesting uh whether you use Oz or not, are like you want a great coding agent. Um uh or I actually”transcript, stated

tool-use-orchestration (programmability)

Oz exposes APIs, SDKs, CLIs, artifacts, conversation history, and environment configuration as primitives for agent orchestration.

“configure environments. You should be able to pull artifacts. You should be able to pull conversation history.”transcript, stated

Tradeoffs

Move agents into cloud-hosted environments.

Chose Cloud sandboxes and hosted agent runs over Laptop-only execution.

Rationale: Cloud execution enables longer running jobs, offline execution, team tracking, and app/API integration.

“orchestration and and and orchestration is part of it, but I think actually, you know, the other big part is just moving to the cloud. So if you want to do this type of workflow where you're working with coding agents and you're not, you know, stuck to your laptop, um you might think that you just”transcript, stated
“Having these things in the cloud though opens up other possibilities.”transcript, stated

Support multiple agent harnesses.

Chose Harness-agnostic orchestration over A single built-in Warp agent only.

Rationale: Different coding agents have different capabilities, and teams want to orchestrate the tools they already use.

“this is using Warp's built-in agent, but uh the thing that we're working towards is supporting this actually to work with any agent harness.”transcript, stated
“want to basically take the coding agents that everyone in here is using all the time, whether again it's like Cloud Code or Codex or Warp's coding agent or whatever, and you're going to want to be able to program those to run off of your laptop. That's the theme. I know I call it orchestration”transcript, stated

Expose agents as programmable infrastructure.

Chose APIs, SDKs, CLI, artifacts, and history over A purely interactive terminal UI.

Rationale: Programmability lets agents be embedded in automations, internal apps, and future multi-agent coordination workflows.

“the ability to use agents um as like an intelligence feature that you put into apps.”transcript, stated
“yeah, the the way to think about what we've built here and the way that we're approaching this is like it's a set of APIs for running and managing agents in the cloud. And the sort of next step for it is like it lets people who are trying to build multi-agent systems where the agents talk to each”transcript, stated

Gotchas (what bit them)

Local agent adoption creates a new class of team visibility and security problems.

Root cause: Agents that run independently on laptops are hard for engineering leaders to inventory, inspect, and control.

Resolution: Move runs into a tracked cloud platform with team visibility and artifacts.

“you can't have a a clear view of like do you have security holes with your agents?”transcript, stated
“But this is all using that exact same infrastructure so that when I launch this agent to do the fix, again, you get something that is um tracked across your team. So, this will take a second to to spin up, but this also would show up in this same tracking location.”transcript, stated

Long single-threaded agents can forget context.

Root cause: Hard tasks can exceed context windows and cause agents to lose relevant information.

Resolution: Add cloud primitives for longer, harder tasks and eventual multi-agent coordination.

“exceeds its context window. Maybe you can pack your agent context, it starts to forget stuff.”transcript, stated
“you need some sort of like primitives for doing longer, harder tasks.”transcript, stated

Agent automations still need inspection and handoff.

Root cause: Agents may complete only part of a task or need correction even when they run inside automations or app backends.

Resolution: Record artifacts and conversation history, expose links, and make human handoff easy.

“even if they're running as part of automations or app backends so that you can uh you can guide them”transcript, stated

Evaluation

The talk evaluates Oz through demos and use cases: local-to-cloud agent launches, team tracking, named scheduled agents, issue deduplication, and launching fix agents from an internal TUI app.

Metrics: number of concurrent agents · cloud run traceability · artifact and conversation-history availability · team-wide visibility · scheduled named-agent runs · issue deduplication over thousands of issues · handoff completeness

3 supporting quotes
“all of these agent runs are actually being tracked now across the team.”transcript, stated
“these named agent runs become something that you can set up across your team.”transcript, stated
“Oz doing is automatically de-duping every issue that that gets filed.”transcript, stated

Outcomes

Concrete scale signals include multiple parallel agents, thousands of GitHub issues in the internal triage app, repeatable scheduled agents, and team-wide run tracking.

3 supporting quotes
“So we we just launched a product called Oz, which I'll demo in a bit, which you can think of as kind of like you know, Vercel for cloud agents or Superbase for cloud agents, where we're trying to make it super easy uh for developers and development teams to move these workflows off of their laptop.”transcript, stated
“turning agents from a solo individual laptop sport into a team thing”transcript, stated
“how do you go from a concrete plan for a hard task that might benefit from multiple agents”transcript, stated