Automation Platform overview

Cloud agents run on the Automation Platform. You define the work (a prompt or a skill) and what starts it, and the platform runs the agent and records what it did. For example, an agent can triage each new issue as it’s filed, or start fixing a build the moment CI fails.

If you’re new to cloud agents, the Cloud agents quickstart gets you to your first run in about ten minutes.

Note

Oz is now the Automation Platform. Only the name changed. Your existing integrations, API keys, scheduled agents, and scripts keep working exactly as before — nothing to migrate.

The oz CLI and the Oz web app keep the Oz name until September 15, 2026, which is why you’ll still see it in commands and URLs.

How a run works

Every run follows the same path, whatever starts it:

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 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.

Integrations and triggers

Every run starts with a trigger. Integrations turn events in other tools into runs: mention @warp in Slack and the agent gets the message and its thread, or run agents inside your GitHub Actions workflows with your CI context. Scheduled agents start runs on a cron schedule. For event sources Warp doesn’t cover, receive the event in your own system and start the run through the API; it becomes a normal, fully tracked task.

Set up a first-party integration with oz integration create on the Oz CLI; the integration setup guide covers it end to end.

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, browse history in the management UI, or query it from the Oz CLI and the API. Access control decides who can run, view, or intervene in tasks.

To fan work out across parent and child agents, see multi-agent orchestration.

Environments

An environment 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, 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

The 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.

API and SDKs

The Oz API & SDK creates and inspects tasks over HTTP: submit a prompt with optional configuration, poll status, and fetch results with full provenance. Teams use it to start agents from incident tooling and internal systems, build dashboards over run history, and coordinate large batches of runs. Official Python and TypeScript SDKs add typed requests and responses, built-in retries, and consistent errors. Start with an SDK unless you need full control over your HTTP client.

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

Runs pick up your team’s shared setup no matter what triggered them: MCP servers, rules, saved prompts, and environment variables. Configure these once and every trigger uses them.

Warp Factories

Warp Factories builds on these pieces to run persistent, multi-agent development workflows: specialized cloud agents move each work item through triage, specification, implementation, and review. It’s in Early Access. Request access to use it with your team.

Where to go next

• 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 your first cloud agent in about ten minutes.
• Environments - define the toolchain and repos a run executes against.
• Oz API & SDK - drive the platform programmatically.