> For the complete documentation index, see [llms.txt](/llms.txt).
> Markdown versions of each page are available by appending .md to any URL.

# Stack overview

The layers of the Warp stack: clients, the control plane, execution planes, data stores, 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](/_astro/warp-stack-overview.A0AU0v5D_2wNOsv.webp?dpl=dpl_AwE7pvFNUprhCfZ3wJEj58XDtgd4)

## Components

1.  **Clients** - The surfaces that start and observe work: the Warp app, the Oz CLI, the web app and cloud agent dashboard, the Warp Factories control room, and MCP clients connected through the [Factory MCP](/factories/factory-mcp/). All clients talk to the same control plane APIs.
2.  **APIs** - The control plane’s entry points: a GraphQL API used by Warp’s own clients, the REST [Agent API and SDKs](/reference/api-and-sdk/) for programmatic use, a webhook receiver for [integration](/platform/integrations/) events, and the hosted Factory MCP endpoint.
3.  **Control plane services** - The coordination layer. Agent orchestration owns run workflows and state; triggers evaluate [schedules](/platform/triggers/scheduled-agents/) and automations; identity and configuration manage teams, [secrets](/platform/secrets/), [environments](/platform/environments/), and [runners](/platform/runners/); inference routing brokers every model call; observability keeps run records and shared sessions; and the codebase index powers [Codebase Context](/agents/capabilities/codebase-context/) retrieval.
4.  **Data stores** - A relational database for platform state, a vector index for codebase embeddings, object storage for run data such as transcripts and artifacts, and a cache plus event delivery for real-time updates. All stored data is encrypted at rest.
5.  **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](/platform/warp-hosting/).
6.  **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](/platform/self-hosting/).
7.  **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](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) (Anthropic, OpenAI, Google, xAI, Fireworks), embedding providers for the codebase index, and Stripe for billing.

## Related pages

-   [Cloud agent run lifecycle](/platform/architecture/cloud-agent-run-lifecycle/) - Trace one run through these layers step by step.
-   [Data security and boundaries](/platform/architecture/data-security-boundaries/) - Where each class of data lives and travels.
-   [Deployment patterns](/platform/deployment-patterns/) - How teams combine these layers in practice.
