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

# Automation Platform overview

The Automation Platform provides shared execution, configuration, and APIs for Warp Factories and standalone cloud agents.

[Warp Factories](https://docs.warp.dev/factories/) and [standalone cloud agents](https://docs.warp.dev/platform/) run on the Automation Platform. It provides the execution, configuration, and APIs they share.

For a team workflow that takes issues through planning, implementation, and review, start with the [Warp Factories quickstart](https://docs.warp.dev/factories/quickstart/) in the [Warp Factories web app](https://platform.warp.dev). For a single run in Warp, use the [cloud agents quickstart](https://docs.warp.dev/platform/quickstart/). See [transitioning from Oz](https://docs.warp.dev/platform/transitioning-from-oz/) if you already use the legacy web app, CLI, or SDKs.

## How a run works

A run starts with a request or event and ends with a result you can inspect:

1.  A **trigger** fires: a schedule, an integration event like a Slack mention or a CI failure, an API call, or a manual start.
2.  Warp creates a **task**, the tracked record of the run. The trigger’s context travels with it: the Slack thread, the PR metadata, the CI logs.
3.  The agent executes on a **host**, optionally inside an [environment](https://docs.warp.dev/platform/environments/) that defines its image, repos, and setup.
4.  The task produces **outputs**: a pull request, a Slack reply, a report, or just a transcript and summary.

![Flow diagram: a trigger kicks off an agent, which runs in an environment and creates artifacts, on either Warp-hosted or self-hosted infrastructure](https://docs.warp.dev/_astro/most-flexible-platform-for-building-with-agents.DwVtxk0__ZRnchf.webp?dpl=dpl_3rVk6HoVcVxapDeEParkKbKD8rU5)

## Integrations and triggers

[Factory automations](https://docs.warp.dev/factories/automations/) route events and schedules to factory agents. Connect the [tools your team uses](https://docs.warp.dev/factories/connect-your-factory/), or use [webhooks](https://docs.warp.dev/factories/webhooks/) and [factory endpoints](https://docs.warp.dev/factories/factory-api/) for custom intake.

Standalone agents also have [integrations](https://docs.warp.dev/platform/integrations/) and [scheduled runs](https://docs.warp.dev/platform/triggers/scheduled-agents/). For CLI setup, use `oz integration create` on the Oz CLI; see the [integration setup guide](https://docs.warp.dev/agents/cli/oz-cli/integration-setup/).

## Tasks and tracking

Warp tracks every run as a task: its status, transcript, and outputs stay available after the run finishes. Watch or steer a live run with [session sharing](https://docs.warp.dev/agents/local-agents/session-sharing/), browse history in the [management UI](https://docs.warp.dev/platform/managing-cloud-agents/), or query it from the [Oz CLI](https://docs.warp.dev/agents/cli/oz-cli/) and the [API](https://docs.warp.dev/factories/api-and-sdk/). Access control decides who can run, view, or intervene in tasks.

To fan work out across parent and child agents, see [multi-agent orchestration](https://docs.warp.dev/platform/orchestration/).

## Environments

An [environment](https://docs.warp.dev/platform/environments/) defines what a run needs: a Docker image with your toolchain, the repositories to clone, and setup commands. Automated runs (integrations, schedules, API calls) use an environment so every run starts from the same setup; interactive local runs use your machine as-is and don’t need one. Define one environment per codebase and reuse it across triggers.

## Hosts

A host is where the agent executes. By default runs execute on [Warp-hosted infrastructure](https://docs.warp.dev/factories/warp-hosting/), with nothing to set up. On Enterprise plans, [self-hosted runners](https://docs.warp.dev/factories/self-hosting/) keep code and execution inside your own network while Warp still tracks the runs.

![Architecture diagram: Warp-designed and customer-defined triggers create an agent task, which is routed to agent runners on Warp or customer infrastructure](https://docs.warp.dev/_astro/platform-architecture.D5hwZrrM_Z1beFr7.webp?dpl=dpl_3rVk6HoVcVxapDeEParkKbKD8rU5)

## The CLI

The [Oz CLI](https://docs.warp.dev/agents/cli/oz-cli/) starts and manages runs where there’s no UI: CI jobs, scripts, and remote servers. Start a run with `oz agent run`, and it reports progress to Warp like any other task, so work that starts on a CI runner shows up alongside everything else your team runs. For interactive sessions, use [agents in the Warp app](https://docs.warp.dev/agents/).

## API and SDKs

Use the [Warp Platform API and SDKs](https://docs.warp.dev/factories/developer-tools/) to send work from your own services. [Factory endpoints](https://docs.warp.dev/factories/factory-api/) dispatch by factory UID; [agent and run endpoints](https://docs.warp.dev/factories/api-and-sdk/) start standalone runs and inspect, continue, or cancel runs.

The official [`warp-platform-sdk` Python package](https://pypi.org/project/warp-platform-sdk/) and [`@warp-dot-dev/warp-platform-sdk` TypeScript package](https://www.npmjs.com/package/@warp-dot-dev/warp-platform-sdk) provide typed requests, retries, and error handling.

## Secrets

Agents often need credentials for APIs, cloud providers, databases, and MCP servers. Store them as [secrets](https://docs.warp.dev/platform/secrets/), and Warp injects them at runtime without exposing the values in logs or the UI. Secrets can be scoped to the whole team or to one person.

## Shared configuration

For factories, declare shared [skills](https://docs.warp.dev/factories/factory-skills/), MCP servers, and execution defaults in the [factory definition](https://docs.warp.dev/factories/factory-as-code/). Standalone workflows also use [MCP servers](https://docs.warp.dev/platform/mcp/), [rules](https://docs.warp.dev/agents/capabilities/rules/), [saved prompts](https://docs.warp.dev/knowledge-and-collaboration/warp-drive/prompts/), and [environment variables](https://docs.warp.dev/knowledge-and-collaboration/warp-drive/environment-variables/); follow each reference for its scope and setup.

## Warp Factories

Use [Scorers](https://docs.warp.dev/factories/measure-and-improve/scorers/), [benchmarks](https://docs.warp.dev/factories/benchmarks/), and [Self-improvement](https://docs.warp.dev/factories/measure-and-improve/self-improvement/) to evaluate factory work and propose changes to its configuration. See [measure and improve](https://docs.warp.dev/factories/measure-and-improve/) for metric definitions and limitations.

## Related pages

-   [Warp Factories quickstart](https://docs.warp.dev/factories/quickstart/) - Create a factory and send its first work item.
-   [Architecture](https://docs.warp.dev/platform/architecture/) - reference diagrams of the stack, the run lifecycle, and data boundaries.
-   [Cloud agents](https://docs.warp.dev/platform/) - what cloud agents are, how they get triggered, and how to run them with or without the Warp app.
-   [Cloud agents quickstart](https://docs.warp.dev/platform/quickstart/) - run your first cloud agent in about ten minutes.
-   [Environments](https://docs.warp.dev/platform/environments/) - define the toolchain and repos a run executes against.
-   [Warp Platform API](https://docs.warp.dev/factories/api-and-sdk/) - drive the platform programmatically.