Skip to content
Warp

Automation Platform > Architecture

Stack overview

Open in ChatGPT ↗
Ask ChatGPT about this page
Open in Claude ↗
Ask Claude about this page
Copied!

The layers of the Warp stack: clients, the Warp control plane, the execution planes, and the external systems agents work with.

The Automation Platform splits into a small number of layers: clients that people and programs use, a Warp-operated control plane that coordinates everything, execution planes where agents actually run, and the external systems agents read from and write to.

Warp stack overview diagram showing clients, the Warp control plane, Warp-hosted and customer-hosted execution planes, and external systems

Components

Section titled “Components”
  1. Clients - The surfaces that start and observe work: the Warp app, the Oz CLI, the web app and cloud agent dashboard, the factory dashboard (the control room in the diagram), and MCP clients connected through the Factory MCP. All clients talk to the same control plane APIs.
  2. APIs - The control plane’s entry points: the REST Agent API and SDKs, a webhook receiver for integration events, and the hosted Factory MCP endpoint.
  3. Control plane services - The coordination layer. Agent orchestration owns run workflows and state; triggers evaluate schedules and automations; identity and configuration manage teams, secrets, environments, and runners; inference routing brokers every model call; and run history, sessions, and costs keep every run observable. Run data — transcripts and selected outputs — is retained by Warp, with an optional export copy to customer-owned S3 or GCS on Enterprise plans.
  4. Warp-hosted execution - The default execution plane. Each cloud agent run gets an isolated, per-run sandbox provisioned on a runner’s compute shape (OS, architecture, vCPUs, memory), with the workspace prepared from an environment. See Warp-hosted execution.
  5. Customer-hosted execution - The Enterprise execution plane on your infrastructure. A managed worker (the oz-agent-worker daemon) connects outbound and executes tasks in Docker containers, Kubernetes Jobs, or directly on the host; unmanaged setups run the Oz CLI inside your own CI or orchestrator. See Self-hosting.
  6. External systems - Everything the platform integrates with: your SSO or identity provider for authentication, source control (GitHub, GitLab, Bitbucket, Azure DevOps), integration providers (Slack, Linear, Jira), LLM providers under Zero Data Retention (Anthropic, OpenAI, Google, xAI, Fireworks), embedding providers, the compute providers that host Warp-hosted sandboxes, and billing.
Section titled “Related pages”