How to run unattended agents

Warp cloud agents can run unattended from schedules, team tools, CI, the Oz CLI, or the API. Use them when you want an agent to keep working after you leave your terminal, react to external events, or run recurring maintenance without a human starting each run.

Every unattended workflow creates a cloud agent run that your team can inspect later. Open runs from the Runs page in the Oz web app, the Agent Management Panel in the Warp app, or the session link posted back to the tool that triggered the agent.

Choose a trigger

Use this table to decide where an unattended agent should start.

Trigger	Use it when	Where to configure	Where to inspect
Scheduled agents	Work should run on a predictable cadence, like weekly triage, nightly dependency checks, or monthly cleanup.	Scheduled Agents or the Scheduled Agents quickstart	Oz web app Runs page, Agent Management Panel in the Warp app, schedule history, and cloud agent session links
Slack	A teammate should delegate work from a Slack message or thread.	Slack integration	Slack thread updates, Oz web app Runs page, Agent Management Panel in the Warp app, and the shared run session
Linear	An issue, comment, or assignment should start the agent.	Linear integration	Linear issue updates, Oz web app Runs page, Agent Management Panel in the Warp app, and the shared run session
GitHub Actions	A repository event, PR workflow, issue workflow, or CI failure should start the agent.	GitHub Actions	GitHub Actions logs, PR or issue comments, Oz web app, and cloud agent runs
Oz CLI	You want to start a named cloud run from a terminal, script, or local automation.	Oz CLI	CLI output, Oz web app Runs page, Agent Management Panel in the Warp app, and cloud agent session links
Oz API or SDK	Your internal system should create, query, or monitor runs programmatically.	Oz API and SDK	Your system, API results, Oz web app, and run sessions

Choose a workflow pattern

Run recurring maintenance

Use Scheduled Agents for tasks that should happen on a fixed cadence. Good fits include:

• dependency update checks
• stale issue or PR triage
• repository hygiene
• documentation refreshes
• recurring reports or audits

Each scheduled run starts a fresh cloud agent session and records its own task history, so you can review what ran, when it ran, and what the agent did.

Delegate work from Slack or Linear

Use Slack or Linear when the task starts from team conversation or issue context. These integrations are best for:

• turning a Slack thread into an implementation task
• asking an agent to investigate a Linear issue
• generating a PR from a bug report or product request
• letting teammates monitor progress without opening Warp

The agent posts progress updates back to the source thread or issue and provides a shared run link for deeper inspection.

React to GitHub events

Use GitHub Actions when the trigger should be tied to a repository event.

For example:

• review a PR when it opens
• respond to an @oz-agent comment
• summarize issues on a schedule
• attempt a fix when CI fails
• suggest fixes for review comments

The GitHub Action can pass event data, prior step output, and repository context into the agent prompt. The agent can comment, review, or open branches depending on the workflow permissions you grant.

Start runs from scripts or internal systems

Use the Oz CLI for scripts and terminal workflows. Use the Oz API and SDK when another service should create or monitor runs. This is useful for:

• internal dashboards
• custom webhooks
• CI systems outside GitHub Actions
• recurring jobs managed by your own scheduler
• workflows that need to query run status or results programmatically

Name cloud runs consistently with --name so your team can filter and review related runs later.

Define the run before deploying

Before deploying an unattended agent, define:

• Trigger - What starts the run: schedule, Slack, Linear, GitHub event, CLI command, API request, or another automation.
• Context - Which repository, issue, thread, PR, logs, or files the agent needs.
• Environment - Where the agent runs, including repos, image, setup commands, secrets, and any MCP servers.
• Permissions - What the agent can read or write in GitHub, Slack, Linear, or other systems.
• Output - Whether the agent should comment, open a PR, generate an artifact, post a summary, or only report findings.
• Review path - Where a human will inspect the run, validate results, and approve changes.

If the agent can change code or infrastructure, keep the instructions narrow and make validation explicit.

Review unattended runs

Unattended does not mean invisible. Use these surfaces to review what happened:

• Oz web app - View runs, schedules, run metadata, and session transcripts from a browser or mobile device.
• Managing cloud agents - Filter runs by source, status, day, creator, or trigger.
• Cloud agent session sharing - Inspect the prompt, plan, commands, logs, output, and follow-up messages where available.
• Oz API and SDK - Query runs and build internal monitoring around status, runtime, or outcomes.

When a run creates a PR, include the cloud run link in the PR description or a comment. See Attach agent session context to GitHub PRs for a template.

Start with one reviewable workflow

Start with one narrow workflow before deploying many unattended agents:

1. Pick one trigger and one repository.
2. Use a focused prompt or skill.
3. Run it manually or with Run now before enabling a recurring schedule.
4. Confirm the run has the right environment, secrets, and permissions.
5. Check the output and session transcript.
6. Add a review or approval step before merging code changes.
7. Expand the workflow only after the first runs are predictable.

Next steps

• Scheduled Agents quickstart - Create your first recurring agent in the Oz web app.
• Integrations quickstart - Trigger agents from Slack or Linear.
• GitHub Actions quickstart - Add an agent to a PR review workflow.
• Viewing cloud agent runs - Inspect and share unattended run sessions.