Automation Platform overview

Warp Factories and standalone cloud agents run on the Automation Platform. It provides the execution, configuration, and APIs they share.

For a team workflow with planning, implementation, and review, start with the Warp Factories quickstart. To run cloud agents directly from Warp, use the cloud agents quickstart. See transitioning from Oz if you already use the Oz web app, Oz 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. This could be a schedule, an integration event like a Slack mention or a CI failure, an API call, or a manual start.
2. The agent receives the request and its context, such as a Slack thread, PR metadata, or CI logs.
3. The agent executes on a host. If an environment is configured, it defines the image, repositories, and setup commands.
4. The run produces outputs, like a pull request, Slack reply, report, or transcript and summary.


Integrations and triggers

Factory automations route events from connected tools to factory agents. They also start runs on a schedule. For custom intake, use webhooks and factory endpoints.

Standalone cloud-agent workflows also have integrations and scheduled runs. For CLI setup, use oz integration create on the Oz CLI. See the integration setup guide.

Inspecting results

Runs retain their status, transcript, and outputs for later review. For inspection, sharing, and steering, see viewing cloud agent runs. Factory work and standalone work have different inspection paths; the cloud agents overview links to each.

Environments

An environment defines a Docker image with your toolchain, repositories, and setup commands. Use the environment setup reference for standalone runs and factory runners for factory execution.

Hosts

A host is where the agent executes. By default, runs execute on Warp-hosted infrastructure, with nothing to set up. On Enterprise plans, self-hosted runners keep code and execution inside your own network while Warp still tracks the runs.

The CLI

Use the Oz CLI for oz workflows in CI, scripts, and remote servers. The Warp Agent CLI runs the Warp Agent with warp.

API and SDKs

Use the Warp Platform API and SDKs to send work from your own services. Factory endpoints dispatch by factory UID; agent and run endpoints start standalone runs and inspect, continue, or cancel runs.

The official warp-platform-sdk Python package and @warp-dot-dev/warp-platform-sdk TypeScript package provide typed requests, retries, and error handling.

Secrets

Agents often need credentials for APIs, cloud providers, databases, and MCP servers. Store them as 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, MCP servers, and execution defaults in the factory definition. Standalone workflows also use MCP servers, rules, saved prompts, and environment variables; follow each reference for its scope and setup.

Measuring factory work

Use Scorers, Benchmarks, and Self-improvement to evaluate factory work and propose changes to its configuration. See measure and improve for metric definitions and limitations.

Related pages

• Warp Factories quickstart - Create a factory and send its first work item.
• Architecture - reference diagrams of the stack, the run lifecycle, and data boundaries.
• Cloud agents - what cloud agents are, how they get triggered, and how to run them with or without the Warp app.
• Cloud agents quickstart - run a cloud agent from Warp.
• Environments - define the toolchain and repos a run executes against.
• Multi-agent orchestration - divide work among parent and child agents.
• Warp Platform API - drive the platform programmatically.