> For the complete documentation index, see [llms.txt](/llms.txt). > Markdown versions of each page are available by appending .md to any URL. # Automation Platform overview How cloud agent runs work on the Automation Platform: triggers start tasks, tasks run in environments on a host, and every run leaves a record. [Cloud agents](/platform/) 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](/platform/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](https://oz.warp.dev) keep the Oz name until September 15, 2026, which is why you’ll still see it in commands and URLs. ![Automation Platform cloud agents overview video](https://i.ytimg.com/vi/poLkJhO7fdo/sddefault.jpg) ## 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. 3. The agent executes on a **host**, optionally inside an [environment](/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](/_astro/most-flexible-platform-for-building-with-agents.DwVtxk0__ZRnchf.webp?dpl=dpl_14fap1oBjzF5jm177Gf5LcaJF1vo) ## Integrations and triggers Every run starts with a trigger. [Integrations](/platform/integrations/) turn events in other tools into runs: mention @warp in [Slack](/platform/integrations/slack/) and the agent gets the message and its thread, or run agents inside your [GitHub Actions](/platform/integrations/github-actions/) workflows with your CI context. [Scheduled agents](/platform/triggers/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](/reference/api-and-sdk/); it becomes a normal, fully tracked task. ## 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](/agents/local-agents/session-sharing/), browse history in the [management UI](/platform/managing-cloud-agents/), or query it from the [Oz CLI](/reference/cli/) and the [API](/reference/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](/platform/orchestration/). ## Environments An [environment](/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](/platform/warp-hosting/), with nothing to set up. On Enterprise plans, [self-hosted runners](/platform/self-hosting/) keep code and execution inside your own network while Warp still tracks the runs. ## The CLI The [Oz CLI](/reference/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](/agents/). ## API and SDKs The [Oz API & SDK](/reference/api-and-sdk/) creates and inspects tasks over HTTP: submit a prompt with optional configuration, poll status, and fetch results with full provenance. Official [Python](https://github.com/warpdotdev/oz-sdk-python) and [TypeScript](https://github.com/warpdotdev/oz-sdk-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, databases, and MCP servers. Store them as [secrets](/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 Runs pick up your team’s shared setup no matter what triggered them: [MCP servers](/platform/mcp/), [rules](/agents/capabilities/rules/), [saved prompts](/knowledge-and-collaboration/warp-drive/prompts/), and [environment variables](/knowledge-and-collaboration/warp-drive/environment-variables/). Configure these once and every trigger uses them. ## Warp Factories [Warp Factories](/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](https://www.warp.dev/factories/request-access) to use it with your team. ## Where to go next - [Cloud agents](/platform/) - what cloud agents are, how they get triggered, and how to run them with or without the Warp app. - [Cloud agents quickstart](/platform/quickstart/) - run your first cloud agent in about ten minutes. - [Environments](/platform/environments/) - define the toolchain and repos a run executes against. - [Oz API & SDK](/reference/api-and-sdk/) - drive the platform programmatically.