> 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

Start with Warp Factories, or use the Automation Platform's shared execution, configuration, and APIs for 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.

## Start with a factory

For a team workflow with planning, implementation, and review, start with the [Warp Factories quickstart](https://docs.warp.dev/factories/quickstart/). Then configure its [agents](https://docs.warp.dev/factories/factory-agents/configuration/), [automations](https://docs.warp.dev/factories/automations/), and [tools](https://docs.warp.dev/factories/mcp/).

Already using the Oz web app, Oz CLI, or SDKs? Use [transitioning from Oz](https://docs.warp.dev/platform/transitioning-from-oz/) to assess that workflow. The [cloud agents overview](https://docs.warp.dev/platform/) retains standalone setup and management entry points.

## How a run works

A trigger starts work: a schedule, a message in a connected tool, or a request from the app, CLI, or API. Its context tells the agent what to investigate or change, such as an issue description, pull request diff, or failed-build logs.

The agent executes on its configured host using the available repositories, tools, and credentials. A run records its progress and produces results such as a pull request, report, or transcript. For example, send failed-build logs with a request for the agent to investigate and propose a fix for review. See [how Warp Factories work](https://docs.warp.dev/factories/how-factories-work/) for the factory task lifecycle and human review points.

![A trigger starts an agent, which runs in a configured environment and produces artifacts such as plans, pull requests, and conversation records.](https://docs.warp.dev/_astro/cloud-agent-run-flow.C5BGK_AS_Z2nmHs6.webp?dpl=dpl_CMfjHAYpfiJ5S3dGnn6h1hYaQp4k)

An environment-backed run produces reviewable artifacts.

The diagram illustrates an environment-backed run. Factories manage workspace setup by default; selecting a separate existing environment is optional.

## Integrations and triggers

Integrations supply work and context from tools your team already uses. For example, a message or issue can become a task for an agent. [Factory automations](https://docs.warp.dev/factories/automations/) route those events from [connected tools](https://docs.warp.dev/factories/connect-your-factory/) to factory agents, or start recurring work on a schedule. For custom intake, use [webhooks](https://docs.warp.dev/factories/webhooks/) and [factory endpoints](https://docs.warp.dev/factories/factory-api/).

Standalone workflows have separate [integrations](https://docs.warp.dev/platform/integrations/) and [scheduled runs](https://docs.warp.dev/platform/triggers/scheduled-agents/). The [CLI integration setup guide](https://docs.warp.dev/agents/cli/oz-cli/integration-setup/) covers their configuration.

## Inspecting results

Run records let you see what the agent attempted, inspect its transcript and outputs, and decide whether the result needs more work. Inspect factory tasks from the [factory dashboard](https://docs.warp.dev/factories/factory-dashboard/). For standalone management, sharing, and steering, use the [cloud-agent inspection paths](https://docs.warp.dev/platform/#monitor-inspect-and-share-cloud-agent-runs).

## Environments

An environment groups a container image, repositories, and setup commands, such as installing the dependencies an agent needs to run tests. Reusing that setup gives recurring tasks a configured toolchain rather than requiring each task to recreate it.

Factories manage their workspace by default, so selecting an existing environment is optional. See [Environments for factory agents](https://docs.warp.dev/factories/environments/) for that option and standalone setup, and [runners](https://docs.warp.dev/factories/runners/) for compute configuration.

## Hosts

A host is where the agent executes commands and accesses its workspace. Warp-hosted execution uses compute provisioned by Warp. Managed self-hosting uses a worker on your infrastructure, where your team manages capacity and network access.

For factory hosting choices and requirements, compare [Warp-hosted execution](https://docs.warp.dev/factories/warp-hosting/) with [managed self-hosting](https://docs.warp.dev/factories/self-hosting/). [Unmanaged execution](https://docs.warp.dev/platform/unmanaged-execution/) covers standalone CLI workflows in an existing checkout or CI runner you operate.

## The CLI

The CLI lets you work from a terminal or incorporate agents into scripts and CI without requiring the Warp desktop app. Use the [Oz CLI](https://docs.warp.dev/agents/cli/oz-cli/) for existing `oz` workflows and the [Warp Agent CLI](https://docs.warp.dev/agents/cli/) for `warp` commands. Check the owning reference before changing a script.

## API and SDKs

The API and SDKs let an internal service submit work and inspect results programmatically. Use [factory endpoints](https://docs.warp.dev/factories/factory-api/) to send work to a factory, and [agent and run endpoints](https://docs.warp.dev/factories/api-and-sdk/) for standalone runs and run inspection. [Developer tools](https://docs.warp.dev/factories/developer-tools/) links to the SDKs and full API reference.

## Secrets

Secrets give agents credentials for resources such as package registries, APIs, or databases. Grant only the access needed for the task. Use [factory secrets](https://docs.warp.dev/factories/secrets/) for credentials granted to factory agents and [harness authentication](https://docs.warp.dev/factories/harnesses/authentication/) for third-party provider credentials. The [legacy secrets reference](https://docs.warp.dev/platform/secrets/) preserves standalone CLI and personal-secret workflows.

## Shared configuration

Configuration determines which agent runs, which tools it can use, and what setup its work needs. A harness runs the coding agent; MCP servers connect it to external tools and data. Factory-wide and per-agent settings live in the [factory definition](https://docs.warp.dev/factories/factory-as-code/). The shared [harness](https://docs.warp.dev/factories/harnesses/), [environment](https://docs.warp.dev/factories/environments/), and [MCP-server](https://docs.warp.dev/factories/mcp/) references explain factory and standalone configuration separately.

For instructions and reusable context, see [factory skills](https://docs.warp.dev/factories/factory-skills/), [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/). These have different scopes; follow the relevant reference.

## Measuring factory work

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
-   [Cloud agents overview](https://docs.warp.dev/platform/) - Find supported standalone entry points
-   [Architecture](https://docs.warp.dev/platform/architecture/) - Review the run lifecycle and data boundaries
-   [Multi-agent orchestration](https://docs.warp.dev/platform/orchestration/) - Coordinate parent and child agents