diff --git a/.agents/references/terminology.md b/.agents/references/terminology.md index 7c329d4d..f33ca41a 100644 --- a/.agents/references/terminology.md +++ b/.agents/references/terminology.md @@ -219,6 +219,34 @@ For the summary of the most critical terms (core features, Oz terms, terms to av - **Warp CLI** — Ambiguous since the Warp Agent CLI launched; avoid the bare term. Use "Oz CLI" for the `oz` binary that runs and manages cloud agents (formerly called `warp-cli`), or "Warp Agent CLI" for the `warp` binary that runs the Warp Agent in any terminal. +- **Automation Platform** — Working name for Warp's cloud agent platform (the proposed successor branding for "Oz" as of the ~2026-08-18 launch), covering environments, integrations, orchestration, self-hosting, and the Agent API/SDK. + *Usage note:* PENDING final naming confirmation — not yet on ZL's locked product-naming list (Warp / Warp Factories / Warp Agent / Warp Terminal). Used in docs IA prototyping via `{VARS.WARP_AUTOMATION_PLATFORM}`; do not hardcode the literal string "Automation Platform" in prose so the name can still change cheaply. + +## Warp Factories terminology + +- **Warp Factories** — Warp's product for deploying and operating cloud software factories: automation loops around the SDLC where cloud agents triage, spec, implement, review, and verify work, with humans in the loop at key decision points. Launches in closed beta ~2026-08-18. + *Usage note:* Capitalize both words as the product name; plural "Factories." Distinct from "software factory" (see below), the generic industry term for the pattern. + +- **software factory** — The generic, lowercase industry term for an automation loop around the SDLC (triage, spec, implement, review, verify). Warp Factories is Warp's product implementation of this pattern. + *Usage note:* Lowercase when used generically ("a software factory," "cloud software factories"). Capitalize only when part of the product name "Warp Factories." + +- **factory** — An individual deployed instance of a software factory, built on Warp Factories infrastructure. + *Usage note:* Lowercase common noun ("your factory," "set up a factory"). + +- **factory definitions as code** — The practice of specifying a factory's repos, agent roles, skills, MCPs, and permissions as version-controlled code, similar to infrastructure-as-code. Enables rollback, canarying, and agentic self-improvement of the factory itself. + +- **work item** — A unit of work moving through a factory (for example an issue, ticket, or triggered task) as it passes through triage, spec, implementation, review, and verification. + +- **foreman agent** — The orchestrator agent that receives a work item's triggering context and dispatches subagents to move it through the factory, choosing model, harness, and context for each step. + +- **Factory MCP** — The MCP server that lets any coding agent or MCP client interact with a factory: push work in, pull status, or guide sessions. + *Usage note:* Capitalize as a feature/proper-noun name. + +- **control room** — The web app view showing all factory agent runs, work item status, automations, and configuration for a given factory. + *Usage note:* Lowercase common noun unless referring to a specific labeled UI element. + +- **AI sovereignty** — Warp Factories' positioning around customer ownership and control of inference, hosting, and data exhaust (agent conversations, evals, memories) for their factory. + ## Technical terms - **AI** — not "A.I." Normalize all instances to "AI." diff --git a/.agents/skills/style_lint/style_lint.py b/.agents/skills/style_lint/style_lint.py index 5ec8b518..b54413b4 100644 --- a/.agents/skills/style_lint/style_lint.py +++ b/.agents/skills/style_lint/style_lint.py @@ -39,7 +39,7 @@ "Codebase Context", "Code Review", "Command Palette", "Global Rules", "Oz CLI", "Oz Platform", "Project Rules", "Slash Commands", "Terminal Mode", "Universal Input", "Warp Drive", - "Warp Platform", + "Warp Platform", "Automation Platform", "Warp Factories", "Factory MCP", } # Terminology: wrong → right (case-sensitive checks) @@ -83,6 +83,9 @@ ("oz.warp.dev", "WEB_APP_URL", "{VARS.WEB_APP_URL} in prose or {{WEB_APP_URL}} in frontmatter"), ("Oz dashboard", "DASHBOARD", "{VARS.DASHBOARD} in prose or {{DASHBOARD}} in frontmatter"), ("Oz run", "PLATFORM_RUN", "{VARS.PLATFORM_RUN} in prose or {{PLATFORM_RUN}} in frontmatter"), + ("Oz API & SDK", "API_SDK_NAME", "{VARS.API_SDK_NAME} in prose or {{API_SDK_NAME}} in frontmatter"), + ("Oz Platform", "WARP_AUTOMATION_PLATFORM", "{VARS.WARP_AUTOMATION_PLATFORM} in prose or {{WARP_AUTOMATION_PLATFORM}} in frontmatter"), + ("Oz", "WARP_AUTOMATION_PLATFORM", "{VARS.WARP_AUTOMATION_PLATFORM} in prose or {{WARP_AUTOMATION_PLATFORM}} in frontmatter"), ] # Oz terms to avoid (case-insensitive patterns) @@ -181,6 +184,11 @@ ) MARKDOWN_LINK = re.compile(r"\[([^\]]*)\]\(([^)]+)\)") VIDEO_EMBED_TITLE = re.compile(r"\btitle\s*=\s*([\"'])(.*?)\1", re.DOTALL) +# JSX expression titles, e.g. title={`${VARS.WEB_APP} walkthrough`} — used when +# the title includes a rename-sensitive {VARS.KEY} reference. Content can't be +# statically evaluated, so these are treated as present but skipped by the +# generic-title check below. +VIDEO_EMBED_TITLE_EXPR = re.compile(r"\btitle\s*=\s*\{(.*?)\}", re.DOTALL) # Common bolded words that are NOT product terms (false positive suppression) COMMON_BOLD_WORDS = { @@ -656,21 +664,29 @@ def check_video_embed_titles(lines: List[str], filepath: str) -> List[Issue]: issues = [] for line_number, tag in _iter_video_embed_tags(lines): title_match = VIDEO_EMBED_TITLE.search(tag) - if not title_match or not title_match.group(2).strip(): - issues.append(Issue( - filepath, line_number, "video-title", - "VideoEmbed missing title prop. Add a specific title that describes the integration, workflow, feature, or task shown.", - "error", - )) + if title_match and title_match.group(2).strip(): + title = title_match.group(2).strip() + if _is_generic_video_title(title): + issues.append(Issue( + filepath, line_number, "video-title", + f"Generic VideoEmbed title: \"{title}\". Use a specific title that describes what the video shows.", + "warning", + )) continue - title = title_match.group(2).strip() - if _is_generic_video_title(title): - issues.append(Issue( - filepath, line_number, "video-title", - f"Generic VideoEmbed title: \"{title}\". Use a specific title that describes what the video shows.", - "warning", - )) + # Not a quoted string literal — check for a JSX expression title, e.g. + # title={`${VARS.WEB_APP} walkthrough`}. Content isn't statically + # evaluable, so skip the generic-title check but still confirm a + # non-empty title prop is present. + expr_match = VIDEO_EMBED_TITLE_EXPR.search(tag) + if expr_match and expr_match.group(1).strip(): + continue + + issues.append(Issue( + filepath, line_number, "video-title", + "VideoEmbed missing title prop. Add a specific title that describes the integration, workflow, feature, or task shown.", + "error", + )) return issues @@ -890,9 +906,23 @@ def check_hardcoded_vars(lines: List[str], filepath: str) -> List[Issue]: Skips fenced code blocks and inline code spans so that CLI examples like `oz.warp.dev` in a code fence are not flagged. + + Literals are checked longest-first and matches are deduplicated by span so + a specific match (e.g. "Oz Platform", "Oz CLI") doesn't also get re-flagged + by the more general bare "Oz" entry for the same occurrence. + + Matches use word boundaries (`\b`) rather than plain substring search, so + short literals like bare "Oz" don't false-positive inside unrelated tokens + such as URL query params, hashes, or other identifiers (e.g. a YouTube + share link's `si=OzvuInMl8DoNR97R` parameter). """ issues = [] in_code_block = False + sorted_strings = sorted(RENAME_SENSITIVE_VAR_STRINGS, key=lambda entry: -len(entry[0])) + compiled = [ + (literal, var_key, suggestion, re.compile(r"\b" + re.escape(literal) + r"\b")) + for literal, var_key, suggestion in sorted_strings + ] for i, line in enumerate(lines, 1): if line.strip().startswith("```"): in_code_block = not in_code_block @@ -901,8 +931,13 @@ def check_hardcoded_vars(lines: List[str], filepath: str) -> List[Issue]: continue # Strip inline code spans so backtick-wrapped references are not flagged prose_line = re.sub(r"`[^`]+`", "", line) - for literal, var_key, suggestion in RENAME_SENSITIVE_VAR_STRINGS: - if literal in prose_line: + matched_spans: List[Tuple[int, int]] = [] + for literal, var_key, suggestion, pattern in compiled: + for m in pattern.finditer(prose_line): + span = m.span() + if any(span[0] >= s and span[1] <= e for s, e in matched_spans): + continue + matched_spans.append(span) issues.append(Issue( filepath, i, "hardcoded-var", f'Hardcoded "{literal}" should use {suggestion} (see src/data/vars.ts)', diff --git a/astro.config.mjs b/astro.config.mjs index 12462c7b..58bc4e23 100644 --- a/astro.config.mjs +++ b/astro.config.mjs @@ -173,7 +173,7 @@ export default defineConfig({ { label: 'Enterprise', description: 'Enterprise features, SSO, team management, and security.', paths: ['enterprise/**'] }, { label: 'Getting Started', description: 'Installation, quickstart, and migration guides.', paths: ['index', 'quickstart', 'getting-started/**'] }, { label: 'Knowledge and Collaboration', description: 'Warp Drive, teams, and the Admin Panel.', paths: ['knowledge-and-collaboration/**'] }, - { label: 'Reference', description: 'CLI and API reference.', paths: ['reference/**'] }, + { label: 'API & Reference', description: 'CLI and API reference.', paths: ['reference/**'] }, // All support-and-community/ pages. open-source-licenses.mdx is excluded // globally above (stack overflow in hast-util-to-text); the patch ensures // it's excluded from this custom set as well. diff --git a/src/components/CustomSidebar.astro b/src/components/CustomSidebar.astro index 6ab218ca..7990cd09 100644 --- a/src/components/CustomSidebar.astro +++ b/src/components/CustomSidebar.astro @@ -69,7 +69,7 @@ import KapaLauncher from './KapaLauncher.astro'; 'getting-started': 'Getting started', 'knowledge-and-collaboration': 'Knowledge & collaboration', 'agents': 'Agents', - 'reference': 'Reference', + 'reference': 'API & Reference', 'changelog': 'Changelog', 'support-and-community': 'Support', 'enterprise': 'Enterprise', diff --git a/src/components/WarpTopicNav.astro b/src/components/WarpTopicNav.astro index d36cf094..be4c83b7 100644 --- a/src/components/WarpTopicNav.astro +++ b/src/components/WarpTopicNav.astro @@ -33,14 +33,12 @@ const { topics } = Astro.locals.starlightSidebarTopics; // Per-topic icon overrides for topics where Starlight's icon registry doesn't // ship the right glyph (only 22 generic UI icons available; no robot/AI). The // `sidebar.ts` config keeps the closest Starlight name (e.g. `puzzle` for -// Agents, `seti:json` for API) so the mobile drawer falls back gracefully; -// this map points to a custom inline SVG that we render here in the header -// instead. +// Agents) so the mobile drawer falls back gracefully; this map points to a +// custom inline SVG that we render here in the header instead. const CUSTOM_TOPIC_ICONS: Record = { Agents: true, - API: true, Enterprise: true, - Oz: true, + 'Automation Platform': true, }; --- @@ -60,22 +58,7 @@ const CUSTOM_TOPIC_ICONS: Record = { this and the Starlight-rendered icons to a single uniform size. `currentColor` so each icon inherits the link's text color and picks up the active-state accent. */} - {topic.label === 'API' ? ( - /* `` brackets — the conventional dev-API glyph. - Two chevrons mirrored across center, stroke weight - matched to the other topic icons. */ - - - - - ) : topic.label === 'Enterprise' ? ( + {topic.label === 'Enterprise' ? ( /* Office building — simple outline: tall rectangle with window grid and entrance, stroke weight matched to the other topic icons. */ @@ -96,7 +79,7 @@ const CUSTOM_TOPIC_ICONS: Record = { - ) : topic.label === 'Oz' ? ( + ) : topic.label === 'Automation Platform' ? ( /* Cloud icon — Feather-style cloud outline, stroke weight matched to the other topic icons. */ - - Agent Memory gives agents in Oz persistent memory across supported harnesses, + Agent Memory gives agents in Warp persistent memory across supported harnesses, including the Warp Agent, Claude Code, and Codex. sidebar: label: "Agent Memory (Research Preview)" --- +import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; :::caution Agent Memory is in **research preview** and is enabled per team for design partners. [Join the waitlist](https://www.warp.dev/oz/agent-memory#waitlist) to request access for your team. ::: -Agent Memory is a persistent memory system that lives on Oz and is shared across every supported agent harness, including the built-in Warp Agent, Claude Code, Codex, and others as they're added. Agents read from and write to this memory system as they run, so durable facts, decisions, and outcomes from one conversation are available to the next — regardless of which harness, machine, or teammate triggers the work. +Agent Memory is a persistent memory system that lives on Warp and is shared across every supported agent harness, including the built-in Warp Agent, Claude Code, Codex, and others as they're added. Agents read from and write to this memory system as they run, so durable facts, decisions, and outcomes from one conversation are available to the next — regardless of which harness, machine, or teammate triggers the work. Memory creation and retrieval are asynchronous and run in the background, so they don't consume tokens or add latency to the active task. @@ -27,7 +28,7 @@ Watch this short preview to see Agent Memory in context. * **Cross-harness memory** - One memory system is shared across the Warp Agent, Claude Code, Codex, and other harnesses as they're added. Third-party harnesses are covered when they run as cloud agents. * **Both local and cloud agents** - Supports interactive local agents in Warp and background cloud agents. * **Asynchronous by design** - Memory creation runs after a conversation ends. Retrieval runs in the background during a run. Neither consumes tokens or adds latency to the active task. -* **Automatic memory creation from conversations** - When a conversation ends, Oz extracts durable facts, learnings, and outcomes and writes them as memories. New knowledge merges with existing memories or supersedes them on conflict. +* **Automatic memory creation from conversations** - When a conversation ends, Warp extracts durable facts, learnings, and outcomes and writes them as memories. New knowledge merges with existing memories or supersedes them on conflict. * **Shareable stores** - Memory is organized into stores. A store can be attached to one or more agents, so the same knowledge is available wherever those agents run. To share knowledge across a team, attach a store to an agent the whole team uses. * **Auto-memory for new agents** - New agents get a dedicated, agent-owned memory store by default, so they start building long-term memory from their first run. You can turn this off when you create the agent. * **Per-agent access and instructions** - Attach stores to specific agents with read-only or read-write access. Per-store instructions tell each agent how and when to use the store. @@ -36,7 +37,7 @@ Watch this short preview to see Agent Memory in context. ## Where Agent Memory runs -Agent Memory is part of Oz. Storage, memory creation, and retrieval all run on Oz alongside your agents. The same memory is accessible from any agent you run on Oz: +Agent Memory is part of Warp. Storage, memory creation, and retrieval all run on Warp alongside your agents. The same memory is accessible from any agent you run in Warp: * The local Warp Agent. * Cloud agents triggered from the CLI, web app, schedules, or integrations. @@ -58,7 +59,7 @@ Teams can use multiple stores to keep contexts separate, and attach the same sto ### Auto-memory for new agents -When you create an agent in the Oz web app, **Auto-memory** is on by default. With it enabled, Oz creates a dedicated memory store owned by that agent and uses it as the agent's default long-term memory: the agent reads relevant memories before it acts and writes durable facts, decisions, and preferences for future runs. Each agent has a single auto-memory store. +When you create an agent in the {VARS.WEB_APP}, **Auto-memory** is on by default. With it enabled, Warp creates a dedicated memory store owned by that agent and uses it as the agent's default long-term memory: the agent reads relevant memories before it acts and writes durable facts, decisions, and preferences for future runs. Each agent has a single auto-memory store. Auto-memory is different from automatic memory creation from conversations, described below: auto-memory is the store an agent gets by default, while automatic memory creation from conversations is how memories are written to a store after a conversation ends. @@ -66,15 +67,15 @@ You can turn Auto-memory off when you create the agent, and you can attach exist ## Automatic memory creation from conversations -When a conversation finishes, Oz extracts durable facts, learnings, and outcomes from the transcript and writes them as memories. Memory creation runs in the background after the conversation ends, so it doesn't consume tokens or add latency during that run. +When a conversation finishes, Warp extracts durable facts, learnings, and outcomes from the transcript and writes them as memories. Memory creation runs in the background after the conversation ends, so it doesn't consume tokens or add latency during that run. * **Memories evolve over time** - Agents update and supersede their own memories as new information arrives, including to resolve contradictions with prior memories. -You can also explicitly ask an agent to remember something during a conversation. Oz saves that memory to the appropriate store. +You can also explicitly ask an agent to remember something during a conversation. Warp saves that memory to the appropriate store. ## How agents use memory -When an agent starts a task, Oz searches the stores the agent can access for relevant memories and injects them as context. The search runs in the background, so the agent only sees the memories returned. Agents can also retrieve additional memories on demand mid-conversation when they determine it's relevant, similar to how they consult [Rules](/agents/capabilities/rules/) or [Codebase Context](/agents/capabilities/codebase-context/). You don't need to write retrieval queries or pre-load memory. +When an agent starts a task, Warp searches the stores the agent can access for relevant memories and injects them as context. The search runs in the background, so the agent only sees the memories returned. Agents can also retrieve additional memories on demand mid-conversation when they determine it's relevant, similar to how they consult [Rules](/agents/capabilities/rules/) or [Codebase Context](/agents/capabilities/codebase-context/). You don't need to write retrieval queries or pre-load memory. ## Attaching memory to your agents @@ -84,8 +85,8 @@ Attach stores to agents with read-only or read-write access. Each attachment inc These capabilities aren't part of the research preview yet, but they're on the way: -* **Programmatic API access** - Read and manage memories and stores through the [Oz API](/reference/api-and-sdk/), in addition to managing them in the Oz web app. -* **Self-hosting support** - Run Agent Memory on a [self-hosted Oz](/platform/self-hosting/) instance to meet security, privacy, and compliance requirements. +* **Programmatic API access** - Read and manage memories and stores through the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/), in addition to managing them in the {VARS.WEB_APP}. +* **Self-hosting support** - Run Agent Memory on a [self-hosted {VARS.WARP_AUTOMATION_PLATFORM}](/platform/self-hosting/) instance to meet security, privacy, and compliance requirements. ## Join the waitlist diff --git a/src/content/docs/agents/capabilities/agent-notifications.mdx b/src/content/docs/agents/capabilities/agent-notifications.mdx index e1de8a8f..41554ece 100644 --- a/src/content/docs/agents/capabilities/agent-notifications.mdx +++ b/src/content/docs/agents/capabilities/agent-notifications.mdx @@ -4,6 +4,7 @@ description: >- Warp surfaces notifications from coding agents, both in-app and via desktop alerts, so you know exactly when an agent needs your attention. --- +import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; Warp delivers notifications from any supported coding agent so you always know when an agent finishes a task, encounters an error, or needs your input. Notifications work whether you're in a different tab or a different app. @@ -106,7 +107,7 @@ In a [multi-agent orchestration](/platform/orchestration/), the parent agent and That means: * **Toasts and the mailbox** - watch the parent's conversation for `Complete`, `Request`, and `Error` notifications. -* **Per-child state** - use the orchestration pill bar above the agent view header (in the Warp app) or the parent's **Sub-agents** tab on the [Runs page](https://oz.warp.dev/runs) (in the Oz web app) to see each child's live status. Both surfaces update as children transition through `INPROGRESS`, `SUCCEEDED`, `BLOCKED`, `FAILED`, `ERROR`, and `CANCELLED`. +* **Per-child state** - use the orchestration pill bar above the agent view header (in the Warp app) or the parent's **Sub-agents** tab on the Runs page (in the {VARS.WEB_APP}) to see each child's live status. Both surfaces update as children transition through `INPROGRESS`, `SUCCEEDED`, `BLOCKED`, `FAILED`, `ERROR`, and `CANCELLED`. * **Blocked children** - if a child blocks on user input (for example, a command approval request), open that child from the pill bar to resolve the block. The parent's transcript also reflects the child's `BLOCKED` state so the parent can wait, send a follow-up, or cancel the child. ## Related pages diff --git a/src/content/docs/agents/capabilities/computer-use/index.mdx b/src/content/docs/agents/capabilities/computer-use/index.mdx index 11ebbcbe..3543f8a4 100644 --- a/src/content/docs/agents/capabilities/computer-use/index.mdx +++ b/src/content/docs/agents/capabilities/computer-use/index.mdx @@ -13,7 +13,7 @@ Computer Use enables agents to interact with desktop environments. The agent can A key use case is **testing UI changes** with a self-contained feedback loop, where the agent can verify that your code changes produce the expected visual and behavioral results without requiring manual testing. -## Overview +## Capabilities With Computer Use, agents can: @@ -42,7 +42,7 @@ Computer Use is **enabled by default** for cloud agent runs on Warp's built-in h Runs started from the Warp app don't use the server default: they always follow the app's **Computer use in Cloud Agents** setting ([`cloud_agent_computer_use_enabled`](/terminal/settings/all-settings/)), which is off by default. To control Computer Use for [Cloud Agents](/platform/) started from the Warp app, navigate to **Settings** > **Agents** > **Warp Agent** > **Experimental** > **Computer use in Cloud Agents**. -### Oz CLI +### CLI When running cloud agents with the [{VARS.WARP_AGENT_CLI}](/reference/cli/), use flags to control Computer Use per run: @@ -51,9 +51,9 @@ oz agent run-cloud --computer-use --prompt "" oz agent run-cloud --no-computer-use --prompt "" ``` -### Oz API +### API -When creating a cloud agent run with the [Oz API](/reference/api-and-sdk/), the optional `config.computer_use_enabled` field controls Computer Use. When omitted, it defaults to `true` for runs on Warp's built-in harness and `false` for runs on third-party harnesses. Set it to `false` to disable Computer Use for the run: +When creating a cloud agent run with the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/), the optional `config.computer_use_enabled` field controls Computer Use. When omitted, it defaults to `true` for runs on Warp's built-in harness and `false` for runs on third-party harnesses. Set it to `false` to disable Computer Use for the run: ```json { @@ -65,9 +65,9 @@ When creating a cloud agent run with the [Oz API](/reference/api-and-sdk/), the } ``` -For full API documentation, see the [Oz API & SDK](/reference/api-and-sdk/) reference. +For full API documentation, see the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) reference. -### Oz web app +### Web app In the {VARS.WEB_APP}, you can enable or disable Computer Use for: diff --git a/src/content/docs/agents/capabilities/computer-use/testing-and-recordings.mdx b/src/content/docs/agents/capabilities/computer-use/testing-and-recordings.mdx index 419c80bf..6155e2b4 100644 --- a/src/content/docs/agents/capabilities/computer-use/testing-and-recordings.mdx +++ b/src/content/docs/agents/capabilities/computer-use/testing-and-recordings.mdx @@ -31,7 +31,7 @@ You don't need to ask the agent to record explicitly. Prompts like "test this ch ## How it works -1. **Confirm Computer Use is enabled.** Computer Use is enabled by default for cloud agent runs on Warp's built-in harness, so no setup is needed unless it was turned off for your run. See the [Computer Use](/agents/capabilities/computer-use/#enabling-computer-use) page for how to control it via the Warp app, the {VARS.WARP_AGENT_CLI}, or the Oz API. +1. **Confirm Computer Use is enabled.** Computer Use is enabled by default for cloud agent runs on Warp's built-in harness, so no setup is needed unless it was turned off for your run. See the [Computer Use](/agents/capabilities/computer-use/#enabling-computer-use) page for how to control it via the Warp app, the {VARS.WARP_AGENT_CLI}, or the {VARS.WARP_AUTOMATION_PLATFORM} API. 2. **Agent starts recording.** Once Computer Use is active, the agent begins a screen capture inside the sandbox. The recording is gated by your session's Computer Use approval. If you've already approved Computer Use for the run, recording starts automatically without a separate prompt. 3. **Agent exercises the UI.** The agent takes screenshots, clicks, types, scrolls, and drives the interface. Each successful interaction is tracked: when it started, when it finished, what actions it contained, and where the cursor moved. 4. **Agent stops and processes.** When the task is complete (or when the recording's configured time or size limit is reached), the agent stops capture. Before upload, the recording is post-processed: idle and thinking gaps are cut, leaving only the windows where real interaction happened, and action overlays are burned in so the video is annotated. @@ -43,7 +43,7 @@ You don't need to ask the agent to record explicitly. Prompts like "test this ch After the agent finishes its Computer Use session, any video recording appears as a block in the conversation. Clicking the block opens the full conversation view alongside the recording artifact. If the recording was produced by a cloud agent run, you can also access it by opening that run's transcript as a [cloud-synced conversation](/platform/viewing-cloud-agent-runs/). -### In the Oz web app +### In the web app Cloud agent runs are listed on the [Runs page of the {VARS.WEB_APP}](/platform/oz-web-app/#runs). Open a run to see its artifacts section, which lists any video recordings produced during that run. You can play the video directly from the run page or download it. @@ -81,7 +81,7 @@ The finished recording is attached to the pull request, giving a reviewer proof ### End-to-end QA of an existing flow -An agent walks through a critical user journey, such as the "New run" creation flow in the Oz web app, capturing the complete interaction. +An agent walks through a critical user journey, such as the "New run" creation flow in the {VARS.WEB_APP}, capturing the complete interaction. Example prompt: ```text @@ -90,7 +90,7 @@ Build the Oz web app and walk through the entire "New run" creation flow end to This gives you a reproducible, time-stamped clip of the flow that can be archived, diffed across releases, or shared with the team as a baseline. - + ### Reproducing a bug diff --git a/src/content/docs/agents/capabilities/full-terminal-use.mdx b/src/content/docs/agents/capabilities/full-terminal-use.mdx index 141c3f1a..6a46f6de 100644 --- a/src/content/docs/agents/capabilities/full-terminal-use.mdx +++ b/src/content/docs/agents/capabilities/full-terminal-use.mdx @@ -5,6 +5,7 @@ description: >- to monitor live output and run commands. --- import { Tabs, TabItem } from '@astrojs/starlight/components'; +import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; Full Terminal Use lets the Warp Agent operate directly inside interactive terminal applications like database shells, debuggers, text editors, and long-running servers. The agent can see the live terminal buffer, write commands, respond to prompts, and hand control back to you at any time. @@ -191,7 +192,7 @@ These settings apply to every session that uses Full Terminal Use. You can still All AI interactions from Full Terminal Use consume [credits](/support-and-community/plans-and-billing/credits/), including understanding your natural language requests. -Credits are consumed in a similar way as other Oz actions that use the same model and a similar context size. +Credits are consumed in a similar way as other Warp actions that use the same model and a similar context size. **Interactive sessions can consume more credits if:** diff --git a/src/content/docs/agents/capabilities/skills.mdx b/src/content/docs/agents/capabilities/skills.mdx index 6c30edcd..60b48b69 100644 --- a/src/content/docs/agents/capabilities/skills.mdx +++ b/src/content/docs/agents/capabilities/skills.mdx @@ -6,6 +6,7 @@ description: >- Create reusable instruction sets that teach agents specific tasks and share expertise across your team. --- +import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; import { FileTree } from '@astrojs/starlight/components'; @@ -409,7 +410,7 @@ This opens an interactive menu where you can: Warp maintains a public collection of ready-to-use skills in the [warpdotdev/oz-skills](https://github.com/warpdotdev/oz-skills) repository. You can browse these skills for inspiration, copy them directly into your project's `.agents/skills/` directory, or adapt them to fit your team's workflows. -These same skills also appear as suggested agents in the [Oz web app](/platform/oz-web-app/), where you can run them directly in the cloud. +These same skills also appear as suggested agents in the [{VARS.WEB_APP}](/platform/oz-web-app/), where you can run them directly in the cloud. ## Suggested skills from Agent Memory @@ -430,7 +431,7 @@ This is useful when you want to reuse a skill's workflow but tailor the executio Skills can be used with both local and [cloud agents](/platform/) to create reusable, automated workflows. When running an agent via the CLI, web app, or API, you can specify a skill to provide the base instructions for the agent. -For a complete guide to running skill-based agents—including CLI usage, the Oz web app, scheduling, skill discovery, and API integration—see [Skills as Agents](/platform/skills-as-agents/). +For a complete guide to running skill-based agents—including CLI usage, the {VARS.WEB_APP}, scheduling, skill discovery, and API integration—see [Skills as Agents](/platform/skills-as-agents/). ## Related features diff --git a/src/content/docs/agents/cli-agents/claude-code.mdx b/src/content/docs/agents/cli-agents/claude-code.mdx index 935b34d9..901d66a5 100644 --- a/src/content/docs/agents/cli-agents/claude-code.mdx +++ b/src/content/docs/agents/cli-agents/claude-code.mdx @@ -6,6 +6,7 @@ description: >- Set up Claude Code in Warp with full notification support, rich input, code review, and more. --- +import { VARS } from '@data/vars'; Claude Code is Anthropic's agentic coding tool that operates directly in your terminal. It understands your codebase, executes commands, edits files, and manages Git workflows — all through natural language. For full documentation, see the [official Claude Code docs](https://code.claude.com/docs). @@ -14,7 +15,7 @@ Warp auto-detects Claude Code when you run it, giving you access to rich input c For installation, authentication, project configuration, and productivity tips, see the [How to set up Claude Code](/guides/external-tools/how-to-set-up-claude-code/) guide. :::note -Claude Code is also available as a harness in Oz for cloud orchestration. See [Claude Code with Oz](/platform/harnesses/claude-code/). +Claude Code is also available as a harness in {VARS.WARP_AUTOMATION_PLATFORM} for cloud orchestration. See [Claude Code with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/claude-code/). ::: ## Setting up notifications @@ -75,6 +76,6 @@ Claude Code supports Warp's full set of agent integration features: * [Claude Code in Warp](https://www.warp.dev/agents/claude-code) — product overview * [Third-party CLI agents overview](/agents/cli-agents/overview/) — supported CLI agent integrations * [Remote Control](/agents/cli-agents/remote-control/) — publish a Claude Code session to monitor and steer it remotely -* [Claude Code with Oz](/platform/harnesses/claude-code/) — Claude Code as a cloud harness +* [Claude Code with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/claude-code/) — Claude Code as a cloud harness * [OpenCode](/agents/cli-agents/opencode/) — OpenCode in Warp * [Codex](/agents/cli-agents/codex/) — Codex in Warp diff --git a/src/content/docs/agents/cli-agents/codex.mdx b/src/content/docs/agents/cli-agents/codex.mdx index 7e45948b..5af08896 100644 --- a/src/content/docs/agents/cli-agents/codex.mdx +++ b/src/content/docs/agents/cli-agents/codex.mdx @@ -6,6 +6,7 @@ description: >- Set up Codex in Warp with notification support, rich input, code review, and more. --- +import { VARS } from '@data/vars'; Codex is OpenAI's open-source coding agent that runs in your terminal. It can write and edit code, execute commands, and navigate your codebase through natural language. For full documentation, see the [Codex GitHub repository](https://github.com/openai/codex). @@ -14,7 +15,7 @@ Warp auto-detects Codex when you run it, giving you access to rich input control For installation, authentication, project configuration, and productivity tips, see the [How to set up Codex CLI](/guides/external-tools/how-to-set-up-codex-cli/) guide. :::note -Codex is also available as a harness in Oz for cloud orchestration. See [Codex with Oz](/platform/harnesses/codex/). +Codex is also available as a harness in {VARS.WARP_AUTOMATION_PLATFORM} for cloud orchestration. See [Codex with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/codex/). ::: ## Setting up notifications @@ -58,6 +59,6 @@ Codex supports Warp's full set of agent integration features: * [How to set up Codex CLI](/guides/external-tools/how-to-set-up-codex-cli/) — step-by-step setup guide * [Codex in Warp](https://www.warp.dev/agents/codex) — product overview * [Third-party CLI agents overview](/agents/cli-agents/overview/) — supported CLI agent integrations -* [Codex with Oz](/platform/harnesses/codex/) — Codex as a cloud harness +* [Codex with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/codex/) — Codex as a cloud harness * [Claude Code](/agents/cli-agents/claude-code/) — Claude Code in Warp * [OpenCode](/agents/cli-agents/opencode/) — OpenCode in Warp diff --git a/src/content/docs/agents/cli-agents/overview.mdx b/src/content/docs/agents/cli-agents/overview.mdx index 7bd8ce5e..2f855d75 100644 --- a/src/content/docs/agents/cli-agents/overview.mdx +++ b/src/content/docs/agents/cli-agents/overview.mdx @@ -15,7 +15,7 @@ This feature set is also known as **universal agent support**. Looking for Warp's own CLI instead? The [Warp Agent CLI](/agents/cli/) runs the Warp Agent itself in any terminal. This page covers running third-party coding agents inside the Warp app. :::note -Claude Code and Codex are also supported as harnesses in Oz for [multi-agent orchestration](/platform/orchestration/). See [Harnesses in Oz](/platform/harnesses/). +Claude Code and Codex are also supported as harnesses in {VARS.WARP_AUTOMATION_PLATFORM} for [multi-agent orchestration](/platform/orchestration/). See [Harnesses in {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/). ::: ## Supported agents diff --git a/src/content/docs/agents/cli/cloud-and-orchestration.mdx b/src/content/docs/agents/cli/cloud-and-orchestration.mdx index 4bc5c14e..9812d69d 100644 --- a/src/content/docs/agents/cli/cloud-and-orchestration.mdx +++ b/src/content/docs/agents/cli/cloud-and-orchestration.mdx @@ -6,7 +6,7 @@ description: >- --- import { VARS } from '@data/vars'; -The {VARS.WARP_CLI} connects your terminal sessions to Oz. You can hand off a local conversation to a cloud agent, pick a finished cloud run back up in your terminal, and coordinate multiple agents working in parallel, all without leaving the CLI. +The {VARS.WARP_CLI} connects your terminal sessions to {VARS.WARP_AUTOMATION_PLATFORM}. You can hand off a local conversation to a cloud agent, pick a finished cloud run back up in your terminal, and coordinate multiple agents working in parallel, all without leaving the CLI. ## Hand off to a cloud agent diff --git a/src/content/docs/agents/cli/index.mdx b/src/content/docs/agents/cli/index.mdx index 3cb8bfaf..5d29bcb1 100644 --- a/src/content/docs/agents/cli/index.mdx +++ b/src/content/docs/agents/cli/index.mdx @@ -27,7 +27,7 @@ To get a working setup in a few minutes, follow the [quickstart](/agents/cli/qui * **[Model choice](/agents/cli/models-and-usage/)** - Pick a model per conversation, bring your own provider API keys, and track credit usage. * **[Customization](/agents/cli/configuration/)** - Configure themes, the statusline, and the start screen through a local settings file. -## How it relates to the Warp app and Oz +## How it relates to the Warp app and cloud agents * **The Warp app** - The CLI runs the same [Warp Agent](/platform/harnesses/warp-agent/) harness as the Warp app, so your account, plan, model access, rules, and skills work the same in both. The CLI doesn't require the Warp app to be installed. * **{VARS.WARP_AUTOMATION_PLATFORM}** - {VARS.WARP_AUTOMATION_PLATFORM} is Warp's programmable platform for running and coordinating agents at scale. The CLI connects to the same platform. Conversations sync to your Warp account, and you can hand work off to [cloud agents](/agents/cli/cloud-and-orchestration/) or continue a cloud run from your terminal. diff --git a/src/content/docs/agents/cli/reference.mdx b/src/content/docs/agents/cli/reference.mdx index fc8088c7..659ae26e 100644 --- a/src/content/docs/agents/cli/reference.mdx +++ b/src/content/docs/agents/cli/reference.mdx @@ -32,7 +32,7 @@ warp --api-key YOUR_API_KEY Command-line arguments can be captured in shell history and process listings. Prefer the `WARP_API_KEY` environment variable, ideally populated from a secret manager. ::: -Create a key in the Warp app under **Settings** > **Cloud platform** > **Oz Cloud API Keys**. See the [API keys reference](/reference/cli/api-keys/) for details. +Create a key in the Warp app under **Settings** > **Cloud platform** > **{VARS.WARP_AUTOMATION_PLATFORM} Cloud API Keys**. See the [API keys reference](/reference/cli/api-keys/) for details. ### `--auto-approve` diff --git a/src/content/docs/agents/getting-started/agents-in-warp.mdx b/src/content/docs/agents/getting-started/agents-in-warp.mdx index 159ffb45..da855768 100644 --- a/src/content/docs/agents/getting-started/agents-in-warp.mdx +++ b/src/content/docs/agents/getting-started/agents-in-warp.mdx @@ -4,9 +4,10 @@ description: >- Work with the Warp Agent in the Warp app. Control its autonomy with profiles and permissions, and give it context from your codebase and tools. --- +import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; -This page covers the Warp Agent in the Warp app. You can run the same agent from any terminal with the [Warp Agent CLI](/agents/cli/), or in the background as a [cloud agent](/platform/) on [Oz](/platform/overview/). Warp also supports [third-party CLI agents](/agents/cli-agents/overview/) like Claude Code and Codex. +This page covers the Warp Agent in the Warp app. You can run the same agent from any terminal with the [Warp Agent CLI](/agents/cli/), or in the background as a [cloud agent](/platform/) on [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/). Warp also supports [third-party CLI agents](/agents/cli-agents/overview/) like Claude Code and Codex. diff --git a/src/content/docs/agents/index.mdx b/src/content/docs/agents/index.mdx index b70aa42d..3c6f5964 100644 --- a/src/content/docs/agents/index.mdx +++ b/src/content/docs/agents/index.mdx @@ -4,10 +4,11 @@ description: >- The Warp Agent writes code, debugs issues, and runs commands. Use it in the Warp app, in any terminal with the CLI, or in the cloud. --- +import { VARS } from '@data/vars'; The **Warp Agent** is Warp's built-in coding agent. It reads your codebase, follows your rules and skills, and asks for approval before it acts, and you can run it in the Warp app, in any terminal, or in the cloud. -This page covers where to run the agent, the third-party CLI agents Warp supports, and [Oz](/platform/overview/), the platform that runs and coordinates agents at scale. +This page covers where to run the agent, the third-party CLI agents Warp supports, and [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/), which runs and coordinates agents at scale. --- @@ -33,9 +34,9 @@ Separately from the Warp Agent, Warp gives third-party CLI coding agents first-c ## The platform behind the agent -[**Oz**](/platform/overview/) is Warp's programmable platform for running and coordinating agents at scale. It provides the environments, triggers, integrations, orchestration, and observability that cloud agents run on, along with a CLI, API, and SDK for driving agents programmatically. +[**{VARS.WARP_AUTOMATION_PLATFORM}**](/platform/overview/) is Warp's programmable system for running and coordinating agents at scale. It provides the environments, triggers, integrations, orchestration, and observability that cloud agents run on, along with a CLI, API, and SDK for driving agents programmatically. -The Oz tab covers the platform in full. +The {VARS.WARP_AUTOMATION_PLATFORM} tab covers it in full. --- diff --git a/src/content/docs/agents/inference/model-choice.mdx b/src/content/docs/agents/inference/model-choice.mdx index 11f198d4..27dd9aac 100644 --- a/src/content/docs/agents/inference/model-choice.mdx +++ b/src/content/docs/agents/inference/model-choice.mdx @@ -6,6 +6,7 @@ description: >- Choose from a curated set of top LLMs for Warp's Agents (or let Warp auto-select the best model). --- +import { VARS } from '@data/vars'; Warp lets you choose from a curated set of large language models to power your agents, or let Warp auto-select the best model for each task. Models from OpenAI, Anthropic, Google, and open source providers are available, with configurable reasoning levels and per-profile defaults. You can also define [custom routers](/agents/inference/custom-routers/) that pick a model for each task using your own logic. @@ -15,7 +16,7 @@ Warp lets you choose from a curated set of large language models (LLMs) to power **Warp supports the following models.** -The `model_id` values shown below can be used when configuring models via the [Oz Platform](/platform/overview/) or [CLI](/reference/cli/). +The `model_id` values shown below can be used when configuring models via the [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) or [CLI](/reference/cli/). ### Auto models diff --git a/src/content/docs/agents/local-agents/interacting-with-agents/index.mdx b/src/content/docs/agents/local-agents/interacting-with-agents/index.mdx index 2095b83f..5a56d400 100644 --- a/src/content/docs/agents/local-agents/interacting-with-agents/index.mdx +++ b/src/content/docs/agents/local-agents/interacting-with-agents/index.mdx @@ -5,6 +5,7 @@ description: >- and multi-thread support. --- import { Tabs, TabItem } from '@astrojs/starlight/components'; +import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; Agent conversations in Warp are multi-turn interactions tied to terminal sessions. Continue previous threads with follow-ups, manage conversation history, attach context from blocks and files, and run multiple conversations simultaneously across windows, tabs, or panes. @@ -197,7 +198,7 @@ The **Active** dropdown lists conversations where you have sent at least one que * Select a conversation to switch to it immediately. * The conversation you're currently viewing is highlighted. -* Cloud agent conversations and Oz runs always appear in **Active** while they are open. +* Cloud agent conversations and {VARS.PLATFORM_RUN}s always appear in **Active** while they are open. #### Past diff --git a/src/content/docs/agents/local-agents/interacting-with-agents/terminal-and-agent-modes.mdx b/src/content/docs/agents/local-agents/interacting-with-agents/terminal-and-agent-modes.mdx index b6d97513..10a1b164 100644 --- a/src/content/docs/agents/local-agents/interacting-with-agents/terminal-and-agent-modes.mdx +++ b/src/content/docs/agents/local-agents/interacting-with-agents/terminal-and-agent-modes.mdx @@ -4,6 +4,7 @@ description: >- Warp provides two distinct modes: a clean terminal for commands, and a dedicated conversation view for multi-turn agent workflows. --- +import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; Warp provides two distinct modes: a clean terminal for running shell commands, and a dedicated conversation view for multi-turn interactions with the Warp Agent. Terminal mode keeps the interface minimal by default, while Agent Mode surfaces full controls for model selection, voice input, image attachments, and conversation management. @@ -17,7 +18,7 @@ Warp provides two distinct modes: a clean terminal for running shell commands, a Before diving in, here are two key concepts: * **Terminal session** - Your shell environment where you run commands. This is the default mode when you open Warp—a clean, traditional terminal input. -* **Agent conversation** - A multi-turn interaction with Oz. Conversations maintain context across exchanges and have their own dedicated view with richer controls. +* **Agent conversation** - A multi-turn interaction with {VARS.WARP_AUTOMATION_PLATFORM}. Conversations maintain context across exchanges and have their own dedicated view with richer controls. Terminal and Agent modes make switching between these two contexts seamless while keeping them visually distinct. @@ -132,7 +133,7 @@ Cloud agent conversations are always stored in the cloud. For more details on ac * **From the conversation list panel** - Cloud conversations appear alongside local conversations. Click to open. * **From the management view** - Use the [Agent Management view](/platform/managing-cloud-agents/) to see all cloud agent runs, filter by status, and click any row to open the conversation. -* **From the Oz web app** - Access your cloud agents from the [Oz web app](https://oz.warp.dev) to manage runs from any browser. +* **From the {VARS.WEB_APP}** - Access your cloud agents from the {VARS.WEB_APP} to manage runs from any browser. For more on cloud agents, see [Cloud Agents overview](/platform/). diff --git a/src/content/docs/agents/local-agents/session-sharing.mdx b/src/content/docs/agents/local-agents/session-sharing.mdx index 6a1f4216..61932f89 100644 --- a/src/content/docs/agents/local-agents/session-sharing.mdx +++ b/src/content/docs/agents/local-agents/session-sharing.mdx @@ -4,9 +4,10 @@ description: >- Share live agent sessions so collaborators can view, steer, and interact with agent activity from any device — in real time or asynchronously. --- +import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; -**Agent Session Sharing** extends Warp's regular [Session Sharing](/knowledge-and-collaboration/session-sharing/) to include full visibility and control over Agent activity. Share any agent session — Oz or third-party — so collaborators can watch progress, review output, and steer the agent from the Warp app, a web browser, or a mobile device. +**Agent Session Sharing** extends Warp's regular [Session Sharing](/knowledge-and-collaboration/session-sharing/) to include full visibility and control over Agent activity. Share any agent session — {VARS.WARP_AUTOMATION_PLATFORM} or third-party — so collaborators can watch progress, review output, and steer the agent from the Warp app, a web browser, or a mobile device. Use Agent Session Sharing when teammates need the execution context behind an agent's work, not just the final answer or code diff. A shared agent session can show the prompt, responses, thinking states, tool use, planning steps, terminal output, and follow-up messages in one reviewable link. diff --git a/src/content/docs/changelog/2025.mdx b/src/content/docs/changelog/2025.mdx index 64e82706..b96e1c3f 100644 --- a/src/content/docs/changelog/2025.mdx +++ b/src/content/docs/changelog/2025.mdx @@ -3,6 +3,7 @@ title: "Changelog — 2025" description: >- Warp release notes for 2025. Updates ship weekly, typically on Thursdays. --- +import { VARS } from '@data/vars'; Submit bugs and feature requests on our [GitHub board!](https://github.com/warpdotdev/Warp/issues/new/choose) @@ -18,7 +19,7 @@ Submit bugs and feature requests on our [GitHub board!](https://github.com/warpd **Bug fixes** -* Fixed a bug where Oz CLI runs could get stuck trying to run a denylisted command. +* Fixed a bug where {VARS.WARP_AGENT_CLI} runs could get stuck trying to run a denylisted command. ### 2025.12.10 (v0.2025.12.10.08.12) @@ -42,7 +43,7 @@ Submit bugs and feature requests on our [GitHub board!](https://github.com/warpd **Improvements** -* The Oz CLI now displays more detailed information when the agent tries to take a prohibited action. +* The {VARS.WARP_AGENT_CLI} now displays more detailed information when the agent tries to take a prohibited action. * Allow dragging file paths from the Project Explorer into active terminal commands like claude code and gemini for referencing files and folders. **Bug fixes** @@ -50,7 +51,7 @@ Submit bugs and feature requests on our [GitHub board!](https://github.com/warpd * Fixed a bug that could cause unbounded memory growth when using Warpified subshells or the legacy (non-tmux) SSH Warpify implementation. * Fixed a bug that could cause `comm` errors to appear in Warpified subshells. * \[Windows] Fixed keybinding for "find in code editor." This is now `CTRL-SHIFT-F` and configurable from Settings > Keyboard shortcuts. -* Ensured that the Oz CLI is available automatically on macOS. +* Ensured that the {VARS.WARP_AGENT_CLI} is available automatically on macOS. * Fixed toast messages showing "Notebook" instead of "Plan" when taking actions on Plans in Warp Drive. ### 2025.11.19 (v0.2025.11.19.08.12) @@ -100,7 +101,7 @@ Submit bugs and feature requests on our [GitHub board!](https://github.com/warpd **Improvements** * Display conversation summaries when summarization is triggered. -* Added completions for the Oz CLI. +* Added completions for the {VARS.WARP_AGENT_CLI}. * Updated community links from Discord to Slack throughout the app. **Bug Fixes** @@ -136,7 +137,7 @@ Submit bugs and feature requests on our [GitHub board!](https://github.com/warpd * Added confirmation dialog when cancelling AI summarization requests. * You can now expand Suggested Code Diffs further on down arrow. * Restore closed panes using `CMD-SHIFT-T` or `CTRL-ALT-T` on Windows / Linux within 60 seconds of them being closed. -* Added shell completions for the Oz CLI. +* Added shell completions for the {VARS.WARP_AGENT_CLI}. * Warp Drive Environment Variables are now supported for Warp for Windows (PowerShell, Git Bash, and WSL). * Enriched the model picker to include detailed specs of each model's intelligence, speed and cost. diff --git a/src/content/docs/changelog/2026.mdx b/src/content/docs/changelog/2026.mdx index f867c376..3e57fc5a 100644 --- a/src/content/docs/changelog/2026.mdx +++ b/src/content/docs/changelog/2026.mdx @@ -1368,7 +1368,7 @@ Oz is Warp's orchestration platform for cloud agents: launch parallel agents, au * **Run Cloud Agents from anywhere with built-in tracking** — start agents from Warp or via the CLI, triggers, or schedules. Every run is auditable and steerable. [Cloud Agents docs →](https://docs.warp.dev/platform/) * **Cloud environments for consistent execution** — configure Docker-based environments (unlimited repos + setup commands) and run agents in isolated cloud sandboxes. [Environments docs →](https://docs.warp.dev/platform/environments) -* **Track agents from the web** — manage runs, create schedules, configure environments, and set up integrations from any browser in the [Oz web app](https://oz.warp.dev). +* **Track agents from the web** — manage runs, create schedules, configure environments, and set up integrations from any browser in the Oz web app. * **Schedule agents based on Skills** — run agents automatically on a cron schedule for code cleanup, dependency updates, and issue triage. See [Scheduled Agents](/platform/triggers/scheduled-agents/). * **Programmable by default** — orchestrate agents via the CLI and integrate Oz into tools and services via the [API and CLI reference](/reference/). diff --git a/src/content/docs/enterprise/enterprise-features/analytics-api.mdx b/src/content/docs/enterprise/enterprise-features/analytics-api.mdx index 959f15fb..056b00c3 100644 --- a/src/content/docs/enterprise/enterprise-features/analytics-api.mdx +++ b/src/content/docs/enterprise/enterprise-features/analytics-api.mdx @@ -6,8 +6,9 @@ description: >- sidebar: label: "Analytics API" --- +import { VARS } from '@data/vars'; -The Enterprise Analytics API lets enterprise admins pull Warp usage data into their own dashboards, cost-allocation tooling, or audit pipelines. It exposes three read-only endpoints over HTTPS that return aggregated team metrics, per-user rollups, and message-level activity events for the agents your team runs in Warp and Oz. +The Enterprise Analytics API lets enterprise admins pull Warp usage data into their own dashboards, cost-allocation tooling, or audit pipelines. It exposes three read-only endpoints over HTTPS that return aggregated team metrics, per-user rollups, and message-level activity events for the agents your team runs in Warp and {VARS.WARP_AUTOMATION_PLATFORM}. :::note[Early access] The Enterprise Analytics API is in Early Access. It is available to all enterprise teams. To start collecting data for your team, an admin must open the Warp app and turn on **Enterprise Usage Reporting (Early Access)** in **Admin Panel** > **Privacy** — no usage data is recorded until that toggle is on. @@ -28,7 +29,7 @@ Before you can call the API, your team must satisfy all of the following: * **Enterprise plan** - The Analytics API is available to all enterprise teams during Early Access; no separate enrollment is required. * **Admin role on the team** - Calls are rejected unless the authenticated user has admin-level permissions on the enterprise team. See [Roles and permissions](/enterprise/team-management/roles-and-permissions/). -* **A personal Warp API key** - Authenticate requests with a key from **Settings** > **Cloud platform** > **Oz Cloud API Keys** in the Warp app. See [API Keys](/reference/cli/api-keys/) for step-by-step instructions. Agent API keys (including legacy team keys) are not accepted by these endpoints — only personal API keys belonging to a team admin work. +* **A personal Warp API key** - Authenticate requests with a key from **Settings** > **Cloud platform** > **{VARS.WARP_AUTOMATION_PLATFORM} Cloud API Keys** in the Warp app. See [API Keys](/reference/cli/api-keys/) for step-by-step instructions. Agent API keys (including legacy team keys) are not accepted by these endpoints — only personal API keys belonging to a team admin work. * **Enterprise Usage Reporting toggle enabled** - In the Warp app, go to **Admin Panel** > **Privacy** and turn on **Enterprise Usage Reporting (Early Access)**. Until this toggle is on, no usage data is recorded for your team and the endpoints will return empty datasets even if every other prerequisite is met. :::caution @@ -296,7 +297,7 @@ Any authenticated user with admin-level permissions on an enterprise team. Calls ### What kind of API key works? -Only **personal** Warp API keys created by an admin from **Settings** > **Cloud platform** > **Oz Cloud API Keys**. Agent API keys (including legacy team keys) are explicitly rejected by these endpoints. See [API Keys](/reference/cli/api-keys/) for how to create one. +Only **personal** Warp API keys created by an admin from **Settings** > **Cloud platform** > **{VARS.WARP_AUTOMATION_PLATFORM} Cloud API Keys**. Agent API keys (including legacy team keys) are explicitly rejected by these endpoints. See [API Keys](/reference/cli/api-keys/) for how to create one. ### Are these calls billed? diff --git a/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx b/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx index c8805b25..8c9e6650 100644 --- a/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx +++ b/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx @@ -4,6 +4,7 @@ description: >- Understand Warp's system architecture and choose the right deployment model for your organization - Warp-hosted, self-hosted, or hybrid. --- +import { VARS } from '@data/vars'; Warp's architecture separates the **control plane** (orchestration, observability, and LLM inference) from the **execution plane** (where agents run, code is accessed, and commands execute). This separation gives enterprise teams flexibility to choose where sensitive workloads run while maintaining centralized management and visibility. @@ -14,9 +15,9 @@ Use this information to evaluate which deployment model fits your organization's Warp's cloud agent infrastructure has four key components: 1. **Trigger** - What starts an agent run (CI step, webhook, cron schedule, Slack mention, CLI command, or API/SDK call). -2. **Orchestration** - What decides what to run and tracks it (Oz orchestrator or your own system). +2. **Orchestration** - What decides what to run and tracks it ({VARS.WARP_AUTOMATION_PLATFORM} orchestrator or your own system). 3. **Execution** - Where the agent actually runs (Warp-hosted environment, your infrastructure, or your existing CI/orchestrator). -4. **Visibility** - How the team monitors and intervenes (Oz dashboard, session sharing, APIs/SDKs). +4. **Visibility** - How the team monitors and intervenes ({VARS.DASHBOARD}, session sharing, APIs/SDKs). {/* TODO: Insert system architecture diagram once received from design team */} @@ -34,7 +35,7 @@ Warp-hosted is the default deployment model. Agents run on Warp-managed infrastr ### How it works * Agents execute in **isolated Docker containers** on Warp-hosted infrastructure (GCP). -* The Oz orchestrator manages agent lifecycle - provisioning, execution, monitoring, and cleanup. +* The {VARS.WARP_AUTOMATION_PLATFORM} orchestrator manages agent lifecycle - provisioning, execution, monitoring, and cleanup. * Environments are ephemeral and destroyed after each run. ### Triggers @@ -75,9 +76,9 @@ Self-hosted deployments use a split architecture: * You control scheduling, scaling, and environment setup. * Warp provides cloud connectivity, shared context, visibility, and session sharing. -**Managed** - Run the `oz-agent-worker` daemon to let the Oz platform orchestrate agents in isolated Docker containers on your infrastructure. +**Managed** - Run the `oz-agent-worker` daemon to let the {VARS.WARP_AUTOMATION_PLATFORM} orchestrate agents in isolated Docker containers on your infrastructure. -* The worker process connects to Oz via WebSocket and receives tasks automatically. +* The worker process connects to {VARS.WARP_AUTOMATION_PLATFORM} via WebSocket and receives tasks automatically. * Agents run in isolated Docker containers managed by the worker. * You get the same orchestration capabilities as Warp-hosted, but execution stays on your infrastructure. @@ -94,7 +95,7 @@ Self-hosted agents require **outbound-only** network access. No inbound network * Compliance or security requirements prevent using Warp-hosted compute. * Source code and execution must stay within your network boundary. -* You want Oz orchestration and visibility without sending code to Warp's infrastructure. +* You want {VARS.WARP_AUTOMATION_PLATFORM} orchestration and visibility without sending code to Warp's infrastructure. ## Hybrid deployments @@ -104,7 +105,7 @@ Organizations can combine Warp-hosted and self-hosted execution to balance conve * Route sensitive workloads (e.g., production code, regulated data) to self-hosted agents. * Route less sensitive workloads (e.g., open-source tooling, internal utilities) to Warp-hosted agents. -* Both execution modes share the same Oz dashboard, session sharing, and API/SDK visibility. +* Both execution modes share the same {VARS.DASHBOARD}, session sharing, and API/SDK visibility. ### Example configurations @@ -151,7 +152,7 @@ Consider the following when selecting a deployment model: ## Related resources -* [Deployment Patterns](/platform/deployment-patterns/) - Detailed patterns for CLI-only, Oz-hosted, and self-hosted setups +* [Deployment Patterns](/platform/deployment-patterns/) - Detailed patterns for CLI-only, {VARS.WARP_AUTOMATION_PLATFORM}-hosted, and self-hosted setups * [Security overview](/enterprise/security-and-compliance/security-overview/) - Data handling, encryption, and compliance details * [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/) - Route inference through your own cloud infrastructure * [Admin Panel](/enterprise/team-management/admin-panel/) - Configure agent policies and security settings diff --git a/src/content/docs/enterprise/enterprise-features/byollm-aws-bedrock.mdx b/src/content/docs/enterprise/enterprise-features/byollm-aws-bedrock.mdx index 4bb536c7..b285f4b2 100644 --- a/src/content/docs/enterprise/enterprise-features/byollm-aws-bedrock.mdx +++ b/src/content/docs/enterprise/enterprise-features/byollm-aws-bedrock.mdx @@ -6,6 +6,7 @@ description: >- Route Warp Agent inference through your AWS account with Bedrock BYOLLM, IAM credentials, and AWS-billed inference. --- +import { VARS } from '@data/vars'; Warp's **AWS Bedrock** BYOLLM integration routes agent inference through your own AWS account using **Amazon Bedrock**. Your team keeps using Warp's agents as usual, while eligible requests execute against Claude models hosted in your AWS account, billed to your AWS account and governed by your IAM controls. @@ -248,7 +249,7 @@ This applies the OIDC role only to runs from a specific named agent. To safely test BYOLLM, configure it on a single named agent first. Misconfigurations scoped to one agent only affect that agent's runs, not the whole team. ::: -In the Oz web app: +In the {VARS.WEB_APP}: 1. [Create a new agent](/platform/oz-web-app/#creating-a-new-agent) or edit an existing one. 2. In the agent form, expand the **AWS Bedrock** section. diff --git a/src/content/docs/enterprise/getting-started/getting-started-developers.mdx b/src/content/docs/enterprise/getting-started/getting-started-developers.mdx index 638efa0b..b5005763 100644 --- a/src/content/docs/enterprise/getting-started/getting-started-developers.mdx +++ b/src/content/docs/enterprise/getting-started/getting-started-developers.mdx @@ -4,10 +4,11 @@ description: >- Download Warp, log in to your team, and start using agents, Codebase Context, and collaborative features to accelerate your development workflow. --- +import { VARS } from '@data/vars'; This guide helps developers get up and running with their team in Warp. You'll learn how to download Warp, log in with your organization's SSO, and configure key features like Codebase Context, Warp Drive, and Agent Profiles to accelerate your work across the entire SDLC (all while staying in your terminal). -When you use agents in Warp, you're working with **Warp's built-in agents**. Oz is Warp's programmable platform for running and coordinating agents at scale, whether they run locally on your machine or in the cloud. Oz provides the orchestration, tracking, and control plane that makes scaling agent workflows seamless. +When you use agents in Warp, you're working with **Warp's built-in agents**. {VARS.WARP_AUTOMATION_PLATFORM} is Warp's programmable system for running and coordinating agents at scale, whether they run locally on your machine or in the cloud. {VARS.WARP_AUTOMATION_PLATFORM} provides the orchestration, tracking, and control plane that makes scaling agent workflows seamless. :::note New to Warp Enterprise? Try the [Enterprise quickstart](/enterprise/getting-started/quickstart/) for a 10-minute walkthrough of SSO login, Warp setup, and running your first agent. diff --git a/src/content/docs/enterprise/getting-started/quickstart.mdx b/src/content/docs/enterprise/getting-started/quickstart.mdx index 073248e7..63b7da5e 100644 --- a/src/content/docs/enterprise/getting-started/quickstart.mdx +++ b/src/content/docs/enterprise/getting-started/quickstart.mdx @@ -6,6 +6,7 @@ description: >- sidebar: label: "Quickstart" --- +import { VARS } from '@data/vars'; This quickstart walks you through the essentials: logging in via SSO, setting up Warp, and running your first agent. You can complete this in under 10 minutes. @@ -34,7 +35,7 @@ If you have an existing Warp account from before your organization enabled SSO, ## 3. Configure and run your first agent -When you use agents in Warp, you're working with **Warp's built-in agents**. Oz is Warp's programmable platform for running and coordinating agents at scale, whether they run locally on your machine or in the cloud. +When you use agents in Warp, you're working with **Warp's built-in agents**. {VARS.WARP_AUTOMATION_PLATFORM} is Warp's programmable system for running and coordinating agents at scale, whether they run locally on your machine or in the cloud. ### Index your codebase @@ -51,14 +52,14 @@ Start a conversation right in the terminal. Try the following prompt: Explain the architecture of this project ``` -Oz reads your codebase, understands its structure, and responds with a context-aware explanation. +{VARS.WARP_AUTOMATION_PLATFORM} reads your codebase, understands its structure, and responds with a context-aware explanation. ### Try more prompts * **Write code** - "Add input validation to the signup form" * **Debug** - "Why is this test failing?" (paste the error output) * **Explore** - "What patterns does this repo use for error handling?" -* **Plan** - Use `/plan` to have Oz create a structured task plan for complex features +* **Plan** - Use `/plan` to have {VARS.WARP_AUTOMATION_PLATFORM} create a structured task plan for complex features ## 4. Run a cloud agent @@ -76,7 +77,7 @@ From the Warp app terminal input, run the command: ``` This launches an interactive flow that guides you through environment setup. -**Option 2: Oz web app** +**Option 2: {VARS.WEB_APP}** Go to the [Environments page](https://app.warp.dev/environments) and click **Create Environment**. @@ -88,7 +89,7 @@ Once your environment is ready, use the following command to launch a cloud agen oz agent run-cloud --env my-env --prompt "Review the open PRs in this repo" ``` -Monitor and steer cloud agents from the Oz dashboard or directly in Warp. +Monitor and steer cloud agents from the {VARS.DASHBOARD} or directly in Warp. ## Next steps diff --git a/src/content/docs/enterprise/index.mdx b/src/content/docs/enterprise/index.mdx index c9e69b85..d3a78235 100644 --- a/src/content/docs/enterprise/index.mdx +++ b/src/content/docs/enterprise/index.mdx @@ -4,13 +4,14 @@ description: >- Warp Enterprise provides the security, control, and collaboration features organizations need to deploy Warp across their engineering teams at scale. --- +import { VARS } from '@data/vars'; Warp Enterprise is built for organizations that want to accelerate software development with agents while maintaining security, compliance, and administrative control. It brings Warp's **Agentic Development Environment** to your entire engineering organization with the governance features IT and security teams require. Warp has two core products: * **Warp Terminal** - A modern terminal designed for agentic development where developers run commands, collaborate with agents, and orchestrate autonomous work from the command line. -* **Oz** - Warp's programmable platform for running and coordinating agents at scale. Oz powers all agents in Warp, whether they run locally or in the cloud, and provides the orchestration, tracking, and control plane for scalable agent workflows. +* **{VARS.WARP_AUTOMATION_PLATFORM}** - Warp's programmable system for running and coordinating agents at scale. {VARS.WARP_AUTOMATION_PLATFORM} powers all agents in Warp, whether they run locally or in the cloud, and provides the orchestration, tracking, and control plane for scalable agent workflows. ## Who Warp Enterprise is for @@ -46,10 +47,10 @@ Warp Enterprise serves three primary audiences: ### Agent capabilities * **State-of-the-art agents** - Multi-model agents with full terminal access, code editing, and autonomous task execution * **Cloud agents** - Run agents in the cloud for unlimited parallelization, background automation, and long-running workflows. Perfect for PR reviews, scheduled tasks, and distributed work across multiple repositories -* **Integrated control plane** - Launch, orchestrate, and manage local, cloud, and autonomous agents from a unified interface. Track all agent activity across your team from the Oz dashboard +* **Integrated control plane** - Launch, orchestrate, and manage local, cloud, and autonomous agents from a unified interface. Track all agent activity across your team from the {VARS.DASHBOARD} * **Agent Profiles** - Customize agent behavior, models, autonomy levels, and permissions * **Rules and guardrails** - Enforce coding standards, tech stack preferences, and security practices through team-wide or project-specific rules -* **Multi-agent support** - Support for all major models and CLI coding agents (Oz, Claude Code, Codex, Copilot) +* **Multi-agent support** - Support for all major models and CLI coding agents ({VARS.WARP_AUTOMATION_PLATFORM}, Claude Code, Codex, Copilot) ## What this section covers diff --git a/src/content/docs/enterprise/security-and-compliance/security-overview.mdx b/src/content/docs/enterprise/security-and-compliance/security-overview.mdx index d2eb2c1b..626e2d7e 100644 --- a/src/content/docs/enterprise/security-and-compliance/security-overview.mdx +++ b/src/content/docs/enterprise/security-and-compliance/security-overview.mdx @@ -5,6 +5,7 @@ description: >- compliance certifications to ensure your organization's requirements are met. --- +import { VARS } from '@data/vars'; Warp builds security and compliance into its core, keeping **developers in control** while enabling powerful agent workflows. This overview explains how Warp handles your data, what security controls are available, and how Warp meets enterprise security standards. @@ -31,7 +32,7 @@ How data collection works by plan: * **Business and Enterprise** - Team admins can enforce data collection settings for the entire team. Data collection is **disabled by default**. :::note -Some product features — including cloud conversations and Oz runs — require storing conversation data to function. This data is stored to power the product experience and is separate from analytics or telemetry data collection. +Some product features — including cloud conversations and {VARS.PLATFORM_RUN}s — require storing conversation data to function. This data is stored to power the product experience and is separate from analytics or telemetry data collection. ::: Some models carry provider-specific data retention requirements and are therefore not covered by ZDR. For Enterprise teams, these models are **off by default**; a workspace admin must explicitly enable them in the [Admin Panel](/enterprise/team-management/admin-panel/#models-settings). @@ -131,7 +132,7 @@ Self-hosted deployments use a split architecture: Two deployment modes are available: * **Unmanaged** - Use `oz agent run` to run agents in your existing orchestrator or CI environment. Supports Linux, macOS, and Windows with no Docker dependency. -* **Managed** - Run the `oz-agent-worker` daemon to let the Oz platform orchestrate agents in isolated Docker containers on your infrastructure. +* **Managed** - Run the `oz-agent-worker` daemon to let the {VARS.WARP_AUTOMATION_PLATFORM} orchestrate agents in isolated Docker containers on your infrastructure. Agent runs are fully tracked and steerable in both modes. No inbound network access is required. diff --git a/src/content/docs/enterprise/team-management/admin-panel.mdx b/src/content/docs/enterprise/team-management/admin-panel.mdx index 67aed514..eedbbef8 100644 --- a/src/content/docs/enterprise/team-management/admin-panel.mdx +++ b/src/content/docs/enterprise/team-management/admin-panel.mdx @@ -7,6 +7,7 @@ description: >- sidebar: label: "Admin panel" --- +import { VARS } from '@data/vars'; The Admin Panel provides administrators with centralized control over team settings in Warp. Configure agent behavior, security policies, codebase indexing, and collaboration features for your entire organization from a single interface. diff --git a/src/content/docs/factories/configure-your-factory.mdx b/src/content/docs/factories/configure-your-factory.mdx new file mode 100644 index 00000000..0198192b --- /dev/null +++ b/src/content/docs/factories/configure-your-factory.mdx @@ -0,0 +1,18 @@ +--- +title: Configure your Factory +description: >- + Define agent roles, skills, MCPs, and permissions for your Warp Factory as + version-controlled code. +sidebar: + label: "Configure your Factory" +--- + +[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. + +Lightweight aggregation page — mostly link into existing detailed docs rather than duplicate them. Cover: +- Factory definitions as code: repos, agent role definitions, skills, MCPs, permissions +- Configuring the default agents (triage, spec, implement, review) and adding custom agents/automations +- Model and harness choice per agent role (link to the Automation Platform tab's Harnesses docs) +- Metrics, evals, and self-improvement configuration (control room, scorers, benchmarks) + +Cross-link to the Automation Platform tab for underlying primitives (Environments, Integrations, Orchestration) rather than duplicating that content.] diff --git a/src/content/docs/factories/connect-your-factory.mdx b/src/content/docs/factories/connect-your-factory.mdx new file mode 100644 index 00000000..675c8bb9 --- /dev/null +++ b/src/content/docs/factories/connect-your-factory.mdx @@ -0,0 +1,18 @@ +--- +title: Connect your Factory +description: >- + Route work into your Warp Factory from Slack, Linear, GitHub, and local + coding agents via the Factory MCP. +sidebar: + label: "Connect your Factory" +--- + +[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. + +Lightweight aggregation page — mostly link into existing detailed docs rather than duplicate them. Cover: +- How work enters a Factory: communication tools (Slack/Teams), task trackers (Linear/Jira), source forges (GitHub/GitLab) +- The Factory MCP: how any coding agent or MCP client can push work in, pull status, or guide sessions +- Integration with Warp Terminal and the Warp Agent CLI (native MCP support, local-to-factory handoff) +- API, SDK, and CLI for building custom integrations (cross-link to the Reference tab) + +Cross-link to the Automation Platform tab's Integrations docs for the underlying connector setup rather than duplicating it.] diff --git a/src/content/docs/factories/how-factories-work.mdx b/src/content/docs/factories/how-factories-work.mdx new file mode 100644 index 00000000..5eeb05be --- /dev/null +++ b/src/content/docs/factories/how-factories-work.mdx @@ -0,0 +1,21 @@ +--- +title: How Warp Factories work +description: >- + Warp Factories move work through triage, spec, implementation, review, and + verification, with humans in the loop and every step defined as code. +sidebar: + label: "How Factories work" +--- + +[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. + +This page absorbs and supersedes the existing conceptual content at `platform/software-factory.mdx` (inner loop / outer loop, agent roles: triage, spec, implementation, reviewer) — see that file for source material and the redirect from `/platform/software-factory` added in `vercel.json`. + +Cover, per the launch blog draft: +- Work item lifecycle: Triage → Spec → Implement → Review → Verify +- The foreman/orchestrator agent and how it dispatches subagents +- Human-in-the-loop decision points +- Factory definitions as code (version-controlled repos, agent roles, skills, MCPs, permissions) +- Natively multi-model and multi-harness + +Cross-link to Configure your Factory and Connect your Factory for the procedural follow-through.] diff --git a/src/content/docs/factories/index.mdx b/src/content/docs/factories/index.mdx new file mode 100644 index 00000000..520a0fc8 --- /dev/null +++ b/src/content/docs/factories/index.mdx @@ -0,0 +1,20 @@ +--- +title: Warp Factories overview +description: >- + Warp Factories give engineering teams open, flexible infrastructure for + building and operating their own cloud software factories. +sidebar: + label: "Overview" +--- + +[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. This page is the Factories tab landing page (`/factories/`). + +Cover, per the launch positioning: +- What a software factory is (automation loop around the SDLC: triage, spec, implement, review, verify) and why teams are building them +- How Warp Factories relates to Warp Agent / Warp Terminal / the CLI (decoupled products that interoperate) +- The "open, flexible infrastructure" positioning: AI sovereignty, bring-your-own inference/hosting, factory definitions as code +- Closed beta status + apply/waitlist CTA (mention the $10k qualified-org usage offer if approved for this surface) + +See `.agents/references/terminology.md` → "Warp Factories terminology" for the baseline glossary (factory, software factory, work item, Factory MCP, control room, etc.) to write against. + +Cross-link to: Quickstart, How Factories work, and the Automation Platform tab (primitives Factories are built on).] diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx new file mode 100644 index 00000000..4be57f77 --- /dev/null +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -0,0 +1,16 @@ +--- +title: Warp Factories infrastructure and security +description: >- + Warp Factories give you control over inference, hosting, and data exhaust + so you own your factory's infrastructure and outputs. +sidebar: + label: "Infrastructure & security" +--- + +[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. + +Lightweight aggregation page — mostly link into existing detailed docs rather than duplicate them. Cover: +- AI sovereignty positioning: bring your own inference, bring your own hosting, own your data exhaust (agent conversations, evals, memories), ZDR +- Self-hosting (cross-link to the Automation Platform tab's Self-hosting docs rather than duplicating) +- Security, permissions, and governance for factory agent runs +- Closed beta / apply for access treatment consistent with other Factories pages] diff --git a/src/content/docs/factories/integrations/github.mdx b/src/content/docs/factories/integrations/github.mdx new file mode 100644 index 00000000..a05fb644 --- /dev/null +++ b/src/content/docs/factories/integrations/github.mdx @@ -0,0 +1,84 @@ +--- +title: Connect a factory to GitHub +description: >- + Connect a factory to GitHub to route repository events into work and return + comments, branches, and pull request links. +sidebar: + label: "GitHub" +topic: factories +--- + +Connect a factory to GitHub to route supported repository events into factory work while preserving source context and returning progress or code artifacts to GitHub. + +## Prerequisites and authorization + +* **GitHub App installation** - Install the Oz by Warp GitHub App and grant it access to the repositories the factory uses. Follow the [GitHub integration setup](../../platform/integrations/github) for installation, organization association, and account connection. +* **Factory repositories** - Create or select a factory that uses GitHub, then include at least one repository covered by the GitHub App installation. +* **GitHub permissions** - Confirm the installation permits the work you expect agents to perform. + +The GitHub App installation is the authorization boundary for private repository access. Its credential can reach the repositories selected for that installation, subject to the app's permissions. Factory repository selection and automation filters route context and events; they do not further narrow the credential. + +When an event matches, Warp starts the configured factory agent. The event author is source context, does not supply the run's credentials, and does not need Warp team membership. Restrict who triggers work with repository, event, and author filters; restrict run reach through the GitHub App installation's repository selection. + +## Connect and configure GitHub + +1. In the factory setup flow, choose **I want to use repos from GitHub.** under **Connect your code host**. +2. Under **Select your repos**, choose the repositories that provide code and context for the factory. +3. In the factory's control room, open **Automations** and create an automation. Choose the receiving agent and add any **Additional instructions**. +4. Under **Triggers**, click **Add trigger**, choose **GitHub**, and choose an event. Select one factory repository, then click **More filters** to narrow the matching activity. +5. Click **Save**, then send a representative event and confirm the expected work item starts or continues. + +## Supported triggers, context, and outputs + +| Trigger class | Supported activity | Context continuity | Typical output | +| --- | --- | --- | --- | +| Issues | Created, labeled, assigned, or mentioned | GitHub issue | Reaction, status comments, summary, and pull request links | +| Pull requests | Opened, ready, reopened, updated with commits, assigned, labeled, mentioned, closed, or merged | Pull request | Comments, code changes, branches, and pull request links | +| Reviews | Review requested or submitted | Pull request or review thread | Reaction, comments, code changes, and pull request links | +| Code and CI | Push, completed check suite or workflow run, or a re-requested Warp-owned check | Commit, pull request, or workflow event | Run result, code changes, and artifact links | + +GitHub only sends check re-request events to the app that created the check. Re-requesting a third-party CI check does not trigger a Warp-owned check event. + +### Automation filters + +Each event exposes only the filters that apply to that event. Available filters include **Repositories**, **Branches**, **Base branches**, **Paths**, **Labels**, **Authors**, **Assignees**, mentioned users or teams, reviewers, review states, workflows, and conclusions. + +For example, route failed runs of a named workflow to a CI-repair automation. Filters decide which events reach an automation. They do not change the repositories or actions authorized by the GitHub App installation. + +## Continue work from GitHub + +Activity associated with the same issue, pull request, or review thread can continue its existing work item with the earlier GitHub context, run history, and artifacts. + +Warp acknowledges handled activity with a reaction and posts comments where GitHub provides a comment surface. Responses can link to the run, branches, and pull requests. A push or CI event without a comment surface retains its result on the work item. + +Agents use the GitHub App installation credential to create branches and pull requests from the run environment. Merge requirements, required reviews, and branch protection remain GitHub repository policy. They are not factory-specific role-based access controls. + +## Factory-definition pull request checks + +Pull request validation for a factory definition is separate from a GitHub work automation. Warp validates relevant changes under the registered factory directory and reports a check with diagnostics or a change summary. + +These checks validate the factory configuration itself. They do not make every pull request a factory work item, and their re-run behavior applies only to checks created by the Warp GitHub App. + +## Permissions and operational boundaries + +An installation token does not grant private repository reads or writes outside the installation's repository grant. Public repository access and other configured credentials are separate. Factory repository selection and automation filters neither expand nor narrow the installation token's reach. + +Use automation filters to limit intake noise, and use the GitHub installation settings to limit credential reach. Review both boundaries whenever you add repositories or broaden an event subscription. + +## Troubleshooting + +### A GitHub event does not start work + +Confirm that the GitHub App installation covers the event's repository, the repository belongs to the factory, and the saved automation includes that event. Then check every configured filter against the event. A label, author, branch, workflow, conclusion, or state mismatch prevents routing. + +### Filter options do not load + +Select a repository first. If the automation editor shows **Connect GitHub**, complete the account connection and retry. You can enter a canonical value when suggestions are unavailable. + +### An agent cannot push a branch or open a pull request + +Check that the installation still covers the target repository and grants the required write permissions. Changing an automation filter cannot restore missing GitHub authorization. + +### A factory-definition check does not appear + +Confirm that the pull request targets the factory definition's production branch and that the GitHub App covers the registered repository. Pull requests that do not change files under the registered factory directory can complete without configuration changes. diff --git a/src/content/docs/factories/quickstart.mdx b/src/content/docs/factories/quickstart.mdx new file mode 100644 index 00000000..13312a88 --- /dev/null +++ b/src/content/docs/factories/quickstart.mdx @@ -0,0 +1,19 @@ +--- +title: Warp Factories quickstart +description: >- + Create a Warp Factory, connect a repo, and trigger your first automated + work item in a few minutes. +sidebar: + label: "Quickstart" +--- + +[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. + +Follow the quickstart template (`.agents/templates/quickstart.md`). Cover: +1. Create a Factory +2. Connect a repo +3. Configure the default agents (triage, spec, implement, review) +4. Trigger work (e.g. via Slack, Linear, GitHub, or the Factory MCP) +5. View / interact with the run in the control room web app + +Keep prerequisites minimal and link out to How Factories work / Configure your Factory / Connect your Factory for depth rather than inlining it here.] diff --git a/src/content/docs/getting-started/migrate-to-warp/migrate-to-warp-from-claude-code.mdx b/src/content/docs/getting-started/migrate-to-warp/migrate-to-warp-from-claude-code.mdx index 3c0e1a5c..23a76bd6 100644 --- a/src/content/docs/getting-started/migrate-to-warp/migrate-to-warp-from-claude-code.mdx +++ b/src/content/docs/getting-started/migrate-to-warp/migrate-to-warp-from-claude-code.mdx @@ -5,6 +5,7 @@ description: >- notifications — or switch from Claude Code to Warp's Agent Mode as your primary coding agent. --- +import { VARS } from '@data/vars'; Claude Code is different from the other sources in this section: it's not a terminal emulator, it's a CLI agent that runs inside any terminal. Warp is an agentic development environment with a built-in [code editor](/code/code-editor/), [Code Review](/code/code-review/), [team collaboration](/knowledge-and-collaboration/warp-drive/), and [MCP](/agents/capabilities/mcp/) support — so you have two paths to choose from: @@ -75,7 +76,7 @@ Warp's Agent also pulls context from several other explicit sources: * **Tight terminal integration.** Agent Mode runs inside Warp and sees the full state of your terminal session — open files, command history, environment variables — without needing you to paste context. * **Parallel agents.** Warp runs multiple agent conversations across tabs simultaneously, each with its own state, which you can track in the Agent Management Panel. * **Code Review built in.** Agent-generated diffs open in Warp's [Code Review](/code/code-review/) panel, not the terminal. -* **Cloud orchestration.** Long-running or scheduled agent work can be offloaded to [Oz](/platform/). +* **Cloud orchestration.** Long-running or scheduled agent work can be offloaded to [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/). ## Warp-native equivalents diff --git a/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx b/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx index 9f84609a..7668c92e 100644 --- a/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx +++ b/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx @@ -11,6 +11,7 @@ tags: - "cloud-agents" - "schedules" --- +import { VARS } from '@data/vars'; A self-improving agent is the outer loop of the [software factory](/guides/agent-workflows/set-up-a-software-factory) you've built in the previous guides. It watches how maintainers correct the inner-loop agents — relabeled issues, edited comments, changed code — and opens a pull request to improve the skill files that drive those agents. Every correction from a teammate becomes a proposed improvement to the factory. @@ -24,7 +25,7 @@ The outer loop proposes improvements; it doesn't apply them silently. Every chan * A working inner loop with at least one agent running ([set up your software factory](/guides/agent-workflows/set-up-a-software-factory)) * A Warp account ([sign up at warp.dev](https://www.warp.dev)) -* An Oz cloud environment with access to your repository ([create one](/platform/environments)) +* A cloud environment with access to your repository ([create one](/platform/environments)) ## Why principles beat rules @@ -83,7 +84,7 @@ The [`update-triage`](https://github.com/warpdotdev/oz-for-oss/blob/main/.agents Weekly is a good starting cadence: it processes the previous week's corrections and opens PRs for review at the start of the week. -1. Create a scheduled cloud agent from the Oz CLI: +1. Create a scheduled cloud agent from the {VARS.WARP_AGENT_CLI}: ```bash oz schedule create \ @@ -93,9 +94,9 @@ Weekly is a good starting cadence: it processes the previous week's corrections --cron "0 9 * * 1" ``` - Or, from the Oz web app: open **Agents** > **Schedules**, click **New schedule**, and set the skill, environment, and cron expression. + Or, from the {VARS.WEB_APP}: open **Agents** > **Schedules**, click **New schedule**, and set the skill, environment, and cron expression. -2. Replace `YOUR_ENVIRONMENT_SLUG` with the slug of your Oz environment. +2. Replace `YOUR_ENVIRONMENT_SLUG` with the slug of your {VARS.WARP_AUTOMATION_PLATFORM} environment. See [Scheduled agents](/platform/triggers/scheduled-agents) for the full reference. @@ -121,7 +122,7 @@ Over time, the companion skill accumulates a clear description of how your team * [What is a software factory?](/platform/software-factory) — How the outer improvement loop fits into the full factory model. * [Set up your software factory](/guides/agent-workflows/set-up-a-software-factory) — The inner loop the outer loop improves. -* [Run a software factory in the cloud](/guides/agent-workflows/run-a-software-factory-in-the-cloud) — Move the loop to Oz for team-wide visibility. +* [Run a software factory in the cloud](/guides/agent-workflows/run-a-software-factory-in-the-cloud) — Move the loop to {VARS.WARP_AUTOMATION_PLATFORM} for team-wide visibility. * [Scheduled agents](/platform/triggers/scheduled-agents) — Full reference for running cloud agents on a cadence. * [`warpdotdev/oz-for-oss`](https://github.com/warpdotdev/oz-for-oss) — The complete reference implementation including all outer-loop skills. -* [Skills](/agents/capabilities/skills) — How skill files work in Warp and Oz. +* [Skills](/agents/capabilities/skills) — How skill files work in Warp and {VARS.WARP_AUTOMATION_PLATFORM}. diff --git a/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx b/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx index 0e768b31..327fecaa 100644 --- a/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx +++ b/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx @@ -9,15 +9,16 @@ tags: - "cloud-agents" - "software-factory" --- +import { VARS } from '@data/vars'; -Learn how to use Oz to build a triage agent that reviews each new GitHub issue for clarity, applies labels, and flags open questions before implementation begins. After completing the steps in this guide, you will have a working triage skill deployed as a GitHub Action. This is the first agent in your [software factory](/platform/software-factory). +Learn how to use {VARS.WARP_AUTOMATION_PLATFORM} to build a triage agent that reviews each new GitHub issue for clarity, applies labels, and flags open questions before implementation begins. After completing the steps in this guide, you will have a working triage skill deployed as a GitHub Action. This is the first agent in your [software factory](/platform/software-factory). ## Prerequisites * A Warp account ([sign up at warp.dev](https://www.warp.dev)) * A GitHub repository with Issues enabled -* An Oz cloud environment with access to your repository ([create one](/platform/environments#create-an-environment-with-guided-setup-recommended)) -* A Warp API key added to your CI secrets as `WARP_API_KEY` ([create one](/reference/cli/api-keys#from-the-oz-web-app-recommended)) +* A cloud environment with access to your repository ([create one](/platform/environments#create-an-environment-with-guided-setup-recommended)) +* A Warp API key added to your CI secrets as `WARP_API_KEY` ([create one](/reference/cli/api-keys#from-the-web-app-recommended)) ## 1. Define your triage criteria @@ -59,7 +60,7 @@ The [`bootstrap-issue-config`](https://github.com/warpdotdev/oz-for-oss/blob/mai ## 3. Test the triage agent locally -Before deploying to GitHub Actions, test the triage agent against a real issue using the Oz CLI: +Before deploying to GitHub Actions, test the triage agent against a real issue using the {VARS.WARP_AGENT_CLI}: ```bash oz agent run \ @@ -70,7 +71,7 @@ oz agent run \ The `--share` flag generates a session link your team can use to inspect what the agent did. Review the session output to confirm that the labels and comments are what you expect. If something is wrong, refine the skill file and run again. -For the full reference of `oz agent run` flags, see the [Oz CLI reference](/reference/cli/). +For the full reference of `oz agent run` flags, see the [{VARS.WARP_AGENT_CLI} reference](/reference/cli/). ## 4. Deploy with GitHub Actions @@ -106,7 +107,7 @@ jobs: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` -2. Replace `YOUR_OZ_ENVIRONMENT_SLUG` with the slug of the Oz environment you created in the prerequisites. +2. Replace `YOUR_OZ_ENVIRONMENT_SLUG` with the slug of the {VARS.WARP_AUTOMATION_PLATFORM} environment you created in the prerequisites. 3. Add `WARP_API_KEY` to your repository's GitHub Actions secrets under **Settings** > **Secrets and variables** > **Actions**. @@ -114,7 +115,7 @@ See [GitHub Actions integration](/platform/integrations/github-actions) for the ## 5. Review and improve -Watch the first few runs in the [Oz web app](https://oz.warp.dev) to verify the agent is labeling and commenting correctly. When you disagree with the agent, e.g., when you relabel an issue or edit a comment, note the pattern. Patterns you see repeatedly are signals to update your skill file. +Watch the first few runs in the {VARS.WEB_APP} to verify the agent is labeling and commenting correctly. When you disagree with the agent, e.g., when you relabel an issue or edit a comment, note the pattern. Patterns you see repeatedly are signals to update your skill file. Add repo-specific context without forking the core skill by creating a `triage-issue-local` companion skill. This file specializes the base skill for your repository (your label taxonomy, ownership map, and definition of readiness) while keeping the shared skill stable. See the [docs repo example](https://github.com/warpdotdev/docs/blob/main/.agents/skills/triage-issue-local/SKILL.md) for the companion skill pattern. diff --git a/src/content/docs/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs.mdx b/src/content/docs/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs.mdx index c0ce86c1..519b57da 100644 --- a/src/content/docs/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs.mdx +++ b/src/content/docs/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs.mdx @@ -10,6 +10,7 @@ tags: - "code-review" - "session-sharing" --- +import { VARS } from '@data/vars'; When an agent helps prepare a pull request, reviewers need the execution context behind the diff: the original prompt, plan, commands, validation results, code changes, and decisions that still need human review. @@ -18,7 +19,7 @@ Add a Warp session or cloud agent run link to the PR description or a PR comment Use these Warp docs and surfaces to collect the right context: * [Agent Session Sharing](/agents/local-agents/session-sharing/) for local Warp agents or third-party CLI agents running in Warp. -* [Cloud agent session sharing](/platform/viewing-cloud-agent-runs/) for cloud agent runs started from Slack, Linear, GitHub Actions, schedules, the Oz CLI, or the API. +* [Cloud agent session sharing](/platform/viewing-cloud-agent-runs/) for cloud agent runs started from Slack, Linear, GitHub Actions, schedules, the {VARS.WARP_AGENT_CLI}, or the API. * The [Code Review panel](/code/code-review/) and [Interactive Code Review](/agents/local-agents/interactive-code-review/) to inspect and refine the actual code diff before or after you share the PR. ## What to include in the PR @@ -71,7 +72,7 @@ See [Agent Session Sharing](/agents/local-agents/session-sharing/) for the full If the agent ran in the cloud, use the cloud run session link: -1. Open the run from the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app or the [Runs page in the Oz web app](/platform/oz-web-app/#runs). +1. Open the run from the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app or the [Runs page in the {VARS.WEB_APP}](/platform/oz-web-app/#runs). 2. Confirm the session shows the run context reviewers need. 3. Copy the cloud agent session link. 4. Paste the link into the PR description or a PR comment. @@ -101,7 +102,7 @@ Reviewers should not have to read an entire transcript to understand what happen * Any failed commands and how they were resolved. * Any assumptions the agent made. -If the PR came from an automated workflow, include the trigger source too. For example: Slack thread, Linear issue, GitHub Actions workflow, scheduled agent, Oz CLI command, or API call. +If the PR came from an automated workflow, include the trigger source too. For example: Slack thread, Linear issue, GitHub Actions workflow, scheduled agent, {VARS.WARP_AGENT_CLI} command, or API call. ## 4. Watch for sensitive context before sharing diff --git a/src/content/docs/guides/agent-workflows/how-to-run-multiple-ai-coding-agents.mdx b/src/content/docs/guides/agent-workflows/how-to-run-multiple-ai-coding-agents.mdx index c02d63e1..a7a3ff04 100644 --- a/src/content/docs/guides/agent-workflows/how-to-run-multiple-ai-coding-agents.mdx +++ b/src/content/docs/guides/agent-workflows/how-to-run-multiple-ai-coding-agents.mdx @@ -11,12 +11,13 @@ tags: --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; Use multiple coding agents, including Warp Agent, Claude Code, Codex, and other CLI agents, when work can be split into independent tasks, reviewed from separate branches, or delegated to cloud agents while you keep working locally. In Warp, you can coordinate agents in three ways: * **Local parallel sessions** - run Warp Agent, Claude Code, Codex, OpenCode, or another CLI agent in separate tabs or panes. * **Isolated worktrees** - give each agent its own Git worktree and branch so parallel edits do not collide. -* **Oz cloud orchestration** - use `/orchestrate`, `/plan`, the Oz CLI, the Oz web app, or the Oz API to fan work out to child agents in cloud environments. +* **{VARS.WARP_AUTOMATION_PLATFORM} cloud orchestration** - use `/orchestrate`, `/plan`, the {VARS.WARP_AGENT_CLI}, the {VARS.WEB_APP}, or the {VARS.API_SDK_NAME} to fan work out to child agents in cloud environments. The best multi-agent workflows have one thing in common: each agent owns a clear slice of work, reports back with validation results, and hands off a branch, diff, PR, or concise finding you can review. @@ -35,7 +36,7 @@ Plan on about 15 minutes for the local setup. Cloud orchestration takes longer o | Split by file or subsystem | A feature spans independent modules that can be changed in parallel. | Assign each agent a worktree, branch, file boundary, and validation command. | | Builder plus reviewer | One agent implements while another reviews, writes tests, or checks edge cases. | Put the reviewer in a read-only or review-focused tab, or use a separate branch for test-only changes. | | Cloud fan-out | The work is large, slow, or can run away from your laptop. | Use [Multi-agent orchestration](/platform/orchestration/) or [Running orchestrated agents](/platform/orchestration/multi-agent-runs/) to spawn cloud children. | -| Repeatable fleet workflow | You want the same agent pattern on every PR, issue, schedule, or release. | Use a cloud agent with a trigger, skill, or API workflow, then inspect parent and child runs in the [Oz web app](/platform/oz-web-app/). | +| Repeatable fleet workflow | You want the same agent pattern on every PR, issue, schedule, or release. | Use a cloud agent with a trigger, skill, or API workflow, then inspect parent and child runs in the [{VARS.WEB_APP}](/platform/oz-web-app/). | ## Plan the split before launching agents @@ -216,8 +217,8 @@ Use cloud agents when the work is long-running, resource-intensive, easy to shar ``` 2. Use `/plan` for larger changes where you want to review the plan, orchestration config, child ownership, and merge strategy before agents launch. -3. For repeatable or unattended workflows, start the parent from the Oz CLI, the Oz web app, or the Oz API. See [Running orchestrated agents](/platform/orchestration/multi-agent-runs/) for launch options. -4. Inspect parent and child runs from the [Oz web app](/platform/oz-web-app/) or the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app. +3. For repeatable or unattended workflows, start the parent from the {VARS.WARP_AGENT_CLI}, the {VARS.WEB_APP}, or the {VARS.API_SDK_NAME}. See [Running orchestrated agents](/platform/orchestration/multi-agent-runs/) for launch options. +4. Inspect parent and child runs from the [{VARS.WEB_APP}](/platform/oz-web-app/) or the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app. Cloud orchestration is the best fit when you need: @@ -254,7 +255,7 @@ Explore related guides and features: * [How to review AI-generated code](/guides/agent-workflows/how-to-review-ai-generated-code/) — review and refine the code your agents produced * [Attach agent session context to GitHub PRs](/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs/) — give reviewers the agent context behind a PR * [Multi-agent orchestration](/platform/orchestration/) — coordinate parent and child agents across local and cloud runs -* [Running orchestrated agents](/platform/orchestration/multi-agent-runs/) — start orchestrated runs from Warp, the Oz CLI, the Oz web app, or the Oz API +* [Running orchestrated agents](/platform/orchestration/multi-agent-runs/) — start orchestrated runs from Warp, the {VARS.WARP_AGENT_CLI}, the {VARS.WEB_APP}, or the {VARS.API_SDK_NAME} * [Set up Claude Code](/guides/external-tools/how-to-set-up-claude-code/) or [Set up Codex CLI](/guides/external-tools/how-to-set-up-codex-cli/) — install both agents if you haven't already * [Claude Code in Warp](https://www.warp.dev/agents/claude-code) — overview of Claude Code support in Warp * [Codex in Warp](https://www.warp.dev/agents/codex) — overview of Codex support in Warp diff --git a/src/content/docs/guides/agent-workflows/how-to-run-unattended-agents.mdx b/src/content/docs/guides/agent-workflows/how-to-run-unattended-agents.mdx index 5d5b35ee..b060dd1a 100644 --- a/src/content/docs/guides/agent-workflows/how-to-run-unattended-agents.mdx +++ b/src/content/docs/guides/agent-workflows/how-to-run-unattended-agents.mdx @@ -2,7 +2,7 @@ title: How to run unattended agents description: >- Start unattended cloud agents from schedules, Slack, Linear, GitHub, GitHub - Actions, the Oz CLI, or the Oz API, then inspect every run. + Actions, the {{WARP_AGENT_CLI}}, or the {{WARP_AUTOMATION_PLATFORM}} API, then inspect every run. sidebar: label: "Run unattended agents" featured: true @@ -11,10 +11,11 @@ tags: - "cloud-agents" - "schedules" --- +import { VARS } from '@data/vars'; -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. +Warp cloud agents can run unattended from schedules, team tools, CI, the {VARS.WARP_AGENT_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](/platform/oz-web-app/#runs), the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app, or the session link posted back to the tool that triggered the agent. +Every unattended workflow creates a cloud agent run that your team can inspect later. Open runs from the [Runs page in the {VARS.WEB_APP}](/platform/oz-web-app/#runs), the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app, or the session link posted back to the tool that triggered the agent. ## Choose a trigger @@ -22,13 +23,13 @@ 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](/platform/triggers/scheduled-agents/) or the [Scheduled Agents quickstart](/platform/triggers/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](/platform/integrations/slack/) | 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](/platform/integrations/linear/) | Linear issue updates, Oz web app Runs page, Agent Management Panel in the Warp app, and the shared run session | -| GitHub | Someone should delegate work by mentioning `@oz-agent` on an issue, pull request, or review comment. | [GitHub integration](/platform/integrations/github/) | GitHub thread comments, 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](/platform/integrations/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](/reference/cli/#running-agents-remotely-oz-agent-run-cloud) | 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](/reference/api-and-sdk/) | Your system, API results, Oz web app, and run sessions | +| Scheduled agents | Work should run on a predictable cadence, like weekly triage, nightly dependency checks, or monthly cleanup. | [Scheduled Agents](/platform/triggers/scheduled-agents/) or the [Scheduled Agents quickstart](/platform/triggers/scheduled-agents-quickstart/) | {VARS.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](/platform/integrations/slack/) | Slack thread updates, {VARS.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](/platform/integrations/linear/) | Linear issue updates, {VARS.WEB_APP} Runs page, Agent Management Panel in the Warp app, and the shared run session | +| GitHub | Someone should delegate work by mentioning `@oz-agent` on an issue, pull request, or review comment. | [GitHub integration](/platform/integrations/github/) | GitHub thread comments, {VARS.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](/platform/integrations/github-actions/) | GitHub Actions logs, PR or issue comments, {VARS.WEB_APP}, and cloud agent runs | +| {VARS.WARP_AGENT_CLI} | You want to start a named cloud run from a terminal, script, or local automation. | [{VARS.WARP_AGENT_CLI}](/reference/cli/#running-agents-remotely-oz-agent-run-cloud) | CLI output, {VARS.WEB_APP} Runs page, Agent Management Panel in the Warp app, and cloud agent session links | +| {VARS.API_SDK_NAME} | Your internal system should create, query, or monitor runs programmatically. | [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) | Your system, API results, {VARS.WEB_APP}, and run sessions | ## Choose a workflow pattern @@ -81,7 +82,7 @@ The GitHub Action can pass event data, prior step output, and repository context ### Start runs from scripts or internal systems -Use the [Oz CLI](/reference/cli/#running-agents-remotely-oz-agent-run-cloud) for scripts and terminal workflows. Use the [Oz API and SDK](/reference/api-and-sdk/) when another service should create or monitor runs. This is useful for: +Use the [{VARS.WARP_AGENT_CLI}](/reference/cli/#running-agents-remotely-oz-agent-run-cloud) for scripts and terminal workflows. Use the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) when another service should create or monitor runs. This is useful for: * internal dashboards * custom webhooks @@ -108,10 +109,10 @@ If the agent can change code or infrastructure, keep the instructions narrow and Unattended does not mean invisible. Use these surfaces to review what happened: -* [Oz web app](/platform/oz-web-app/) - View runs, schedules, run metadata, and session transcripts from a browser or mobile device. +* [{VARS.WEB_APP}](/platform/oz-web-app/) - View runs, schedules, run metadata, and session transcripts from a browser or mobile device. * [Managing cloud agents](/platform/managing-cloud-agents/) - Filter runs by source, status, day, creator, or trigger. * [Cloud agent session sharing](/platform/viewing-cloud-agent-runs/) - Inspect the prompt, plan, commands, logs, output, and follow-up messages where available. -* [Oz API and SDK](/reference/api-and-sdk/) - Query runs and build internal monitoring around status, runtime, or outcomes. +* [{VARS.API_SDK_NAME}](/reference/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](/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs/) for a template. @@ -129,7 +130,7 @@ Start with one narrow workflow before deploying many unattended agents: ## Next steps -* [Scheduled Agents quickstart](/platform/triggers/scheduled-agents-quickstart/) - Create your first recurring agent in the Oz web app. +* [Scheduled Agents quickstart](/platform/triggers/scheduled-agents-quickstart/) - Create your first recurring agent in the {VARS.WEB_APP}. * [Integrations quickstart](/platform/integrations/quickstart/) - Trigger agents from Slack or Linear. * [GitHub integration](/platform/integrations/github/) - Set up `@oz-agent` mentions on issues and pull requests. * [GitHub Actions quickstart](/platform/integrations/quickstart-github-actions/) - Add an agent to a PR review workflow. diff --git a/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx b/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx index dd11c370..5fc431ac 100644 --- a/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx +++ b/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx @@ -1,7 +1,7 @@ --- title: Run a software factory in the cloud description: >- - Set up the Oz-native production path for your software factory with cloud + Set up the {{WARP_AUTOMATION_PLATFORM}}-native production path for your software factory with cloud environments, secrets, triggers, and audit trails. sidebar: label: "Run a software factory in the cloud" @@ -11,8 +11,9 @@ tags: - "software-factory" - "orchestration" --- +import { VARS } from '@data/vars'; -The GitHub Actions approach in [Set up your software factory](/guides/agent-workflows/set-up-a-software-factory) gets the four-agent loop working. This guide covers the Oz-native production setup for teams running the factory at scale: cloud environments, secrets and permissions, triggers, and observability. +The GitHub Actions approach in [Set up your software factory](/guides/agent-workflows/set-up-a-software-factory) gets the four-agent loop working. This guide covers the {VARS.WARP_AUTOMATION_PLATFORM}-native production setup for teams running the factory at scale: cloud environments, secrets and permissions, triggers, and observability. ## Prerequisites @@ -21,20 +22,20 @@ The GitHub Actions approach in [Set up your software factory](/guides/agent-work ## Why cloud agents, not cloud computers -A common approach to cloud-based agents is to spin up a persistent virtual machine, or "cloud computer", that the agent logs into and uses like a developer's laptop. Oz uses a different model where each agent run is a short-lived, scoped execution with its own environment and permissions, similar to a cloud function rather than a long-running server. +A common approach to cloud-based agents is to spin up a persistent virtual machine, or "cloud computer", that the agent logs into and uses like a developer's laptop. {VARS.WARP_AUTOMATION_PLATFORM} uses a different model where each agent run is a short-lived, scoped execution with its own environment and permissions, similar to a cloud function rather than a long-running server. The practical difference: * **Per-agent permissions** — Your triage agent only needs to read issues and post comments. Your implementation agent needs to push branches and open PRs. Each agent gets exactly the permissions it needs, not a single shared credential that everything uses. * **Audit trails** — Every cloud agent run is logged separately. You can see exactly what the triage agent did versus what the implementation agent did, when it ran, and what it produced. -* **Team visibility** — Any teammate can open a run in the Oz web app to inspect the session transcript, steer a stuck agent, or pick up where the agent left off. +* **Team visibility** — Any teammate can open a run in the {VARS.WEB_APP} to inspect the session transcript, steer a stuck agent, or pick up where the agent left off. * **Scale without contention** — Multiple triage runs can execute in parallel without fighting over a shared dev box, local git checkouts, or CPU. -See [Deployment patterns](/platform/deployment-patterns) for a full comparison of Oz-hosted, CLI-based, and self-hosted execution patterns. +See [Deployment patterns](/platform/deployment-patterns) for a full comparison of {VARS.WARP_AUTOMATION_PLATFORM}-hosted, CLI-based, and self-hosted execution patterns. ## 1. Set up a cloud environment -An Oz environment is a Docker-based sandbox with your repository, secrets, and any tools the agents need. If you don't already have one from the previous guides, create one now: run [`/create-environment`](warp://action/create_environment) in Warp and Oz detects your stack, suggests a Docker image, and creates the environment automatically. +A cloud environment is a Docker-based sandbox with your repository, secrets, and any tools the agents need. If you don't already have one from the previous guides, create one now: run [`/create-environment`](warp://action/create_environment) in Warp and {VARS.WARP_AUTOMATION_PLATFORM} detects your stack, suggests a Docker image, and creates the environment automatically. For repositories that need specific toolchains or dependencies, [`warpdotdev/oz-dev-environments`](https://github.com/warpdotdev/oz-dev-environments) has prebuilt Docker images for common stacks. @@ -61,37 +62,37 @@ Use fine-grained personal access tokens or separate GitHub App installations to ## 3. Configure triggers -With GitHub Actions, your factory already has event-based triggers. Oz also provides first-party integrations that handle triggering without GitHub Actions boilerplate: +With GitHub Actions, your factory already has event-based triggers. {VARS.WARP_AUTOMATION_PLATFORM} also provides first-party integrations that handle triggering without GitHub Actions boilerplate: * **Slack** — Teammates can kick off a run by mentioning `@warp` in a Slack thread. Useful for one-off requests that don't need the full label workflow. See [Slack integration](/platform/integrations/slack). * **Linear** — When an issue in Linear reaches a specific status, a cloud agent run starts automatically. Useful for teams that track work in Linear rather than GitHub Issues. See [Linear integration](/platform/integrations/linear). * **Scheduled agents** — For the outer improvement loop (which runs on a cadence rather than an event), use a scheduled cloud agent. See [Scheduled agents](/platform/triggers/scheduled-agents). -* **Oz API and SDK** — For custom triggers — webhooks, internal dashboards, other events — use the [Oz API and SDK](/reference/api-and-sdk) to start runs programmatically. +* **{VARS.API_SDK_NAME}** — For custom triggers — webhooks, internal dashboards, other events — use the [{VARS.API_SDK_NAME}](/reference/api-and-sdk) to start runs programmatically. ## 4. Monitor factory runs -Every cloud agent run in your factory appears in the Oz dashboard with: +Every cloud agent run in your factory appears in the {VARS.DASHBOARD} with: * A session transcript showing every action the agent took * Artifacts: PRs, branches, plans, and reports the agent produced * Status history: queued, in progress, succeeded, or failed with error details * A session sharing link any teammate can open to inspect or steer the run -Open runs from [oz.warp.dev](https://oz.warp.dev) or from the **Agent Management Panel** in the Warp app. Include the session link in PR descriptions so reviewers can see exactly how the agent built the change — see [Attach agent context to GitHub PRs](/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs). +Open runs from {VARS.WEB_APP_URL} or from the **Agent Management Panel** in the Warp app. Include the session link in PR descriptions so reviewers can see exactly how the agent built the change — see [Attach agent context to GitHub PRs](/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs). See [Viewing cloud agent runs](/platform/viewing-cloud-agent-runs) for the full reference. ## 5. Use multi-agent orchestration for large backlogs -When a sprint starts and you want to process many issues in parallel, Oz can fan out to child agents — one per issue — from a single parent run. The parent coordinates; the children execute in parallel, each with their own environment, prompt, and permissions. +When a sprint starts and you want to process many issues in parallel, {VARS.WARP_AUTOMATION_PLATFORM} can fan out to child agents — one per issue — from a single parent run. The parent coordinates; the children execute in parallel, each with their own environment, prompt, and permissions. See [Multi-agent orchestration](/platform/orchestration) for fan-out, sharding, and result aggregation patterns. ## Productivity tips * **Start with one agent role in the cloud** — Get the triage agent running as a cloud run before moving all four roles. Confirm that the environment, secrets, and permissions work correctly before expanding. -* **Add session links to PR descriptions** — When the implementation agent opens a PR, include the Oz run link so reviewers get the full context. See [Attach agent context to GitHub PRs](/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs) for a template. -* **Monitor credit usage** — Cloud agent runs consume credits. Monitor usage in the Oz web app and adjust run scope if needed. See [Credits](/support-and-community/plans-and-billing/credits). +* **Add session links to PR descriptions** — When the implementation agent opens a PR, include the {VARS.PLATFORM_RUN} link so reviewers get the full context. See [Attach agent context to GitHub PRs](/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs) for a template. +* **Monitor credit usage** — Cloud agent runs consume credits. Monitor usage in the {VARS.WEB_APP} and adjust run scope if needed. See [Credits](/support-and-community/plans-and-billing/credits). ## Next steps diff --git a/src/content/docs/guides/agent-workflows/set-up-a-software-factory.mdx b/src/content/docs/guides/agent-workflows/set-up-a-software-factory.mdx index 37e9c284..9abf9700 100644 --- a/src/content/docs/guides/agent-workflows/set-up-a-software-factory.mdx +++ b/src/content/docs/guides/agent-workflows/set-up-a-software-factory.mdx @@ -9,13 +9,14 @@ tags: - "software-factory" - "cloud-agents" --- +import { VARS } from '@data/vars'; This guide adds the implementation and reviewer agents to the [triage](/guides/agent-workflows/build-a-triage-agent) and [spec](/guides/agent-workflows/write-product-and-tech-specs-with-agents) agents you set up previously, then connects all four into a software factory using GitHub labels as the state machine. Issues flow automatically from triage to a reviewable pull request. ## Prerequisites * A working [triage agent](/guides/agent-workflows/build-a-triage-agent) and [spec agent](/guides/agent-workflows/write-product-and-tech-specs-with-agents), each deployed individually -* An Oz cloud environment with access to your repository ([create one](/platform/environments)) +* A cloud environment with access to your repository ([create one](/platform/environments)) * `warpdotdev/oz-agent-action` installed (see [GitHub Actions integration](/platform/integrations/github-actions)) ## How the loop works @@ -157,12 +158,12 @@ The reviewer agent surfaces issues and inconsistencies; the human makes the fina * **Validate before the reviewer runs** — After the implementation agent opens a PR, run `/validate-changes-match-specs` to check the diff against `PRODUCT.md` and `TECH.md`. This catches any misalignments before the reviewer agent posts comments. The skill is available from [`warpdotdev/common-skills`](https://github.com/warpdotdev/common-skills). * **Start with triage only** — Get your triage agent running well before adding spec and implementation. A groomed, labeled backlog is immediately useful to every developer on the team. * **Use `@oz-agent` for one-off requests** — Teammates can mention `@oz-agent` in an issue comment to kick off an agent run directly, bypassing the label workflow for urgent requests. -* **Monitor runs in the Oz web app** — Every cloud agent run appears in the [Oz web app](https://oz.warp.dev) with a session link. Use it to inspect what each agent did, steer a stuck run, or hand work back to a local session. +* **Monitor runs in the {VARS.WEB_APP}** — Every cloud agent run appears in the {VARS.WEB_APP} with a session link. Use it to inspect what each agent did, steer a stuck run, or hand work back to a local session. ## Next steps * [What is a software factory?](/platform/software-factory) — The conceptual overview of the full loop. -* [Run a software factory in the cloud](/guides/agent-workflows/run-a-software-factory-in-the-cloud) — Move the loop into a managed Oz deployment. +* [Run a software factory in the cloud](/guides/agent-workflows/run-a-software-factory-in-the-cloud) — Move the loop into a managed {VARS.WARP_AUTOMATION_PLATFORM} deployment. * [Build a self-improving agent](/guides/agent-workflows/build-a-self-improving-agent) — Add the outer improvement loop. * [Review AI-generated code](/guides/agent-workflows/how-to-review-ai-generated-code) — The human review workflow for agent-generated PRs. * [`warpdotdev/oz-for-oss`](https://github.com/warpdotdev/oz-for-oss) — The complete reference implementation. diff --git a/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx b/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx index ed8f5e13..45f25ec0 100644 --- a/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx +++ b/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx @@ -8,6 +8,7 @@ tags: - "agents" - "software-factory" --- +import { VARS } from '@data/vars'; Once your [triage agent](/guides/agent-workflows/build-a-triage-agent) is labeling issues as `ready-to-spec`, use agents to turn those issues into two spec files: a product spec that describes what the feature should do from the user's perspective, and a tech spec that describes how to implement it. @@ -75,4 +76,4 @@ A tech spec defines how the feature will be implemented, including architecture * [Set up your software factory](/guides/agent-workflows/set-up-a-software-factory) — Connect the spec role to implementation and review. * [`warpdotdev/common-skills`](https://github.com/warpdotdev/common-skills) — The full set of shared skills including `write-product-spec`, `write-tech-spec`, and `validate-changes-match-specs`. * [Planning](/agents/capabilities/planning) — Warp's built-in planning feature for smaller tasks. -* [Skills](/agents/capabilities/skills) — How skill files work in Warp and Oz. +* [Skills](/agents/capabilities/skills) — How skill files work in Warp and {VARS.WARP_AUTOMATION_PLATFORM}. diff --git a/src/content/docs/guides/configuration/how-to-set-up-self-serve-data-analytics-with-skills.mdx b/src/content/docs/guides/configuration/how-to-set-up-self-serve-data-analytics-with-skills.mdx index f81d51a5..b2a3f65a 100644 --- a/src/content/docs/guides/configuration/how-to-set-up-self-serve-data-analytics-with-skills.mdx +++ b/src/content/docs/guides/configuration/how-to-set-up-self-serve-data-analytics-with-skills.mdx @@ -10,6 +10,7 @@ tags: --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; Self-serve data analytics means anyone on your team can ask a data question and get a trustworthy answer, without pinging the data team. This guide sets up that workflow using two community Skills that chain together: one resolves vague questions to the right BigQuery tables, and the other structures deep-dive analyses into reproducible folders. Plan on about 10 minutes for initial setup, plus time to customize the model index for your warehouse. @@ -179,7 +180,7 @@ The `analysis-artifacts` Skill is largely stack-agnostic. It structures outputs, You installed two community Skills, customized the model index for your warehouse, and ran both a simple lookup and a full deep-dive analysis. -**Extend to Slack.** Wire the same two Skills into a cloud agent configured with your dbt repo, and your teammates can ask data questions by @-mentioning Oz in a Slack channel, without opening a terminal. The agent clones the repo, picks up the Skills from `.agents/skills/`, and replies in-thread. See the [Slack integration docs](https://docs.warp.dev/platform/integrations/slack/) and [Skills as Agents](https://docs.warp.dev/platform/skills-as-agents/) for setup. +**Extend to Slack.** Wire the same two Skills into a cloud agent configured with your dbt repo, and your teammates can ask data questions by @-mentioning {VARS.WARP_AUTOMATION_PLATFORM} in a Slack channel, without opening a terminal. The agent clones the repo, picks up the Skills from `.agents/skills/`, and replies in-thread. See the [Slack integration docs](https://docs.warp.dev/platform/integrations/slack/) and [Skills as Agents](https://docs.warp.dev/platform/skills-as-agents/) for setup. Explore related guides and features: diff --git a/src/content/docs/guides/external-tools/using-mcp-servers-with-warp.mdx b/src/content/docs/guides/external-tools/using-mcp-servers-with-warp.mdx index 554c71d1..51a774f9 100644 --- a/src/content/docs/guides/external-tools/using-mcp-servers-with-warp.mdx +++ b/src/content/docs/guides/external-tools/using-mcp-servers-with-warp.mdx @@ -10,6 +10,7 @@ tags: featured: true --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; @@ -18,7 +19,7 @@ MCP servers let Warp agents use external tools and data sources through a standa Warp supports MCP in two places: * **Local agents in the Warp app** use MCP servers configured in **Settings** > **Agents** > **MCP servers**, Warp Drive, or file-based config. -* **Cloud agents** use MCP servers passed through the Oz CLI, agent config files, or Warp-shared MCP server UUIDs. +* **Cloud agents** use MCP servers passed through the {VARS.WARP_AGENT_CLI}, agent config files, or Warp-shared MCP server UUIDs. Use this guide to choose the right setup path, then jump to the source docs for exact configuration syntax. @@ -56,8 +57,8 @@ Example workflow: 1. Create or identify the MCP server the cloud agent should use. 2. Store required credentials as [Agent Secrets](/platform/secrets/) instead of hardcoding tokens in config files. 3. Attach the MCP server with `--mcp`, a config file, or a Warp-shared MCP UUID. -4. Run the cloud agent from the Oz CLI, Slack, Linear, GitHub Actions, a schedule, or the API. -5. Inspect the run in the [Oz web app](/platform/oz-web-app/) or [Cloud agent session sharing](/platform/viewing-cloud-agent-runs/). +4. Run the cloud agent from the {VARS.WARP_AGENT_CLI}, Slack, Linear, GitHub Actions, a schedule, or the API. +5. Inspect the run in the [{VARS.WEB_APP}](/platform/oz-web-app/) or [Cloud agent session sharing](/platform/viewing-cloud-agent-runs/). For schema and cloud-specific limitations, see [MCP Servers for cloud agents](/platform/mcp/). @@ -67,7 +68,7 @@ Use shared MCP servers when multiple teammates or workflows need the same tool c For local agents, share the server from the MCP settings page. Warp scrubs sensitive environment values and prompts teammates to provide their own values when they install it. -For cloud agents, reference a Warp-shared MCP server by UUID with the Oz CLI: +For cloud agents, reference a Warp-shared MCP server by UUID with the {VARS.WARP_AGENT_CLI}: ```sh oz mcp list diff --git a/src/content/docs/index.mdx b/src/content/docs/index.mdx index c1afe116..6b407570 100644 --- a/src/content/docs/index.mdx +++ b/src/content/docs/index.mdx @@ -1,14 +1,15 @@ --- -title: Getting started with Warp and Oz +title: Getting started with Warp and {{WARP_AUTOMATION_PLATFORM}} description: >- - Get started with Warp, the Agentic Development Environment, and Oz, the - orchestration platform for cloud agents. + Get started with Warp, the Agentic Development Environment, and {{WARP_AUTOMATION_PLATFORM}}, + which orchestrates cloud agents at scale. sidebar: - label: Getting started with Warp and Oz + label: Getting started with Warp and {{WARP_AUTOMATION_PLATFORM}} --- +import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; -Warp is an [open source](https://github.com/warpdotdev/warp) **Agentic Development Environment** that combines a modern, high-performance terminal with powerful agents to help you build, test, deploy, and debug code. Agents in Warp are powered by **Oz**, the orchestration platform for running agents locally or in the cloud at scale. +Warp is an [open source](https://github.com/warpdotdev/warp) **Agentic Development Environment** that combines a modern, high-performance terminal with powerful agents to help you build, test, deploy, and debug code. Agents in Warp are powered by **{VARS.WARP_AUTOMATION_PLATFORM}**, which orchestrates agents locally or in the cloud at scale.
![Warp, the Agentic Development Environment: Warp (a modern terminal built for coding with agents) and Oz (the orchestration platform for cloud agents)](../../assets/terminal/warp-oz-welcome.png) @@ -70,15 +71,15 @@ Cloud agents are ideal for work that doesn't need your immediate attention, like ### The platform behind them -**Oz** is Warp's programmable platform for running and coordinating agents at scale. It provides the environments, triggers, integrations, orchestration, and observability that cloud agents run on, plus a CLI, API, and SDK. +**{VARS.WARP_AUTOMATION_PLATFORM}** is Warp's programmable system for running and coordinating agents at scale. It provides the environments, triggers, integrations, orchestration, and observability that cloud agents run on, plus a CLI, API, and SDK. -→ [Learn about the Oz platform](/platform/overview/) +→ [Learn about the {VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) --- ## How they work together -Warp and Oz provide a unified experience across local and cloud development: +Warp and {VARS.WARP_AUTOMATION_PLATFORM} provide a unified experience across local and cloud development: * **Same agent, anywhere**: Whether you're working in the Warp app, in another terminal through the Warp Agent CLI, or running agents in the cloud, you're using the same underlying agent capabilities. * **Seamless handoff**: Start a task in the cloud and take over locally in Warp when you want hands-on control, without losing progress or context. @@ -89,13 +90,13 @@ Warp and Oz provide a unified experience across local and cloud development: ## Multi-model support -Oz is multi-model by design. You can [choose your preferred LLM](/agents/inference/model-choice/) from a curated set of top models. +{VARS.WARP_AUTOMATION_PLATFORM} is multi-model by design. You can [choose your preferred LLM](/agents/inference/model-choice/) from a curated set of top models. --- ## Open source -Warp's client is open source under [AGPL v3](https://github.com/warpdotdev/warp/blob/master/LICENSE-AGPL). The source lives at [`warpdotdev/warp`](https://github.com/warpdotdev/warp), where you can read the code, file issues, and contribute alongside the Warp team. Development happens in the open with an agent-first workflow managed by Oz. +Warp's client is open source under [AGPL v3](https://github.com/warpdotdev/warp/blob/master/LICENSE-AGPL). The source lives at [`warpdotdev/warp`](https://github.com/warpdotdev/warp), where you can read the code, file issues, and contribute alongside the Warp team. Development happens in the open with an agent-first workflow managed by {VARS.WARP_AUTOMATION_PLATFORM}. → [Contributing to Warp](/support-and-community/community/contributing/) explains how to file issues, claim work, and ship code or themes. @@ -117,4 +118,4 @@ Warp's AI features can be globally disabled in **Settings** > **Agents** > **War * [**Using the Warp Agent**](/agents/local-agents/overview/): Explore all AI features available in Warp * [**Warp Agent CLI**](/agents/cli/): Run the Warp Agent in any terminal * [**Cloud Agents overview**](/platform/): Set up background automation -* [**Oz Platform**](/platform/overview/): Learn about the CLI, API, SDK, and infrastructure +* [**{VARS.WARP_AUTOMATION_PLATFORM}**](/platform/overview/): Learn about the CLI, API, SDK, and infrastructure diff --git a/src/content/docs/platform/agents.mdx b/src/content/docs/platform/agents.mdx index 2dbad407..c6d353ef 100644 --- a/src/content/docs/platform/agents.mdx +++ b/src/content/docs/platform/agents.mdx @@ -6,10 +6,11 @@ description: >- sidebar: label: "Agents" --- +import { VARS } from '@data/vars'; A **cloud agent** is an agent that runs in Warp's cloud (or on a self-hosted worker) instead of on your local machine. Use a cloud agent when you want to give an automation its own settings, secrets, skills, and permissions instead of having it act as a user on your team. -Every team starts with a default cloud agent, which is what runs when an automation triggers a task with no other configuration. You can optionally create additional cloud agents through the Oz web app's **Agents** page or the public API. See [Managing cloud agents](#managing-cloud-agents) below. +Every team starts with a default cloud agent, which is what runs when an automation triggers a task with no other configuration. You can optionally create additional cloud agents through the {VARS.WEB_APP}'s **Agents** page or the public API. See [Managing cloud agents](#managing-cloud-agents) below. ## How cloud agents get triggered @@ -17,10 +18,10 @@ A run executes as a cloud agent when it's authenticated with an [agent API key]( * **Schedules** — Cron-style recurring runs. See [Scheduled agents](/platform/triggers/scheduled-agents/). * **Integrations** — Slack mentions, Linear issue updates, GitHub Actions workflow steps. See [Integrations](/platform/integrations/). -* **API and SDK** — Programmatic runs from your own backend, scripts, or webhooks via the [Oz API](/reference/api-and-sdk/). -* **CLI** — `oz agent run-cloud` from a developer machine, CI pipeline, or self-hosted worker. See the [Oz CLI](/reference/cli/). +* **API and SDK** — Programmatic runs from your own backend, scripts, or webhooks via the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/). +* **CLI** — `oz agent run-cloud` from a developer machine, CI pipeline, or self-hosted worker. See the [{VARS.WARP_AGENT_CLI}](/reference/cli/). -Each run is tracked in the [Oz dashboard](https://oz.warp.dev/runs) with its trigger source, the environment it ran in, and the full transcript. +Each run is tracked in the {VARS.DASHBOARD} with its trigger source, the environment it ran in, and the full transcript. ## Agent API keys @@ -32,7 +33,7 @@ In the CLI and REST API, a cloud agent is represented as a **service account**. ## Managing cloud agents -Use the [Oz web app's Agents page](/platform/oz-web-app/#agents) for day-to-day management. Use the public API when you need to create or update agents from scripts, CI/CD, or internal tooling. Full request and response formats, including error codes, live on the [API Reference](/api) page under the **agent** tag. +Use the [{VARS.WEB_APP}'s Agents page](/platform/oz-web-app/#agents) for day-to-day management. Use the public API when you need to create or update agents from scripts, CI/CD, or internal tooling. Full request and response formats, including error codes, live on the [API Reference](/api) page under the **agent** tag. | Action | Endpoint | What it does | | --- | --- | --- | @@ -56,18 +57,26 @@ When a team is over its plan limit (for example, after downgrading), the extra a ## Where cloud agents appear in the product -* **Agents page** - The Agents page in the [Oz web app](/platform/oz-web-app/) is where teams view, create, edit, and delete cloud agents. +* **Agents page** - The Agents page in the [{VARS.WEB_APP}](/platform/oz-web-app/) is where teams view, create, edit, and delete cloud agents. * **Agent picker** - Forms that start a new run or schedule include an **Agent** dropdown. **Quick run** is the default: runs execute as the calling user, and pull requests are authored by that person. Picking a cloud agent runs as that agent instead, so with [team GitHub authorization](/platform/team-access-billing-and-identity/#team-github-authorization) configured, pull requests are authored by the **Oz by Warp** GitHub App. Choose a cloud agent for any schedule that opens pull requests. See [Run identity and pull request authorship](/platform/triggers/scheduled-agents-quickstart/#run-identity-and-pull-request-authorship). * **Run filters and detail** - The Runs view lets you filter by cloud agent, and individual run detail pages show which agent executed the run. * **Admin Panel** - Billing usage in the [Admin Panel](/knowledge-and-collaboration/admin-panel/) attributes credits consumed by cloud agent runs to the team rather than to a person. +## Capabilities + +Cloud agents — and individual runs — can also be granted specific capabilities: + +* [**Skills as agents**](/platform/skills-as-agents/) - Attach a skill directly to a cloud agent identity, or pass one at run time, so the agent starts from a reusable, version-controlled prompt instead of an ad hoc one. +* [**MCP servers**](/platform/mcp/) - Connect a run to external tools and services (GitHub, dbt, Sentry, or a custom internal service) via Model Context Protocol. +* [**Secrets**](/platform/secrets/) - Store and inject credentials into cloud agent runs without exposing secret values, scoped to a team, a person, or a specific cloud agent identity. + ## Related pages * [Triggers](/platform/triggers/) - How schedules, integrations, and API calls invoke cloud agents. * [Environments](/platform/environments/) - The runtime context (Docker image, repos, setup commands) a cloud agent uses. * [Multi-agent orchestration](/platform/orchestration/) - Coordinate a parent cloud agent and its children across local and cloud runs. * [API keys](/reference/cli/api-keys/) - Create personal and agent API keys. -* [Oz API & SDK](/reference/api-and-sdk/) - Programmatic access to the cloud agent endpoints. +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) - Programmatic access to the cloud agent endpoints. * [Federated identity tokens](/reference/cli/federate/) - Issue OIDC tokens from inside a run. -* [Oz web app](/platform/oz-web-app/) - Manage cloud agents and inspect their runs in the web UI. +* [{VARS.WEB_APP}](/platform/oz-web-app/) - Manage cloud agents and inspect their runs in the web UI. * [Admin Panel](/knowledge-and-collaboration/admin-panel/) - Team-level billing and access controls. diff --git a/src/content/docs/platform/deployment-patterns.mdx b/src/content/docs/platform/deployment-patterns.mdx index f8dfc36e..b96b04fd 100644 --- a/src/content/docs/platform/deployment-patterns.mdx +++ b/src/content/docs/platform/deployment-patterns.mdx @@ -2,7 +2,7 @@ title: Deployment patterns description: >- Common architectures for deploying cloud agents, including CLI-only, - Oz-hosted, and self-hosted execution patterns. + {{WARP_AUTOMATION_PLATFORM}}-hosted, and self-hosted execution patterns. sidebar: label: "Deployment patterns" --- @@ -15,9 +15,9 @@ Teams adopt cloud agents in a few repeatable ways. This page outlines the most c Cloud agent setups usually have four moving parts: 1. **Trigger**: something happens (CI step, webhook, cron, Slack mention). -2. **Orchestration**: something decides what to run and tracks it (Oz orchestrator, GitHub Actions, your internal system). -3. **Execution**: where the agent actually runs (your runner, Oz-hosted environment, or self-hosted workers). -4. **Visibility**: how the team monitors and intervenes (Oz dashboard, session sharing, APIs). +2. **Orchestration**: something decides what to run and tracks it ({VARS.WARP_AUTOMATION_PLATFORM} orchestrator, GitHub Actions, your internal system). +3. **Execution**: where the agent actually runs (your runner, {VARS.WARP_AUTOMATION_PLATFORM}-hosted environment, or self-hosted workers). +4. **Visibility**: how the team monitors and intervenes ({VARS.DASHBOARD}, session sharing, APIs). --- @@ -55,23 +55,23 @@ Use this when you already have a system that schedules work (CI, dev boxes, inte * A Warp team * A [cloud agent](/platform/agents/) (recommended for automation) -* The Oz CLI installed on the runner / box +* The {VARS.WARP_AGENT_CLI} installed on the runner / box * Any needed credentials (often via secrets + environment variables) --- -### Pattern 2: Oz-hosted agents + Oz orchestration (managed cloud execution) +### Pattern 2: Warp-hosted agents and orchestration (managed cloud execution) -Use this when you want Oz to run agent workloads on Warp-managed infrastructure, typically inside reproducible Docker environments, with built-in lifecycle management. +Use this when you want {VARS.WARP_AUTOMATION_PLATFORM} to run agent workloads on Warp-managed infrastructure, typically inside reproducible Docker environments, with built-in lifecycle management. ![Warp enterprise SaaS architecture showing customer infrastructure, isolated tenant sandboxes, Warp backend, and LLM providers](../../../assets/agent-platform/cloud-agents-infra.png) #### What it looks like * **Trigger**: first-party integrations, cron schedules, API/SDK calls, or on-demand commands -* **Orchestration**: Oz orchestrator -* **Execution**: Oz-hosted environments (Docker-based) -* **Visibility**: Oz dashboard + session sharing + APIs/SDKs +* **Orchestration**: {VARS.WARP_AUTOMATION_PLATFORM} orchestrator +* **Execution**: {VARS.WARP_AUTOMATION_PLATFORM}-hosted environments (Docker-based) +* **Visibility**: {VARS.DASHBOARD} + session sharing + APIs/SDKs #### Why teams choose it @@ -88,16 +88,16 @@ Use this when you want Oz to run agent workloads on Warp-managed infrastructure, #### Example recipe: daily dead-code cleanup -1. Define an Oz [Environment](/platform/environments/) with the repo + toolchain. +1. Define a Warp [Environment](/platform/environments/) with the repo + toolchain. 2. Create a [schedule](/platform/triggers/scheduled-agents/) with a fixed prompt for cleanup. -3. Oz runs the agent on the cadence. +3. {VARS.WARP_AUTOMATION_PLATFORM} runs the agent on the cadence. 4. Your team monitors runs in the [{VARS.WEB_APP}](/platform/oz-web-app/) and [viewing cloud agent runs](/platform/viewing-cloud-agent-runs/), reviews artifacts (PRs, plans), and intervenes when needed. #### Example recipe: crash triage via Sentry webhook -1. Define an Oz Environment with the target repo. +1. Define a Warp Environment with the target repo. 2. Register a Sentry webhook to your handler (server, cloud function, Zapier/n8n). -3. Handler extracts crash details, constructs a prompt, and calls the Oz orchestrator API/SDK to start a task. +3. Handler extracts crash details, constructs a prompt, and calls the {VARS.WARP_AUTOMATION_PLATFORM} orchestrator API/SDK to start a task. 4. Warp spins up the run in the environment and you monitor progress via UI/API. #### Example recipe: fan-out parallel work (sharding) @@ -113,7 +113,7 @@ When a task is naturally divisible, use [multi-agent orchestration](/platform/or ### Pattern 3: Self-hosted execution -Use this when you need to control where agent execution happens while still using Oz orchestration and visibility. Repositories are cloned and stored only on your infrastructure; orchestration metadata, session transcripts, and LLM inference route through Warp's backend under [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr). +Use this when you need to control where agent execution happens while still using {VARS.WARP_AUTOMATION_PLATFORM} orchestration and visibility. Repositories are cloned and stored only on your infrastructure; orchestration metadata, session transcripts, and LLM inference route through Warp's backend under [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr). Think of self-hosted execution as **customer-hosted execution with Warp-hosted orchestration**, not as a fully offline agent stack. Code repositories, build artifacts, runtime secrets, and execution workspaces stay on your infrastructure. Code context can still appear in session transcripts and LLM prompts as the agent works. @@ -123,7 +123,7 @@ Think of self-hosted execution as **customer-hosted execution with Warp-hosted o Self-hosting has two architectures that differ on **who orchestrates agent runs** (both keep code and execution on your infrastructure): -* **[Managed](/platform/self-hosting/#managed-architecture)** — Oz orchestrates. You run the `oz-agent-worker` daemon; Oz routes runs to it from Slack, Linear, schedules, the API, or `oz agent run-cloud`. Tasks execute in Docker containers, Kubernetes Jobs, or directly on the host. +* **[Managed](/platform/self-hosting/#managed-architecture)** — {VARS.WARP_AUTOMATION_PLATFORM} orchestrates. You run the `oz-agent-worker` daemon; {VARS.WARP_AUTOMATION_PLATFORM} routes runs to it from Slack, Linear, schedules, the API, or `oz agent run-cloud`. Tasks execute in Docker containers, Kubernetes Jobs, or directly on the host. * **[Unmanaged](/platform/self-hosting/unmanaged/)** — You orchestrate. Invoke `oz agent run` directly from your CI, Kubernetes, or dev environment. Warp provides session tracking and observability; it does not start or stop agents. Why teams choose self-hosted execution: diff --git a/src/content/docs/platform/environments.mdx b/src/content/docs/platform/environments.mdx index 3c1bfb65..a3df9570 100644 --- a/src/content/docs/platform/environments.mdx +++ b/src/content/docs/platform/environments.mdx @@ -6,6 +6,7 @@ description: >- Environments ensure your cloud agents run with consistent toolchains across all triggers. Learn when to use environments and how to configure them. --- +import { VARS } from '@data/vars'; Environments ensure your [cloud agents](/platform/) run with the same toolchain and setup every time, regardless of where they're triggered from. @@ -29,7 +30,7 @@ Don't want to bring your own image? Warp provides [prebuilt dev images](https:// ## About environments -Environments define _how_ an agent runs, not _what_ it does. They're required for [Oz Platform](/platform/overview/) automation (cloud agents, integrations, API runs) but are not required for interactive local usage. +Environments define _how_ an agent runs, not _what_ it does. They're required for [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) automation (cloud agents, integrations, API runs) but are not required for interactive local usage. An environment typically includes: @@ -54,9 +55,9 @@ What an environment is not: * [MCP Servers](/platform/mcp/) – connect agents to external tools and data via MCP. * Per-run context – Trigger-specific data like Slack threads, PR metadata, or CI logs attach to individual tasks, not the environment configuration. -## How environments fit into the Oz Platform +## How environments fit into cloud agent runs -An environment is the runtime layer for automated Oz Platform runs. It defines the container image, repos, and setup steps used when a trigger kicks off an agent task. +An environment is the runtime layer for automated {VARS.WARP_AUTOMATION_PLATFORM} runs. It defines the container image, repos, and setup steps used when a trigger kicks off an agent task. Components in the execution flow: @@ -122,13 +123,13 @@ Choose an environment if any of the following apply: **Example:** -If your team tags @Oz in Slack to fix a failing CI job, an environment ensures every run uses the same Docker image, clones the same repos, and runs the same setup commands. +If your team tags @{VARS.WARP_AUTOMATION_PLATFORM} in Slack to fix a failing CI job, an environment ensures every run uses the same Docker image, clones the same repos, and runs the same setup commands. The fix the agent applies matches what runs in CI and what your teammates see when they review the PR. ### Where to configure environments -You can create environments in three ways: from the Oz web app, using the guided setup in Warp, or through the CLI. +You can create environments in three ways: from the {VARS.WEB_APP}, using the guided setup in Warp, or through the CLI. **Before you begin** @@ -146,15 +147,15 @@ Musl-based Docker images (such as Alpine Linux) are not supported. The agent run Create one environment per codebase, then reuse it across triggers like Slack, Linear, and CLI runs. ::: -### Create an environment from the Oz web app +### Create an environment from the web app
![Creating a new environment in the Oz Web App.](../../../assets/agent-platform/oz-web-app-new-environment.png)
The Create environment panel in the Oz web app.
-1. Open the [Environments page in the Oz web app](https://oz.warp.dev/environments) and click **New environment**. -2. Enter a name, select one or more repositories, and enter a **Docker image reference**. Click **Suggest** to have Oz recommend an image based on your repos, or start from one of [Warp's prebuilt dev images](https://github.com/warpdotdev/oz-dev-environments). +1. Open the Environments page in the {VARS.WEB_APP} and click **New environment**. +2. Enter a name, select one or more repositories, and enter a **Docker image reference**. Click **Suggest** to have {VARS.WARP_AUTOMATION_PLATFORM} recommend an image based on your repos, or start from one of [Warp's prebuilt dev images](https://github.com/warpdotdev/oz-dev-environments). 3. Optionally, add setup commands, configure cloud provider access (AWS or GCP), or add a description. 4. Click **Create environment**. @@ -216,7 +217,7 @@ Key flags: ## Managing environments -Once created, you can use the [Oz CLI](/reference/cli/) to inspect and update environments. +Once created, you can use the [{VARS.WARP_AGENT_CLI}](/reference/cli/) to inspect and update environments. **List environments** diff --git a/src/content/docs/platform/handoff/cloud-to-cloud.mdx b/src/content/docs/platform/handoff/cloud-to-cloud.mdx index cad8ff25..c1b41171 100644 --- a/src/content/docs/platform/handoff/cloud-to-cloud.mdx +++ b/src/content/docs/platform/handoff/cloud-to-cloud.mdx @@ -7,6 +7,7 @@ sidebar: label: "Cloud to cloud" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; Cloud-to-cloud handoff in Warp lets you send follow-up instructions to a finished cloud agent run and continue it in a fresh cloud session. The run keeps the same conversation and restores the prior workspace state, so the agent can pick up where it left off instead of starting over. @@ -17,7 +18,7 @@ Watch this walkthrough to see how cloud-to-cloud handoff continues a cloud agent Use this handoff direction when: * You want to send a follow-up to a cloud agent after its session has ended. -* You want to continue a background cloud agent run, such as a scheduled or integration-triggered run, while preserving it as a single unit of work in the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app and the [Runs page in the Oz web app](/platform/oz-web-app/#runs). +* You want to continue a background cloud agent run, such as a scheduled or integration-triggered run, while preserving it as a single unit of work in the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app and the [Runs page in the {VARS.WEB_APP}](/platform/oz-web-app/#runs). ## What carries over @@ -43,7 +44,7 @@ Cloud-to-cloud handoff relies on a snapshot from the prior session. Older cloud To continue an ended cloud run, open the run in Warp and send the next message in the conversation. When the original session has ended, Warp automatically starts a fresh cloud session and restores the prior workspace state. -1. **Open the ended cloud run.** Find it on the [Runs page](https://oz.warp.dev/runs) in the Oz web app or in the conversation panel in the Warp app. +1. **Open the ended cloud run.** Find it on the Runs page in the {VARS.WEB_APP} or in the conversation panel in the Warp app. 2. **Send your follow-up.** Enter the next message in the conversation's input and submit it. The run picks up where it left off, with workspace state restored. @@ -58,9 +59,9 @@ Cloud-to-cloud handoff also works for supported third-party agent runtimes, but ## Inspecting a run that's been handed off -The [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app and the [Runs page in the Oz web app](/platform/oz-web-app/#runs) show one row per run, even when the run spans multiple sessions. +The [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app and the [Runs page in the {VARS.WEB_APP}](/platform/oz-web-app/#runs) show one row per run, even when the run spans multiple sessions. -1. Open the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app or the [Runs page in the Oz web app](/platform/oz-web-app/#runs). +1. Open the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app or the [Runs page in the {VARS.WEB_APP}](/platform/oz-web-app/#runs). 2. Select the handed-off run. 3. Review the transcript. Each session appears in order, so you can see where one session ended and the next began. diff --git a/src/content/docs/platform/handoff/index.mdx b/src/content/docs/platform/handoff/index.mdx index 39bfa779..79aa37c3 100644 --- a/src/content/docs/platform/handoff/index.mdx +++ b/src/content/docs/platform/handoff/index.mdx @@ -6,6 +6,7 @@ description: >- sidebar: label: "Handoff overview" --- +import { VARS } from '@data/vars'; Handoff moves agent work between local Warp sessions and cloud agent runs without making you restart the task. Depending on the direction, Warp carries over conversation history, workspace changes, and attachments so the receiving agent can continue from the prior session instead of starting from scratch. @@ -26,7 +27,7 @@ Handoff supports three directions: Handoff coverage depends on which agent is running the conversation: -* **Cloud to cloud** works for the Warp Agent and the [third-party cloud harnesses currently supported in Oz](/platform/harnesses/): Claude Code and Codex. For Claude Code and Codex runs, click **Continue**, then enter your follow-up prompt. Warp Agent runs use the streamlined follow-up input. +* **Cloud to cloud** works for the Warp Agent and the [third-party cloud harnesses currently supported in {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/): Claude Code and Codex. For Claude Code and Codex runs, click **Continue**, then enter your follow-up prompt. Warp Agent runs use the streamlined follow-up input. * **Local to cloud** works for the Warp Agent. It isn't available for third-party CLI agent sessions. ## What carries over @@ -49,8 +50,8 @@ Each direction has a clear motivating workflow. ## Related pages -* [Cloud agents overview](/platform/) - What cloud agents are, when to use them, and how they fit into the Oz Platform. -* [Managing cloud agents](/platform/managing-cloud-agents/) - Inspect handoff runs from the Agent Management Panel in the Warp app or the Runs page in the Oz web app alongside local conversations. +* [Cloud agents overview](/platform/) - What cloud agents are, when to use them, and how they fit into the {VARS.WARP_AUTOMATION_PLATFORM}. +* [Managing cloud agents](/platform/managing-cloud-agents/) - Inspect handoff runs from the Agent Management Panel in the Warp app or the Runs page in the {VARS.WEB_APP} alongside local conversations. * [Viewing cloud agent runs](/platform/viewing-cloud-agent-runs/) - Open and continue a cloud run locally with **Continue locally** or `/continue-locally`. * [Cloud-synced conversations](/agents/local-agents/cloud-conversations/) - How conversations sync between local and cloud so handoff can find them. * [Environments](/platform/environments/) - The runtime context a cloud agent runs in after a handoff. diff --git a/src/content/docs/platform/handoff/local-to-cloud.mdx b/src/content/docs/platform/handoff/local-to-cloud.mdx index 5a7c87cf..960fa81a 100644 --- a/src/content/docs/platform/handoff/local-to-cloud.mdx +++ b/src/content/docs/platform/handoff/local-to-cloud.mdx @@ -7,6 +7,7 @@ sidebar: label: "Local to cloud" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; Local-to-cloud handoff in Warp promotes an active local Warp Agent conversation into a cloud agent run. Warp forks the conversation, snapshots your uncommitted workspace changes, and sends both to the cloud so the agent can continue the same task with the context and files it needs. @@ -74,7 +75,7 @@ The cloud agent runs with the same model your local conversation was using. Chan After you submit, the cloud agent applies your workspace snapshot and responds to your follow-up. The local conversation is not modified, so you can keep working in it locally or close it. -To check on the new run, open it from the [Runs page](https://oz.warp.dev/runs) in the Oz web app or the conversation panel in the Warp app. +To check on the new run, open it from the Runs page in the {VARS.WEB_APP} or the conversation panel in the Warp app. ## Troubleshooting diff --git a/src/content/docs/platform/handoff/snapshots.mdx b/src/content/docs/platform/handoff/snapshots.mdx index 4f3542c0..5f660000 100644 --- a/src/content/docs/platform/handoff/snapshots.mdx +++ b/src/content/docs/platform/handoff/snapshots.mdx @@ -7,6 +7,7 @@ description: >- sidebar: label: "Snapshots" --- +import { VARS } from '@data/vars'; Workspace snapshots are how [handoff](/platform/handoff/) carries repository changes and other workspace state across cloud agent runs. At the end of every cloud agent run, Warp asks a small declarations script which repositories and files to snapshot, then uploads the resulting git diffs and file contents so the next cloud agent run can apply them. @@ -230,4 +231,4 @@ Snapshotting is also skipped automatically when cloud conversations are disabled * [Handoff from cloud to cloud](/platform/handoff/cloud-to-cloud/) - Continue a finished cloud run; the prior session's workspace snapshot is what gets restored. * [Self-hosting overview](/platform/self-hosting/) - Architecture decision guide for self-hosted workers, where customizing snapshots is most often needed. * [Unmanaged architecture](/platform/self-hosting/unmanaged/) - Run `oz agent run` in CI, Kubernetes, or your dev environment outside the bundled image. -* [Oz CLI](/reference/cli/) - Full reference for `oz agent run` and `oz agent run-cloud`. +* [{VARS.WARP_AGENT_CLI}](/reference/cli/) - Full reference for `oz agent run` and `oz agent run-cloud`. diff --git a/src/content/docs/platform/harnesses/authentication.mdx b/src/content/docs/platform/harnesses/authentication.mdx index 7cd5219e..9aaa8d4c 100644 --- a/src/content/docs/platform/harnesses/authentication.mdx +++ b/src/content/docs/platform/harnesses/authentication.mdx @@ -1,13 +1,14 @@ --- title: Third-party cloud agent authentication description: >- - Connect your Anthropic or OpenAI credentials to Oz, then launch Claude Code - or Codex as cloud agents from the desktop app, Oz web app, or API. + Connect your Anthropic or OpenAI credentials to {{WARP_AUTOMATION_PLATFORM}}, then launch Claude Code + or Codex as cloud agents from the desktop app, {{WEB_APP}}, or API. sidebar: label: "Authentication" --- +import { VARS } from '@data/vars'; -Third-party cloud agent authentication in Oz stores provider credentials for cloud runs as Warp-managed secrets. Third-party cloud agents, like [Claude Code](#connecting-claude-code-credentials) and [Codex](#connecting-codex-credentials), call their providers directly, so set up an Anthropic or OpenAI credential once before launching a third-party harness. +Third-party cloud agent authentication in {VARS.WARP_AUTOMATION_PLATFORM} stores provider credentials for cloud runs as Warp-managed secrets. Third-party cloud agents, like [Claude Code](#connecting-claude-code-credentials) and [Codex](#connecting-codex-credentials), call their providers directly, so set up an Anthropic or OpenAI credential once before launching a third-party harness. Auth secrets can be scoped to a **team** (available to all teammates' runs) or **personal** (only your own runs), like any other Warp-managed secret. @@ -26,24 +27,24 @@ Claude Code is Anthropic's agentic coding tool. For more on Claude Code authenti 3. Navigate to the API keys section, then click **Get API key**. 4. Create a new API key and copy the value. -Oz also supports Bedrock-routed credentials (**Anthropic Bedrock API key** and **Anthropic Bedrock access key**) if your team consumes Anthropic models through AWS. +{VARS.WARP_AUTOMATION_PLATFORM} also supports Bedrock-routed credentials (**Anthropic Bedrock API key** and **Anthropic Bedrock access key**) if your team consumes Anthropic models through AWS. -### Store API key in Oz +### Store the API key #### Warp desktop app Start a new cloud agent run and choose **Claude Code** from the **Agent harness** dropdown. In the harness auth secret field, add or select your Anthropic credential. -#### Oz web app +#### Web app -Start a [new run](https://oz.warp.dev/runs/new), choose **Claude Code** as the harness, and add a new key in the Claude Code auth secret dialog. +Start a new run, choose **Claude Code** as the harness, and add a new key in the Claude Code auth secret dialog.
![The Oz web app dialog for adding a new Claude Code auth secret.](../../../../assets/agent-platform/claude-code-auth-secret-setup.png)
The Claude Code auth secret dialog.
-#### Oz CLI +#### CLI ```bash oz secret create claude api-key --team @@ -69,17 +70,17 @@ A ChatGPT subscription (Plus, Pro, Team) does not include API access. You need a 4. In the **Create new secret key** dialog, choose the owner, project, and permissions for the key. 5. Click **Create secret key**, then copy the value. -### Store API key in Oz +### Store the API key #### Warp desktop app Start a new cloud agent run and choose **Codex** from the **Agent harness** dropdown. In the harness auth secret field, add or select your OpenAI credential. -#### Oz web app +#### Web app -Start a [new run](https://oz.warp.dev/runs/new), choose **Codex** as the harness, and add a new key in the Codex auth secret dialog. +Start a new run, choose **Codex** as the harness, and add a new key in the Codex auth secret dialog. -#### Oz CLI +#### CLI ```bash oz secret create codex api-key --team @@ -114,7 +115,7 @@ Deleting an auth secret breaks any scheduled or integration-triggered run that r ## Troubleshooting **Claude Code or Codex run fails with an authentication error.**\ -Confirm the run was started with a harness auth secret selected. From the Oz web app's run detail pane, the **Harness auth secret** field shows which secret (if any) was used. Re-launch the run with the correct secret selected, or create one if your team doesn't have one yet. +Confirm the run was started with a harness auth secret selected. From the {VARS.WEB_APP}'s run detail pane, the **Harness auth secret** field shows which secret (if any) was used. Re-launch the run with the correct secret selected, or create one if your team doesn't have one yet. **The harness auth secret dropdown is empty.**\ The dropdown only lists secrets whose type matches the selected harness — Anthropic types for Claude Code, OpenAI for Codex. If you stored the credential as a raw value, recreate it using the typed flow above. @@ -124,7 +125,7 @@ Your team admin has disabled the harness for your workspace. Contact your admin ## Related pages -* [Harnesses in Oz](/platform/harnesses/) — overview of third-party harnesses in Oz. +* [Harnesses in {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/) — overview of third-party harnesses in {VARS.WARP_AUTOMATION_PLATFORM}. * [Claude Code in Warp](/agents/cli-agents/claude-code/) — run Claude Code locally in the Warp terminal. * [Codex CLI in Warp](/agents/cli-agents/codex/) — run Codex locally in the Warp terminal. * [Cloud agent secrets](/platform/secrets/) — the full Warp-managed secrets reference. diff --git a/src/content/docs/platform/harnesses/claude-code.mdx b/src/content/docs/platform/harnesses/claude-code.mdx index 570d47c2..449a57e4 100644 --- a/src/content/docs/platform/harnesses/claude-code.mdx +++ b/src/content/docs/platform/harnesses/claude-code.mdx @@ -1,21 +1,22 @@ --- -title: Claude Code with Oz +title: Claude Code with {{WARP_AUTOMATION_PLATFORM}} description: >- - Run Claude Code with Oz. Strong at code review, deep bug investigation, large + Run Claude Code with {{WARP_AUTOMATION_PLATFORM}}. Strong at code review, deep bug investigation, large feature planning, and frontend or UI work. sidebar: label: "Claude Code" --- +import { VARS } from '@data/vars'; -Claude Code is Anthropic's agentic coding tool. Running it with Oz puts Claude Code inside a Warp-managed environment and connects it to the rest of the Oz platform — including triggers, environments, secrets, observability, and governance — while still behaving like the Claude Code your team already uses. +Claude Code is Anthropic's agentic coding tool. Running it with {VARS.WARP_AUTOMATION_PLATFORM} puts Claude Code inside a Warp-managed environment and connects it to the rest of the {VARS.WARP_AUTOMATION_PLATFORM} — including triggers, environments, secrets, observability, and governance — while still behaving like the Claude Code your team already uses. :::note -This page covers Claude Code as a **cloud** harness, dispatched and orchestrated by Oz. To run Claude Code locally in your Warp terminal, see [Claude Code in Warp](/agents/cli-agents/claude-code/) instead. +This page covers Claude Code as a **cloud** harness, dispatched and orchestrated by {VARS.WARP_AUTOMATION_PLATFORM}. To run Claude Code locally in your Warp terminal, see [Claude Code in Warp](/agents/cli-agents/claude-code/) instead. ::: ## Key features -* **Cloud orchestration** - Launch Claude Code from any Oz trigger: the Warp app, the Oz web app, the Oz CLI, the REST API, schedules, Slack mentions, Linear issues, or GitHub Actions. +* **Cloud orchestration** - Launch Claude Code from any {VARS.WARP_AUTOMATION_PLATFORM} trigger: the Warp app, the {VARS.WEB_APP}, the {VARS.WARP_AGENT_CLI}, the REST API, schedules, Slack mentions, Linear issues, or GitHub Actions. * **Claude model picker** - Choose the Claude model the harness uses, including the latest pinned Opus, Sonnet, and Haiku releases, the `best`/`opus`/`sonnet`/`haiku` aliases, and 1M-context variants. * **First-class subagent** - A Warp Agent parent can dispatch Claude Code subagents to handle steps that require code review or nuanced judgment within a larger orchestration. @@ -26,11 +27,11 @@ The Claude Code harness exposes Anthropic's coding-tuned model lineup. Common ch * `best` - Resolves to the current top-of-line Claude model. * `opus`, `sonnet`, `haiku` - Aliases that resolve to the current default for that family. -For the full list — including 1M-context variants for very large codebases and planning-tuned models — open the model picker in the Warp app's Cloud Mode or the **Model** field on the Oz web app's new-run pane. +For the full list — including 1M-context variants for very large codebases and planning-tuned models — open the model picker in the Warp app's Cloud Mode or the **Model** field on the {VARS.WEB_APP}'s new-run pane. ## Credentials and billing -Claude Code calls Anthropic directly using credentials your team provides. Oz supports three Anthropic credential types, stored as [Warp-managed secrets](/platform/secrets/): +Claude Code calls Anthropic directly using credentials your team provides. {VARS.WARP_AUTOMATION_PLATFORM} supports three Anthropic credential types, stored as [Warp-managed secrets](/platform/secrets/): * **Anthropic API key** - For direct Anthropic API access. * **Anthropic Bedrock API key** - For Bedrock-routed inference using an API key. @@ -43,13 +44,13 @@ For setup steps, see [Connecting Claude Code credentials](/platform/harnesses/au ## Starting a Claude Code run * **Warp app** - In Cloud Mode, click the **Agent harness** dropdown above the input and choose **Claude Code**. -* **Oz web app** - On the new run or new schedule pane, choose **Claude Code** in the **Harness** field. A **Claude Code auth secret** field appears below it; pick one of your stored Anthropic secrets. +* **{VARS.WEB_APP}** - On the new run or new schedule pane, choose **Claude Code** in the **Harness** field. A **Claude Code auth secret** field appears below it; pick one of your stored Anthropic secrets. * **API and SDK** - Set the agent config `harness` to `claude` and the Anthropic secret name on the matching auth-secret field. See the [API reference](/reference/api-and-sdk/). ## Related pages -* [Harnesses in Oz](/platform/harnesses/) — choose between Warp Agent, Claude Code, and Codex. +* [Harnesses in {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/) — choose between Warp Agent, Claude Code, and Codex. * [Authentication](/platform/harnesses/authentication/) — store Anthropic credentials as Warp-managed secrets. -* [Warp Agent with Oz](/platform/harnesses/warp-agent/) — Oz's default harness, the only one that can orchestrate Claude Code subagents. -* [Codex with Oz](/platform/harnesses/codex/) — Codex as a cloud harness. +* [Warp Agent with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/warp-agent/) — {VARS.WARP_AUTOMATION_PLATFORM}'s default harness, the only one that can orchestrate Claude Code subagents. +* [Codex with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/codex/) — Codex as a cloud harness. * [Claude Code in Warp](/agents/cli-agents/claude-code/) — Claude Code in your local Warp terminal. diff --git a/src/content/docs/platform/harnesses/codex.mdx b/src/content/docs/platform/harnesses/codex.mdx index 1377c15c..10a70b5b 100644 --- a/src/content/docs/platform/harnesses/codex.mdx +++ b/src/content/docs/platform/harnesses/codex.mdx @@ -1,21 +1,22 @@ --- -title: Codex with Oz +title: Codex with {{WARP_AUTOMATION_PLATFORM}} description: >- - Run Codex with Oz for codebase migrations, release coordination, batch test + Run Codex with {{WARP_AUTOMATION_PLATFORM}} for codebase migrations, release coordination, batch test generation, and backend or DevOps automation. sidebar: label: "Codex" --- +import { VARS } from '@data/vars'; -Codex is OpenAI's coding agent. Running it with Oz puts Codex inside a Warp-managed environment and connects it to the rest of the Oz platform — including triggers, environments, secrets, observability, and governance — while still behaving like the Codex CLI your team already uses. +Codex is OpenAI's coding agent. Running it with {VARS.WARP_AUTOMATION_PLATFORM} puts Codex inside a Warp-managed environment and connects it to the rest of the {VARS.WARP_AUTOMATION_PLATFORM} — including triggers, environments, secrets, observability, and governance — while still behaving like the Codex CLI your team already uses. :::note -This page covers Codex as a **cloud** harness, dispatched and orchestrated by Oz. To run Codex locally in your Warp terminal, see [Codex CLI in Warp](/agents/cli-agents/codex/) instead. +This page covers Codex as a **cloud** harness, dispatched and orchestrated by {VARS.WARP_AUTOMATION_PLATFORM}. To run Codex locally in your Warp terminal, see [Codex CLI in Warp](/agents/cli-agents/codex/) instead. ::: ## Key features -* **Cloud orchestration** - Launch Codex from any Oz trigger: the Warp app, the Oz web app, the Oz CLI, the REST API, schedules, Slack mentions, Linear issues, or GitHub Actions. +* **Cloud orchestration** - Launch Codex from any {VARS.WARP_AUTOMATION_PLATFORM} trigger: the Warp app, the {VARS.WEB_APP}, the {VARS.WARP_AGENT_CLI}, the REST API, schedules, Slack mentions, Linear issues, or GitHub Actions. * **Codex model picker** - Choose the OpenAI model Codex uses, including the GPT-5 lineup, Codex-tuned variants, and a `default` option that lets Codex pick its own recommended model. * **First-class subagent** - A Warp Agent parent can dispatch Codex subagents to handle high-volume or well-defined coding steps inside a larger orchestration. @@ -27,11 +28,11 @@ The Codex harness exposes OpenAI's Codex-tuned and general coding models. Common * `gpt-5.5`, `gpt-5.4` - Recent strong coding models from OpenAI with a configurable reasoning level. * `gpt-5.4-mini` - A faster, lower-cost option for lighter coding tasks or subagents. -For the full list, including Codex-tuned and general models, open the model picker on the Oz web app's new-run pane. For details on each model, see [OpenAI's Codex model docs](https://developers.openai.com/codex/models). +For the full list, including Codex-tuned and general models, open the model picker on the {VARS.WEB_APP}'s new-run pane. For details on each model, see [OpenAI's Codex model docs](https://developers.openai.com/codex/models). ## Credentials and billing -Codex calls OpenAI directly using credentials your team provides. Oz supports one credential type today, stored as a [Warp-managed secret](/platform/secrets/): +Codex calls OpenAI directly using credentials your team provides. {VARS.WARP_AUTOMATION_PLATFORM} supports one credential type today, stored as a [Warp-managed secret](/platform/secrets/): * **OpenAI API key** - The Codex harness authenticates to OpenAI using this key for every run. @@ -42,13 +43,13 @@ For setup steps, see [Connecting Codex credentials](/platform/harnesses/authenti ## Starting a Codex run * **Warp app** - In Cloud Mode, click the **Agent harness** dropdown above the input and choose **Codex**. -* **Oz web app** - On the new run or new schedule pane, choose **Codex** in the **Harness** field. A **Codex auth secret** field appears below it; pick the OpenAI secret your team has stored. +* **{VARS.WEB_APP}** - On the new run or new schedule pane, choose **Codex** in the **Harness** field. A **Codex auth secret** field appears below it; pick the OpenAI secret your team has stored. * **API and SDK** - Set the agent config `harness` to `codex` and the OpenAI secret name on the matching auth-secret field. See the [API reference](/reference/api-and-sdk/). ## Related pages -* [Harnesses in Oz](/platform/harnesses/) — choose between Warp Agent, Claude Code, and Codex. +* [Harnesses in {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/) — choose between Warp Agent, Claude Code, and Codex. * [Authentication](/platform/harnesses/authentication/) — store OpenAI credentials as Warp-managed secrets. -* [Warp Agent with Oz](/platform/harnesses/warp-agent/) — Oz's default harness, the only one that can orchestrate Codex subagents. -* [Claude Code with Oz](/platform/harnesses/claude-code/) — Claude Code as a cloud harness. +* [Warp Agent with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/warp-agent/) — {VARS.WARP_AUTOMATION_PLATFORM}'s default harness, the only one that can orchestrate Codex subagents. +* [Claude Code with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/claude-code/) — Claude Code as a cloud harness. * [Codex CLI in Warp](/agents/cli-agents/codex/) — Codex in your local Warp terminal. diff --git a/src/content/docs/platform/harnesses/index.mdx b/src/content/docs/platform/harnesses/index.mdx index 9feedda5..899184e6 100644 --- a/src/content/docs/platform/harnesses/index.mdx +++ b/src/content/docs/platform/harnesses/index.mdx @@ -1,5 +1,5 @@ --- -title: Harnesses in Oz +title: Harnesses in {{WARP_AUTOMATION_PLATFORM}} description: >- Run third-party harnesses such as Claude Code or Codex as cloud agents. They inherit the same triggers, environments, secrets, and observability as Warp @@ -8,8 +8,9 @@ sidebar: label: "Overview" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -Oz can run third-party agent harnesses as cloud agents alongside Warp Agent, including [Claude Code](/platform/harnesses/claude-code/) and [Codex](/platform/harnesses/codex/). You choose the harness (agent runtime) that fits the task; the platform around the run stays the same. +{VARS.WARP_AUTOMATION_PLATFORM} can run third-party agent harnesses as cloud agents alongside Warp Agent, including [Claude Code](/platform/harnesses/claude-code/) and [Codex](/platform/harnesses/codex/). You choose the harness (agent runtime) that fits the task; the platform around the run stays the same. Watch this walkthrough to see how to run Warp Agent, Claude Code, or Codex as a cloud agent. @@ -17,12 +18,12 @@ Watch this walkthrough to see how to run Warp Agent, Claude Code, or Codex as a ## What stays the same -Third-party harnesses inherit the same Oz platform features as Warp Agent: +Third-party harnesses inherit the same {VARS.WARP_AUTOMATION_PLATFORM} features as Warp Agent: * **Triggers** — Slack, Linear, schedules, CI, and API [triggers](/platform/triggers/) launch any harness. * **Environments and secrets** — Reuse the same [environments](/platform/environments/) and [agent secrets](/platform/secrets/). * **Skills and Rules** — Saved [Skills](/agents/capabilities/skills/) and [Rules](/agents/capabilities/rules/) apply across harnesses. -* **Observability** — Every run produces a transcript and shareable session in the [Oz dashboard](/platform/managing-cloud-agents/). +* **Observability** — Every run produces a transcript and shareable session in the [{VARS.DASHBOARD}](/platform/managing-cloud-agents/). ## Billing @@ -43,7 +44,7 @@ In Cloud Mode, choose a harness from the **Agent harness** dropdown above the in You can enter Cloud Mode by creating a new **Cloud Agent** tab or by using the `/cloud-agent` slash command. ::: -### Oz web app +### Web app On the new run or new schedule pane, choose the harness in the **Harness** field. @@ -53,8 +54,8 @@ Set the `harness` field on the agent config. See the [API reference](/reference/ ## Related pages -* [Warp Agent with Oz](/platform/harnesses/warp-agent/) — Oz's default first-party harness. -* [Claude Code with Oz](/platform/harnesses/claude-code/) — Claude Code as a cloud harness. -* [Codex with Oz](/platform/harnesses/codex/) — Codex as a cloud harness. +* [Warp Agent with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/warp-agent/) — {VARS.WARP_AUTOMATION_PLATFORM}'s default first-party harness. +* [Claude Code with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/claude-code/) — Claude Code as a cloud harness. +* [Codex with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/codex/) — Codex as a cloud harness. * [Authentication](/platform/harnesses/authentication/) — connect credentials and launch Claude Code or Codex. * [Third-party CLI agents in the Warp terminal](/agents/cli-agents/overview/) — run Claude Code, Codex, and other CLI agents locally. diff --git a/src/content/docs/platform/harnesses/warp-agent.mdx b/src/content/docs/platform/harnesses/warp-agent.mdx index ad7870bd..6f5e1b24 100644 --- a/src/content/docs/platform/harnesses/warp-agent.mdx +++ b/src/content/docs/platform/harnesses/warp-agent.mdx @@ -1,13 +1,14 @@ --- -title: Warp Agent with Oz +title: Warp Agent with {{WARP_AUTOMATION_PLATFORM}} description: >- - Warp Agent is Oz's default harness. It routes across leading models, has full + Warp Agent is {{WARP_AUTOMATION_PLATFORM}}'s default harness. It routes across leading models, has full terminal access, and is the only harness that can orchestrate subagents. sidebar: label: "Warp Agent" --- +import { VARS } from '@data/vars'; -Warp Agent is the harness Warp builds and ships with Oz. It's the default for every cloud agent run unless you pick another harness, and it's the only harness that can spawn cross-harness subagents (for example, a Warp Agent parent dispatching a Claude Code or Codex child). +Warp Agent is the harness Warp builds and ships with {VARS.WARP_AUTOMATION_PLATFORM}. It's the default for every cloud agent run unless you pick another harness, and it's the only harness that can spawn cross-harness subagents (for example, a Warp Agent parent dispatching a Claude Code or Codex child). Warp Agent is the same agent runtime that powers Agent Mode in the Warp terminal. Running it as a cloud harness gives you the same behavior — model routing, tool access, Skills, Rules, Memory — without tying execution to a single laptop. @@ -22,7 +23,7 @@ Warp Agent is the same agent runtime that powers Agent Mode in the Warp terminal ## How it works -Warp Agent is the same agent runtime as Agent Mode in the Warp terminal: it plans, calls tools, edits code, runs tests, and reports progress. The cloud platform adds the [environment](/platform/environments/), triggers, observability, and team governance around the run, and the transcript is inspectable in real time and replayable afterward from the [Oz dashboard](/platform/managing-cloud-agents/). +Warp Agent is the same agent runtime as Agent Mode in the Warp terminal: it plans, calls tools, edits code, runs tests, and reports progress. The cloud platform adds the [environment](/platform/environments/), triggers, observability, and team governance around the run, and the transcript is inspectable in real time and replayable afterward from the [{VARS.DASHBOARD}](/platform/managing-cloud-agents/). Team admins can disable any harness for their workspace. Users on that team can only start runs with the harnesses that remain enabled. @@ -53,17 +54,17 @@ Subagents run in the same environment as the parent and share the same secrets, Warp Agent is the default, so there's nothing extra to configure. * **Warp app** - Start a cloud agent run from the input. The **Agent harness** dropdown defaults to **Warp Agent**. -* **Oz web app** - On a new run or new schedule pane, leave the **Harness** field set to **Warp Agent**. -* **Oz CLI** - Run `oz agent run-cloud --prompt "..."` with no `--harness` flag, or pass `--harness oz` explicitly. +* **{VARS.WEB_APP}** - On a new run or new schedule pane, leave the **Harness** field set to **Warp Agent**. +* **{VARS.WARP_AGENT_CLI}** - Run `oz agent run-cloud --prompt "..."` with no `--harness` flag, or pass `--harness oz` explicitly. * **API and SDK** - Omit the `harness` field on the agent config, or set it to `oz`. See the [API reference](/reference/api-and-sdk/). For a complete walkthrough, see the [Cloud agents quickstart](/platform/quickstart/). ## Related pages -* [Harnesses in Oz](/platform/harnesses/) — choose between Warp Agent, Claude Code, and Codex. -* [Claude Code with Oz](/platform/harnesses/claude-code/) — Claude Code as a cloud harness. -* [Codex with Oz](/platform/harnesses/codex/) — Codex as a cloud harness. +* [Harnesses in {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/) — choose between Warp Agent, Claude Code, and Codex. +* [Claude Code with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/claude-code/) — Claude Code as a cloud harness. +* [Codex with {VARS.WARP_AUTOMATION_PLATFORM}](/platform/harnesses/codex/) — Codex as a cloud harness. * [Model choice](/agents/inference/model-choice/) — the model catalog Warp Agent routes across. * [Agent Profiles and permissions](/agents/capabilities/agent-profiles-permissions/) — configure the default model, autonomy, and tool access for Warp Agent. * [Skills as agents](/platform/skills-as-agents/) — turn a saved skill into a reusable Warp Agent run. diff --git a/src/content/docs/platform/index.mdx b/src/content/docs/platform/index.mdx index 53014998..987d0028 100644 --- a/src/content/docs/platform/index.mdx +++ b/src/content/docs/platform/index.mdx @@ -6,6 +6,7 @@ description: >- sidebar: label: "Cloud agents overview" --- +import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; Cloud agents are autonomous, background agents that run on Warp's cloud infrastructure or your own, triggered by system events, schedules, or integrations like Slack and GitHub. They execute tasks with full observability — every run is tracked, inspectable, and shareable across your team. @@ -14,7 +15,7 @@ Cloud agents are autonomous, background agents that run on Warp's cloud infrastr ### Monitor, inspect, and share cloud agent runs -To understand what a cloud agent did, start from the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app or the [Runs page in the Oz web app](/platform/oz-web-app/#runs). From there, you can find a run by source, status, trigger, or owner; open the run transcript; inspect the prompt, plan, commands, logs, and output; and share the session link with teammates for review. +To understand what a cloud agent did, start from the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app or the [Runs page in the {VARS.WEB_APP}](/platform/oz-web-app/#runs). From there, you can find a run by source, status, trigger, or owner; open the run transcript; inspect the prompt, plan, commands, logs, and output; and share the session link with teammates for review. For a full walkthrough, see [Viewing cloud agent runs](/platform/viewing-cloud-agent-runs/). If the run came from Slack, Linear, GitHub Actions, a schedule, the CLI, or the API, it still produces a reviewable cloud agent run record. @@ -55,7 +56,7 @@ If you are evaluating whether something should be a cloud agent, a good test is ### How cloud agents work -Cloud agents run on the [Oz Platform](/platform/overview/), which provides the primitives for triggering work, orchestrating tasks, executing agents (optionally in environments), injecting secrets, and inspecting results. +Cloud agents run on the [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/), which provides the primitives for triggering work, orchestrating tasks, executing agents (optionally in environments), injecting secrets, and inspecting results. * Something **triggers** an agent task. * The **orchestrator creates** and tracks the task. @@ -63,11 +64,11 @@ Cloud agents run on the [Oz Platform](/platform/overview/), which provides the p The exact way tasks are triggered and executed depends on your deployment model (for example CLI-only, Warp-hosted orchestration, or self-hosted execution). Those options are covered in the [Deployment Patterns](/platform/deployment-patterns/) pages. -For teams that need execution to stay within their network boundary, self-hosting supports two architectures: a **managed** worker daemon that lets Oz orchestrate agents in Docker containers on your machines, and an **unmanaged** mode where you run `oz agent run` directly in your CI, Kubernetes, or dev environment. See [Self-hosting](/platform/self-hosting/) for details. +For teams that need execution to stay within their network boundary, self-hosting supports two architectures: a **managed** worker daemon that lets {VARS.WARP_AUTOMATION_PLATFORM} orchestrate agents in Docker containers on your machines, and an **unmanaged** mode where you run `oz agent run` directly in your CI, Kubernetes, or dev environment. See [Self-hosting](/platform/self-hosting/) for details. ### What you get by default -Because cloud agents run on the [Oz Platform](/platform/overview/), each run is tracked and produces a persistent record that can be observed, shared, and reviewed (even if execution happens outside the Warp app). +Because cloud agents run on the [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/), each run is tracked and produces a persistent record that can be observed, shared, and reviewed (even if execution happens outside the Warp app). #### Codebase Context @@ -77,7 +78,7 @@ Cloud agent runs automatically benefit from [Codebase Context](/agents/capabilit Cloud agent tasks are designed to be inspectable by the team: -* The [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app and the [Runs page in the Oz web app](/platform/oz-web-app/#runs) surface task status, source, trigger, creator, history, and credit usage. +* The [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app and the [Runs page in the {VARS.WEB_APP}](/platform/oz-web-app/#runs) surface task status, source, trigger, creator, history, and credit usage. * [Cloud agent session sharing](/platform/viewing-cloud-agent-runs/) opens the run transcript so teammates can inspect the prompt, plan, commands, logs, files changed, outputs, and follow-up messages where available. * [Agent Session Sharing](/agents/local-agents/session-sharing/) lets authorized teammates share, monitor, and steer live local or third-party agent sessions. @@ -91,7 +92,7 @@ For details on configuring MCP servers for cloud agents, see [MCP Servers](/plat #### API access to tasks -The Oz Platform exposes task visibility via the [**Oz API and SDKs**](/reference/api-and-sdk/), so teams can: +The {VARS.WARP_AUTOMATION_PLATFORM} exposes task visibility via the [**{VARS.API_SDK_NAME}**](/reference/api-and-sdk/), so teams can: * Query which tasks are running or have run. * Fetch task metadata and outcomes. @@ -99,10 +100,10 @@ The Oz Platform exposes task visibility via the [**Oz API and SDKs**](/reference ### Using cloud agents with or without the Warp app -Cloud agents do not require the Warp app. Teams can deploy and operate them through the [Oz Platform](/platform/overview/) using: +Cloud agents do not require the Warp app. Teams can deploy and operate them through the [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) using: -* [Oz CLI](/reference/cli/) — run agents from scripts, CI, or the terminal -* [Oz web app](/platform/oz-web-app/) — visual interface for managing runs, schedules, environments, and integrations (works on mobile) +* [{VARS.WARP_AGENT_CLI}](/reference/cli/) — run agents from scripts, CI, or the terminal +* [{VARS.WEB_APP}](/platform/oz-web-app/) — visual interface for managing runs, schedules, environments, and integrations (works on mobile) * [Agent Session Sharing](/agents/local-agents/session-sharing/) — attach to running tasks to monitor or steer * [Agent Management Panel](/platform/managing-cloud-agents/) — view agent activity and run history in the Warp app * [APIs and SDKs](/reference/api-and-sdk/) — programmatic access for custom integrations @@ -113,7 +114,7 @@ If your team also uses Warp's terminal, you get an additional workflow: tasks la ### Billing and plan requirements -Cloud agents and [integrations](/platform/integrations/) run on the [Oz Platform](/platform/overview/) control plane, and usage is billed using credits. +Cloud agents and [integrations](/platform/integrations/) run on the [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) control plane, and usage is billed using credits. :::note [Bring Your Own API Key (BYOK)](/agents/inference/bring-your-own-api-key/) is not supported for cloud agent runs. BYOK keys are stored locally on your device and are not accessible to cloud-hosted agents. All cloud agent runs consume Warp credits. @@ -148,14 +149,14 @@ If your credit balance reaches zero, cloud agent runs will not be able to execut ### Learn more * [Cloud agents quickstart](/platform/quickstart/) — run your first cloud agent with an environment in ~10 minutes. -* [Oz Platform](/platform/overview/) — CLI, Oz API/SDK, orchestration, tasks, environments, hosts, integrations, and more. +* [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) — CLI, {VARS.API_SDK_NAME}, orchestration, tasks, environments, hosts, integrations, and more. * [Harnesses](/platform/harnesses/) — pick between Warp Agent, Claude Code, and Codex for any cloud agent run. * [Agents](/platform/agents/) — cloud agents that own and execute runs on your team. * [Multi-agent orchestration](/platform/orchestration/) — coordinate a parent agent and its child agents across local and cloud runs to build supervisor/worker, fan-out, critic, DAG, and swarm workflows. * [Skills as Agents](/platform/skills-as-agents/) — run agents based on reusable skill definitions from the CLI, web app, API, or on a schedule. -* [Oz CLI](/reference/cli/) — shows how to run agents in non-interactive mode from CI, scripts, or remote machines, including auth and common commands. +* [{VARS.WARP_AGENT_CLI}](/reference/cli/) — shows how to run agents in non-interactive mode from CI, scripts, or remote machines, including auth and common commands. * [Environments](/platform/environments/) — explains how environments provide the runtime context (repo, image, startup commands) for agent tasks. -* [Oz API and SDK](/reference/api-and-sdk/) — documents the REST API for creating, querying, and monitoring agent tasks programmatically. +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) — documents the REST API for creating, querying, and monitoring agent tasks programmatically. * [Agent Secrets](/platform/secrets/) — covers how to store, scope, and inject credentials into agent runs safely. * [MCP Servers](/platform/mcp/) — how to configure MCP servers for agent tool access and how MCP configuration is applied across runs. * [Deployment Patterns](/platform/deployment-patterns/) (beta) — compares common ways to deploy cloud agents and when to use each. diff --git a/src/content/docs/platform/integrations/azure-devops.mdx b/src/content/docs/platform/integrations/azure-devops.mdx index a7cbf770..0ffe45c3 100644 --- a/src/content/docs/platform/integrations/azure-devops.mdx +++ b/src/content/docs/platform/integrations/azure-devops.mdx @@ -6,8 +6,9 @@ description: >- Connect cloud agents to Azure DevOps repos using personal access tokens and Warp-managed secrets. --- +import { VARS } from '@data/vars'; -Cloud agents work with any Git repository, including those hosted on Azure DevOps. A native Azure DevOps integration is not yet available, but you can grant agents access to your repositories using a personal access token and Warp-managed secrets. Once configured, your environment works with any Oz trigger—Slack, Linear, schedules, or the CLI. +Cloud agents work with any Git repository, including those hosted on Azure DevOps. A native Azure DevOps integration is not yet available, but you can grant agents access to your repositories using a personal access token and Warp-managed secrets. Once configured, your environment works with any {VARS.WARP_AUTOMATION_PLATFORM} trigger—Slack, Linear, schedules, or the CLI. This page explains how to generate an Azure DevOps personal access token, store it securely, and configure a cloud agent environment that clones your repository at runtime. @@ -19,9 +20,9 @@ This approach works for both Azure DevOps Services (dev.azure.com) and Azure Dev ## Prerequisites -* A Warp account ([create an account at oz.warp.dev](https://oz.warp.dev)) +* A Warp account (create an account at {VARS.WEB_APP_URL}) * A repository hosted on Azure DevOps (cloud or self-hosted) -* The [Oz CLI](/reference/cli/) installed and authenticated +* The [{VARS.WARP_AGENT_CLI}](/reference/cli/) installed and authenticated --- @@ -121,8 +122,8 @@ oz agent run-cloud --environment --prompt "Your task here" With your environment configured, you can connect it to any Warp trigger exactly as you would with a GitHub-backed environment: -* **Slack** — Tag **@Oz** in a message to start an agent run against your Azure DevOps repo. See [Slack](/platform/integrations/slack/). -* **Linear** — Tag **@Oz** on an issue to kick off a workflow. See [Linear](/platform/integrations/linear/). +* **Slack** — Tag **@{VARS.WARP_AUTOMATION_PLATFORM}** in a message to start an agent run against your Azure DevOps repo. See [Slack](/platform/integrations/slack/). +* **Linear** — Tag **@{VARS.WARP_AUTOMATION_PLATFORM}** on an issue to kick off a workflow. See [Linear](/platform/integrations/linear/). * **Scheduled agents** — Run agents on a recurring schedule. See [Scheduled Agents](/platform/triggers/scheduled-agents/). :::note diff --git a/src/content/docs/platform/integrations/bitbucket.mdx b/src/content/docs/platform/integrations/bitbucket.mdx index 632cfcd8..93561e38 100644 --- a/src/content/docs/platform/integrations/bitbucket.mdx +++ b/src/content/docs/platform/integrations/bitbucket.mdx @@ -6,8 +6,9 @@ description: >- Connect cloud agents to Bitbucket repos using access tokens and Warp-managed secrets. --- +import { VARS } from '@data/vars'; -Cloud agents work with any Git repository, including those hosted on Bitbucket. Unlike GitHub, Bitbucket does not have a native Warp integration, but you can grant agents access to your Bitbucket repositories using an access token and Warp-managed secrets. Once configured, your environment works with any Oz trigger—Slack, Linear, schedules, or the CLI. +Cloud agents work with any Git repository, including those hosted on Bitbucket. Unlike GitHub, Bitbucket does not have a native Warp integration, but you can grant agents access to your Bitbucket repositories using an access token and Warp-managed secrets. Once configured, your environment works with any {VARS.WARP_AUTOMATION_PLATFORM} trigger—Slack, Linear, schedules, or the CLI. This page explains how to generate a Bitbucket access token, store it securely, and configure a cloud agent environment that clones your repository at runtime. @@ -22,9 +23,9 @@ Follow the section that matches your setup. ## Prerequisites -* A Warp account ([create an account at oz.warp.dev](https://oz.warp.dev)) +* A Warp account (create an account at {VARS.WEB_APP_URL}) * A repository hosted on Bitbucket (Cloud or Data Center/Server) -* The [Oz CLI](/reference/cli/) installed and authenticated +* The [{VARS.WARP_AGENT_CLI}](/reference/cli/) installed and authenticated --- @@ -201,8 +202,8 @@ oz agent run-cloud --environment --prompt "Your task here" With your environment configured, you can connect it to any Warp trigger exactly as you would with a GitHub-backed environment: -* **Slack** — Tag **@Oz** in a message to start an agent run against your Bitbucket repo. See [Slack](/platform/integrations/slack/). -* **Linear** — Tag **@Oz** on an issue to kick off a workflow. See [Linear](/platform/integrations/linear/). +* **Slack** — Tag **@{VARS.WARP_AUTOMATION_PLATFORM}** in a message to start an agent run against your Bitbucket repo. See [Slack](/platform/integrations/slack/). +* **Linear** — Tag **@{VARS.WARP_AUTOMATION_PLATFORM}** on an issue to kick off a workflow. See [Linear](/platform/integrations/linear/). * **Scheduled agents** — Run agents on a recurring schedule. See [Scheduled Agents](/platform/triggers/scheduled-agents/). :::note diff --git a/src/content/docs/platform/integrations/cloud-providers.mdx b/src/content/docs/platform/integrations/cloud-providers.mdx index bd79dedb..5a08cf55 100644 --- a/src/content/docs/platform/integrations/cloud-providers.mdx +++ b/src/content/docs/platform/integrations/cloud-providers.mdx @@ -5,6 +5,7 @@ description: >- sidebar: label: "AWS, GCP, and other cloud providers" --- +import { VARS } from '@data/vars'; Cloud agents can securely access AWS, GCP, and other cloud providers using short-lived OpenID Connect (OIDC) credentials. Configure your cloud agent environment to automatically authenticate to your cloud provider without storing long-lived keys, using Warp's built-in OIDC federation support. @@ -12,7 +13,7 @@ Cloud agents can securely access AWS, GCP, and other cloud providers using short ## Prerequisites -* A Warp account. You can [create an account in the Oz web app](https://oz.warp.dev). +* A Warp account. You can create an account in the {VARS.WEB_APP}. * A cloud provider account Follow the section for your cloud provider. @@ -23,7 +24,7 @@ Follow the section for your cloud provider. ### Step 1: Create an OIDC identity provider -The first step is to configure your AWS account to trust OIDC tokens produced by Oz. +The first step is to configure your AWS account to trust OIDC tokens produced by {VARS.WARP_AUTOMATION_PLATFORM}. 1. Open the [AWS IAM console](https://console.aws.amazon.com/iam). 2. Click **Identity Providers**, then click **Add provider**. @@ -126,23 +127,23 @@ To allow multiple specific principals, use a list of subjects: Finally, configure the cloud agent environment to use your new AWS role. -1. Open the [Oz web app](https://oz.warp.dev). +1. Open the {VARS.WEB_APP}. 2. Create or edit an environment. See [Environments](/platform/oz-web-app/#environments) for instructions. 3. Expand the **AWS** section and enter the AWS role ARN from Step 2. 4. Save the environment. :::caution -Currently, AWS federation can only be configured in the Oz web app, not the CLI. +Currently, AWS federation can only be configured in the {VARS.WEB_APP}, not the CLI. ::: Agents running in this environment will now automatically assume the configured role when using the `aws` CLI or a compatible SDK. :::note -Oz uses the [**Assume role with web identity**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-oidc) +{VARS.WARP_AUTOMATION_PLATFORM} uses the [**Assume role with web identity**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-oidc) AWS authentication mechanism. The following environment variables are set while the agent is running: * `AWS_ROLE_ARN`: the ARN of the role configured above -* `AWS_WEB_IDENTITY_TOKEN_FILE`: the path to a temporary file containing the agent's Oz OIDC token +* `AWS_WEB_IDENTITY_TOKEN_FILE`: the path to a temporary file containing the agent's {VARS.WARP_AUTOMATION_PLATFORM} OIDC token * `AWS_ROLE_SESSION_NAME`: a derived session name, of the form `Oz_Run_`. ::: @@ -152,8 +153,8 @@ AWS authentication mechanism. The following environment variables are set while ### Step 1: Create a Workload Identity Pool and Provider -The Oz GCP integration uses [Workload Identity Federation](https://docs.cloud.google.com/iam/docs/workload-identity-federation). -You will need to configure a pool and provider to trust OIDC tokens produced by Oz. +The {VARS.WARP_AUTOMATION_PLATFORM} GCP integration uses [Workload Identity Federation](https://docs.cloud.google.com/iam/docs/workload-identity-federation). +You will need to configure a pool and provider to trust OIDC tokens produced by {VARS.WARP_AUTOMATION_PLATFORM}. These instructions use the `gcloud` tool. You can also follow the OIDC instructions in [Configure Workload Identity Federation with other identity providers](https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-other-providers) @@ -212,20 +213,20 @@ for the full syntax supported. Finally, configure the cloud agent environment to use your Workload Identity Federation provider. -1. Open the [Oz web app](https://oz.warp.dev). +1. Open the {VARS.WEB_APP}. 2. Create or edit an environment. See [Environments](/platform/oz-web-app/#environments) for instructions. 3. Expand the **GCP** section and enter the project number, pool ID, and provider ID from Step 1. 4. Save the environment. :::caution -Currently, Workload Identity Federation can only be configured in the Oz web app, not the CLI. +Currently, Workload Identity Federation can only be configured in the {VARS.WEB_APP}, not the CLI. ::: Agents running in this environment will now automatically configure [Application Default Credentials](https://docs.cloud.google.com/docs/authentication/application-default-credentials) to use the configured pool. Both the `GOOGLE_APPLICATION_CREDENTIALS` and `CLOUDSDK_AUTH_CREDENTIAL_FILE_OVERRIDE` -environment variables are set, so both the `gcloud` CLI and official Google SDKs will use the Oz -federated credentials. Oz uses +environment variables are set, so both the `gcloud` CLI and official Google SDKs will use the {VARS.WARP_AUTOMATION_PLATFORM} +federated credentials. {VARS.WARP_AUTOMATION_PLATFORM} uses [**executable-sourced credentials**](https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-other-providers#create-credential-config) to configure ADC for automatic token rotation. @@ -233,19 +234,19 @@ to configure ADC for automatic token rotation. Environment variables alone are enough for the Google SDKs, but `gcloud` reports no active account until it signs in through its own auth system, and some tooling depends on an active account. During provider -setup, Oz therefore also runs `gcloud auth login` against the federated credential file so `gcloud` reports +setup, {VARS.WARP_AUTOMATION_PLATFORM} therefore also runs `gcloud auth login` against the federated credential file so `gcloud` reports the federated identity as its active account. This step is best-effort and never blocks the run: -* **`gcloud` isn't installed** - Oz skips the sign-in. The ADC environment variables still provide credentials to the Google SDKs. -* **Sign-in fails or times out** - Oz logs the failure and continues. The ADC environment variables still work, so a run only loses the active-account convenience. +* **`gcloud` isn't installed** - {VARS.WARP_AUTOMATION_PLATFORM} skips the sign-in. The ADC environment variables still provide credentials to the Google SDKs. +* **Sign-in fails or times out** - {VARS.WARP_AUTOMATION_PLATFORM} logs the failure and continues. The ADC environment variables still work, so a run only loses the active-account convenience. To confirm the account inside a run, use `gcloud auth list`. ## Other providers -To authenticate from Oz to another provider that supports OIDC federation, you can issue tokens +To authenticate from {VARS.WARP_AUTOMATION_PLATFORM} to another provider that supports OIDC federation, you can issue tokens directly. Within the agent environment, use the `oz federate issue-token` command to produce an OIDC token @@ -262,7 +263,7 @@ You can then exchange this token for provider-specific credentials. ## OIDC token claims -All Oz OIDC tokens include standard claims like `iss` (issuer) and `iat` (issued at). +All {VARS.WARP_AUTOMATION_PLATFORM} OIDC tokens include standard claims like `iss` (issuer) and `iat` (issued at). ### Audience @@ -279,7 +280,7 @@ By default, the `sub` claim uses the format `:`: * `user:abc123def456`: Identifies a user with ID `abc123def456` * `service_account:abc123def456`: Identifies your autogenerated team account -When authenticating to AWS, Oz will use a different `sub` claim format, because AWS trust policies cannot +When authenticating to AWS, {VARS.WARP_AUTOMATION_PLATFORM} will use a different `sub` claim format, because AWS trust policies cannot match on custom OIDC claims. The format above will be prefixed with your team UID: * `scoped_principal:xyz789/user:abc123def456`: Identifies the user `abc123def456`, who is a member of team `xyz789`. * `scoped_principal:user:abc123def456`: Identifies the user `abc123def456`, who is not on any team. @@ -297,7 +298,7 @@ Team ID: xyz789 Team Name: My Team ``` -You can also check the user IDs from past runs using the Oz API: +You can also check the user IDs from past runs using the {VARS.API_SDK_NAME}: ```bash curl https://app.warp.dev/api/v1/agent/runs -H "Authorization: Bearer $WARP_API_KEY" @@ -321,7 +322,7 @@ curl https://app.warp.dev/api/v1/agent/runs -H "Authorization: Bearer $WARP_API_ Every token includes a `teams` claim. The value will be a list with your team UID - currently, this list only ever contains a single value. -### Oz run +### Run The following claims are derived from an agent run: diff --git a/src/content/docs/platform/integrations/github-actions.mdx b/src/content/docs/platform/integrations/github-actions.mdx index 8b804a7b..49e98796 100644 --- a/src/content/docs/platform/integrations/github-actions.mdx +++ b/src/content/docs/platform/integrations/github-actions.mdx @@ -5,6 +5,7 @@ description: >- CI fixes. --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; Run agents directly in your GitHub Actions workflows using `oz-agent-action`. The agent integrates seamlessly into your CI pipeline, automating tasks like code review, issue triage, bug fixing, and maintenance using your repository context and GitHub permissions. This page covers how the integration works, how to set it up, and common automation patterns for development teams. @@ -16,7 +17,7 @@ Run agents directly in your GitHub Actions workflows using `oz-agent-action`. Th GitHub Actions is different from the [GitHub integration](/platform/integrations/github/). GitHub Actions runs agents inside workflows you define in your repository, and you control the trigger, permissions, and prompt in YAML. The GitHub integration starts agents when someone mentions `@oz-agent` on an issue, pull request, or review comment, using the Oz by Warp GitHub App with no workflow file. ::: -If you're comparing GitHub Actions with schedules, Slack, Linear, the GitHub integration, the Oz CLI, or API-triggered runs, see [Run agents unattended with schedules and triggers](/guides/agent-workflows/how-to-run-unattended-agents/). +If you're comparing GitHub Actions with schedules, Slack, Linear, the GitHub integration, the {VARS.WARP_AGENT_CLI}, or API-triggered runs, see [Run agents unattended with schedules and triggers](/guides/agent-workflows/how-to-run-unattended-agents/). Watch this demo to see the integration in action: @@ -33,7 +34,7 @@ In this demo ### What the GitHub Actions integration does -The `oz-agent-action` is a GitHub Action that wraps the Oz CLI and: +The `oz-agent-action` is a GitHub Action that wraps the {VARS.WARP_AGENT_CLI} and: * Runs an agent inside an Actions job * Caches package installation for faster builds diff --git a/src/content/docs/platform/integrations/gitlab.mdx b/src/content/docs/platform/integrations/gitlab.mdx index 6586594f..de01cd95 100644 --- a/src/content/docs/platform/integrations/gitlab.mdx +++ b/src/content/docs/platform/integrations/gitlab.mdx @@ -6,8 +6,9 @@ description: >- Connect cloud agents to GitLab repos using personal access tokens and Warp-managed secrets. --- +import { VARS } from '@data/vars'; -Cloud agents work with any Git repository, including those hosted on GitLab. Unlike GitHub, GitLab does not have a native Warp integration, but you can grant agents access to your GitLab repositories using a personal access token and Warp-managed secrets. Once configured, your environment works with any Oz trigger—Slack, Linear, schedules, or the CLI. +Cloud agents work with any Git repository, including those hosted on GitLab. Unlike GitHub, GitLab does not have a native Warp integration, but you can grant agents access to your GitLab repositories using a personal access token and Warp-managed secrets. Once configured, your environment works with any {VARS.WARP_AUTOMATION_PLATFORM} trigger—Slack, Linear, schedules, or the CLI. This page explains how to generate a GitLab personal access token, store it securely, and configure a cloud agent environment that clones your repository at runtime. @@ -19,9 +20,9 @@ This approach works for both GitLab.com and self-hosted GitLab instances. ## Prerequisites -* A Warp account ([create an account at oz.warp.dev](https://oz.warp.dev)) +* A Warp account (create an account at {VARS.WEB_APP_URL}) * A repository hosted on GitLab (cloud or self-hosted) -* The [Oz CLI](/reference/cli/) installed and authenticated +* The [{VARS.WARP_AGENT_CLI}](/reference/cli/) installed and authenticated --- @@ -120,8 +121,8 @@ oz agent run-cloud --environment --prompt "Your task here" With your environment configured, you can connect it to any Warp trigger exactly as you would with a GitHub-backed environment: -* **Slack** — Tag **@Oz** in a message to start an agent run against your GitLab repo. See [Slack](/platform/integrations/slack/). -* **Linear** — Tag **@Oz** on an issue to kick off a workflow. See [Linear](/platform/integrations/linear/). +* **Slack** — Tag **@{VARS.WARP_AUTOMATION_PLATFORM}** in a message to start an agent run against your GitLab repo. See [Slack](/platform/integrations/slack/). +* **Linear** — Tag **@{VARS.WARP_AUTOMATION_PLATFORM}** on an issue to kick off a workflow. See [Linear](/platform/integrations/linear/). * **Scheduled agents** — Run agents on a recurring schedule. See [Scheduled Agents](/platform/triggers/scheduled-agents/). :::note diff --git a/src/content/docs/platform/integrations/index.mdx b/src/content/docs/platform/integrations/index.mdx index 2e00fd65..1d711b7e 100644 --- a/src/content/docs/platform/integrations/index.mdx +++ b/src/content/docs/platform/integrations/index.mdx @@ -6,6 +6,7 @@ description: >- development workflows. --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; Warp integrations let your team trigger agents directly from the terminal, or from tools like [Slack](/platform/integrations/slack/), [Linear](/platform/integrations/linear/), [Jira](/platform/integrations/jira/), and [GitHub](/platform/integrations/github/). Once set up, agents can: @@ -13,7 +14,7 @@ Warp integrations let your team trigger agents directly from the terminal, or fr * Run code inside your codebase in a remote environment * Open pull requests and perform other multi-step agent workflows on your behalf -If you're deciding whether an agent should run from a schedule, Slack, Linear, GitHub, GitHub Actions, the Oz CLI, or the API, see [Run agents unattended with schedules and triggers](/guides/agent-workflows/how-to-run-unattended-agents/). +If you're deciding whether an agent should run from a schedule, Slack, Linear, GitHub, GitHub Actions, the {VARS.WARP_AGENT_CLI}, or the API, see [Run agents unattended with schedules and triggers](/guides/agent-workflows/how-to-run-unattended-agents/). :::note Warp has two distinct GitHub surfaces. The [GitHub integration](/platform/integrations/github/) starts agents when someone mentions `@oz-agent` on an issue, pull request, or review comment, using the Oz by Warp GitHub App. [GitHub Actions](/platform/integrations/github-actions/) runs agents inside workflows you define in your own CI pipeline. @@ -23,7 +24,7 @@ Warp has two distinct GitHub surfaces. The [GitHub integration](/platform/integr For a full walkthrough of Warp's integrations and configurable environments, see [Integration setup](/reference/cli/integration-setup/). ::: -All of this is powered by the [Oz CLI](/reference/cli/). +All of this is powered by the [{VARS.WARP_AGENT_CLI}](/reference/cli/). --- diff --git a/src/content/docs/platform/integrations/jira.mdx b/src/content/docs/platform/integrations/jira.mdx index 3113df95..7ce6ecd9 100644 --- a/src/content/docs/platform/integrations/jira.mdx +++ b/src/content/docs/platform/integrations/jira.mdx @@ -5,6 +5,7 @@ sidebar: description: >- Trigger cloud agent runs directly from Jira issues using the warp-agent label. --- +import { VARS } from '@data/vars'; The Jira integration lets your team kick off cloud agent runs directly from Jira Cloud issues. When you add the `warp-agent` label to an issue, an agent starts in the cloud and gets to work — then posts status updates and a summary as Jira comments when it's done. @@ -16,7 +17,7 @@ The Jira integration lets your team kick off cloud agent runs directly from Jira * **Team membership** - The Jira integration requires you to be part of a [Warp team](/knowledge-and-collaboration/teams/). Teams can be created on any plan, including Free. * **Plan and credits** - Your team must be on a plan that supports integrations (Build, Max, or Business) and have at least 20 credits available. See [Access, Billing, and Identity](/platform/team-access-billing-and-identity/) for details. * **Infrastructure** - By default, agents run on Warp-hosted infrastructure. Enterprise teams can [self-host agents](/platform/self-hosting/) on their own infrastructure. -* **Jira site admin** - Installing the Oz app in Jira requires site admin permissions. +* **Jira site admin** - Installing the {VARS.WARP_AUTOMATION_PLATFORM} app in Jira requires site admin permissions. --- @@ -24,15 +25,15 @@ The Jira integration lets your team kick off cloud agent runs directly from Jira #### 1. Open the Jira app installation page -In the [Oz web app](https://oz.warp.dev/integrations), find Jira and click **Set up**. On the Atlassian installation page, click **Get app**. +In the {VARS.WEB_APP}, find Jira and click **Set up**. On the Atlassian installation page, click **Get app**. -#### 2. Install Oz on your Jira site +#### 2. Install the app on your Jira site -Choose the Jira Cloud site you want to connect, review the requested permissions, and install Oz. Only Jira site admins can install apps. +Choose the Jira Cloud site you want to connect, review the requested permissions, and install {VARS.WARP_AUTOMATION_PLATFORM}. Only Jira site admins can install apps. -#### 3. Open the Oz configuration page +#### 3. Open the app configuration page -In your Jira site, open **Manage apps**. Find Oz, open its three-dot actions menu, then click **Configure**. +In your Jira site, open **Manage apps**. Find {VARS.WARP_AUTOMATION_PLATFORM}, open its three-dot actions menu, then click **Configure**. The configuration page URL for the production app follows this pattern: @@ -50,19 +51,19 @@ The confirmation page displays **Jira connected** when the connection succeeds. #### 5. (Optional) Configure the default environment, model, and harness -Return to the [Integrations page in the Oz web app](https://oz.warp.dev/integrations), then click **Edit Jira** to set the default [environment](/platform/environments/), model, harness, and agent for Jira-triggered runs. If you don't change these settings, Oz uses your workspace's default configuration. +Return to the Integrations page in the {VARS.WEB_APP}, then click **Edit Jira** to set the default [environment](/platform/environments/), model, harness, and agent for Jira-triggered runs. If you don't change these settings, {VARS.WARP_AUTOMATION_PLATFORM} uses your workspace's default configuration. --- ### How to start a run -Add the label **`warp-agent`** to any Jira issue. Oz will pick it up, post a comment to let you know it's started, and begin working through the task using the issue title, description, and recent comments as context. +Add the label **`warp-agent`** to any Jira issue. {VARS.WARP_AUTOMATION_PLATFORM} will pick it up, post a comment to let you know it's started, and begin working through the task using the issue title, description, and recent comments as context. -When the run finishes, Oz posts a summary comment to the issue with links to any pull requests or branches it created, along with a link to the full conversation in Warp. To track runs across your team, open the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app, where Jira-triggered runs appear in the **All** tab. +When the run finishes, {VARS.WARP_AUTOMATION_PLATFORM} posts a summary comment to the issue with links to any pull requests or branches it created, along with a link to the full conversation in Warp. To track runs across your team, open the [Agent Management Panel](/platform/managing-cloud-agents/) in the Warp app, where Jira-triggered runs appear in the **All** tab. #### Connecting your Jira account to Warp -This step is for any user who triggers runs — it doesn't require Jira admin permissions. The first time you trigger a run, Oz posts a comment prompting you to connect your Jira account to Warp. Connecting attributes your Jira-triggered runs to your Warp account; the run doesn't start until your account is connected. After connecting, re-add the `warp-agent` label to start the run. +This step is for any user who triggers runs — it doesn't require Jira admin permissions. The first time you trigger a run, {VARS.WARP_AUTOMATION_PLATFORM} posts a comment prompting you to connect your Jira account to Warp. Connecting attributes your Jira-triggered runs to your Warp account; the run doesn't start until your account is connected. After connecting, re-add the `warp-agent` label to start the run. 1. Follow the link in the comment to open the Warp page in your Jira personal settings. The link for the production app follows this pattern: @@ -78,13 +79,13 @@ The page displays **Jira account connected** when the link succeeds, and the set ### Troubleshooting -If Oz doesn't respond after adding the label, check that: +If {VARS.WARP_AUTOMATION_PLATFORM} doesn't respond after adding the label, check that: -* The Oz app is installed and the workspace is connected (see the app's **Configure** screen in Jira). +* The {VARS.WARP_AUTOMATION_PLATFORM} app is installed and the workspace is connected (see the app's **Configure** screen in Jira). * The issue is in Jira Cloud (not Server or Data Center). :::note -When a Jira-triggered run fails to start, Oz updates its comment on the issue to say it could not start the task. Re-add the `warp-agent` label to try again; a new attempt starts a new comment thread. +When a Jira-triggered run fails to start, {VARS.WARP_AUTOMATION_PLATFORM} updates its comment on the issue to say it could not start the task. Re-add the `warp-agent` label to try again; a new attempt starts a new comment thread. ::: For other issues, reach out to your Warp contact or join the [Warp community on Slack](https://go.warp.dev/join-preview). diff --git a/src/content/docs/platform/integrations/linear.mdx b/src/content/docs/platform/integrations/linear.mdx index efe5a6b7..d9860ce7 100644 --- a/src/content/docs/platform/integrations/linear.mdx +++ b/src/content/docs/platform/integrations/linear.mdx @@ -7,8 +7,9 @@ description: >- pull requests on your behalf. --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -The Linear integration lets your team delegate development work directly to agents from inside Linear. When you tag @Oz on an issue or comment, an agent will spin up in the cloud, clone the repos defined in your environment, and begin working through the task. +The Linear integration lets your team delegate development work directly to agents from inside Linear. When you tag @{VARS.WARP_AUTOMATION_PLATFORM} on an issue or comment, an agent will spin up in the cloud, clone the repos defined in your environment, and begin working through the task. Agents keep you updated inside Linear, generate pull requests using your GitHub account, and provide a link to join a live remote session so you can watch or steer the workflow in real time. @@ -18,18 +19,18 @@ This guide explains what the integration does, how it works end-to-end, and how --- -### Using Oz inside Linear +### Triggering agents inside Linear -Tagging @Oz on an issue or in a Linear comment starts an agent run. Oz clones the repositories defined in your environment, sets up your development environment using your Docker image and setup commands, and begins working through the task with full context from your codebase and the Linear issue. Agents post updates as they progress, including a task list, elapsed time, and checkpoints, so you can follow along without leaving Linear. +Tagging @{VARS.WARP_AUTOMATION_PLATFORM} on an issue or in a Linear comment starts an agent run. {VARS.WARP_AUTOMATION_PLATFORM} clones the repositories defined in your environment, sets up your development environment using your Docker image and setup commands, and begins working through the task with full context from your codebase and the Linear issue. Agents post updates as they progress, including a task list, elapsed time, and checkpoints, so you can follow along without leaving Linear. Agents also share a link to an interactive remote session using Warp's [cloud agent session sharing](/platform/viewing-cloud-agent-runs/). Opening this link lets you view the live terminal output for the running agent in Warp or in the browser. From there, you can interrupt or guide the agent with additional instructions when needed. Once the agent finishes, it will create a pull request on your behalf — using your GitHub permissions — and post a summary of its work and the PR link back into Linear. You can start an agent in two ways: -* **Tag @Oz in a comment** and describe what you want done. -* **Assign the issue to Oz** as if it were a teammate. +* **Tag @{VARS.WARP_AUTOMATION_PLATFORM} in a comment** and describe what you want done. +* **Assign the issue to {VARS.WARP_AUTOMATION_PLATFORM}** as if it were a teammate. -Oz will acknowledge the request directly in the Linear issue and begin working. +{VARS.WARP_AUTOMATION_PLATFORM} will acknowledge the request directly in the Linear issue and begin working. Agents keep you informed through: @@ -79,7 +80,7 @@ Because PRs are created as _you_, this makes code review, auditing, and team col ### How to configure the integration -Setup involves two steps powered by the [Oz CLI](/reference/cli/). For more instructions, see [Integrations Overview](/platform/integrations/). +Setup involves two steps powered by the [{VARS.WARP_AGENT_CLI}](/reference/cli/). For more instructions, see [Integrations Overview](/platform/integrations/). #### 1. Create an environment @@ -101,7 +102,7 @@ For full instructions, see our [Environment Setup](/platform/integrations/) docs Once your environment exists, create the integration. :::note -For easier setup, use the [Oz web app](https://oz.warp.dev) to configure integrations with a guided flow. +For easier setup, use the {VARS.WEB_APP} to configure integrations with a guided flow. ::: Alternatively, you can use the CLI: @@ -110,7 +111,7 @@ Alternatively, you can use the CLI: oz integration create linear --environment ``` -The CLI will open a browser window prompting you to install the Oz app into your Linear workspace. After installation, the integration becomes available to all members of your Warp team. +The CLI will open a browser window prompting you to install the {VARS.WARP_AUTOMATION_PLATFORM} app into your Linear workspace. After installation, the integration becomes available to all members of your Warp team. :::tip If the integration cannot be created or a Linear-triggered run cannot start, use the returned error code to narrow the fix. Common errors include: @@ -123,12 +124,12 @@ If the integration cannot be created or a Linear-triggered run cannot start, use ### Uninstallation instructions -To remove the Oz integration from Linear: +To remove the {VARS.WARP_AUTOMATION_PLATFORM} integration from Linear: 1. Only a Linear team admin can manage app permissions. 2. In Linear, go to **Settings**. 3. Navigate to Agents under the Features section. -4. Select Oz from the list of installed agents. +4. Select {VARS.WARP_AUTOMATION_PLATFORM} from the list of installed agents. 5. Click **Revoke access** to remove the integration for your workspace. @@ -137,4 +138,4 @@ After revoking access, Warp will no longer be able to read issues, receive trigg ### Troubleshooting -If something isn't working as expected—missing repos, PR failures, Linear not detecting Oz, or environment issues—see our [Integrations Troubleshooting](/platform/integrations/#troubleshooting) page for detailed guidance on GitHub permissions, environment configuration, and common setup problems. +If something isn't working as expected—missing repos, PR failures, Linear not detecting {VARS.WARP_AUTOMATION_PLATFORM}, or environment issues—see our [Integrations Troubleshooting](/platform/integrations/#troubleshooting) page for detailed guidance on GitHub permissions, environment configuration, and common setup problems. diff --git a/src/content/docs/platform/integrations/quickstart-github-actions.mdx b/src/content/docs/platform/integrations/quickstart-github-actions.mdx index cf5b3ca1..6ad87997 100644 --- a/src/content/docs/platform/integrations/quickstart-github-actions.mdx +++ b/src/content/docs/platform/integrations/quickstart-github-actions.mdx @@ -6,6 +6,7 @@ description: >- sidebar: label: "Quickstart" --- +import { VARS } from '@data/vars'; Add agents to your GitHub Actions workflows with [`oz-agent-action`](https://github.com/warpdotdev/oz-agent-action). This quickstart walks you through setting up your first GitHub Actions integration: a PR review workflow that automatically analyzes pull requests and posts inline review comments. @@ -13,7 +14,7 @@ Add agents to your GitHub Actions workflows with [`oz-agent-action`](https://git ## Prerequisites -* **Warp API key** - Create one in the [Oz web app](https://oz.warp.dev/settings). Use a personal key if the agent should commit as you, or an agent key (which runs as a [cloud agent](/platform/agents/) on your team) with [team GitHub authorization](/platform/team-access-billing-and-identity/#team-github-authorization). See [API Keys](/reference/cli/api-keys/) for the full creation flow. +* **Warp API key** - Create one in the {VARS.WEB_APP}. Use a personal key if the agent should commit as you, or an agent key (which runs as a [cloud agent](/platform/agents/) on your team) with [team GitHub authorization](/platform/team-access-billing-and-identity/#team-github-authorization). See [API Keys](/reference/cli/api-keys/) for the full creation flow. * **A GitHub repository with Actions enabled** - The workflow file will live in `.github/workflows/` in your repo. --- @@ -76,9 +77,9 @@ To verify the workflow ran: ## 4. View the run -Each `oz-agent-action` step creates a cloud agent run you can inspect from the Oz dashboard: +Each `oz-agent-action` step creates a cloud agent run you can inspect from the {VARS.DASHBOARD}: -* **Oz web app** - Go to the [Runs page in the Oz web app](https://oz.warp.dev/runs) to see the full run transcript: status, commands executed, files changed, and agent output. See [Viewing Cloud Agent Runs](/platform/viewing-cloud-agent-runs/) for a complete walkthrough. +* **{VARS.WEB_APP}** - Go to the Runs page in the {VARS.WEB_APP} to see the full run transcript: status, commands executed, files changed, and agent output. See [Viewing Cloud Agent Runs](/platform/viewing-cloud-agent-runs/) for a complete walkthrough. * **Warp app** - Open the conversations panel to see the run alongside your other agent activity. When the run completes, the agent posts feedback as inline review comments on the PR. diff --git a/src/content/docs/platform/integrations/quickstart.mdx b/src/content/docs/platform/integrations/quickstart.mdx index b4b4103b..272904a7 100644 --- a/src/content/docs/platform/integrations/quickstart.mdx +++ b/src/content/docs/platform/integrations/quickstart.mdx @@ -6,11 +6,12 @@ description: >- sidebar: label: "Quickstart" --- +import { VARS } from '@data/vars'; -Oz integrations let you trigger cloud agents directly from the tools your team already uses. This guide walks you through connecting Oz to Slack. Once set up, anyone on your team can tag @Oz in a message or thread to kick off a cloud agent that runs the task and posts results back to the conversation. +{VARS.WARP_AUTOMATION_PLATFORM} integrations let you trigger cloud agents directly from the tools your team already uses. This guide walks you through connecting {VARS.WARP_AUTOMATION_PLATFORM} to Slack. Once set up, anyone on your team can tag @{VARS.WARP_AUTOMATION_PLATFORM} in a message or thread to kick off a cloud agent that runs the task and posts results back to the conversation. :::note -**Want to connect with Linear instead?** The setup is the same — just substitute `slack` with `linear` in the CLI commands, or select Linear in the Oz web app. See [Linear](/platform/integrations/linear/) for details. +**Want to connect with Linear instead?** The setup is the same — just substitute `slack` with `linear` in the CLI commands, or select Linear in the {VARS.WEB_APP}. See [Linear](/platform/integrations/linear/) for details. ::: --- @@ -25,15 +26,15 @@ Oz integrations let you trigger cloud agents directly from the tools your team a ## 1. Connect the Slack integration -The simplest way to set up the integration is **using the Oz web app**: +The simplest way to set up the integration is **using the {VARS.WEB_APP}**: -1. Navigate to the [Integrations page in the Oz web app](https://oz.warp.dev/integrations). +1. Navigate to the Integrations page in the {VARS.WEB_APP}. 2. Click **Slack**. -3. Follow the guided flow to select your environment and authorize Oz in your Slack workspace. +3. Follow the guided flow to select your environment and authorize {VARS.WARP_AUTOMATION_PLATFORM} in your Slack workspace. All members of your Warp team can now use the integration. -**Using the Oz CLI instead:** +**Using the {VARS.WARP_AGENT_CLI} instead:** Run `oz integration create` to connect the Slack integration: @@ -41,7 +42,7 @@ Run `oz integration create` to connect the Slack integration: oz integration create slack --environment ``` -Replace `` with your environment ID (see [Environments](/platform/environments/) if you need to create one). Find it with `oz environment list` on the Oz CLI or in the [Oz web app](https://oz.warp.dev). The CLI opens a browser window to authorize the Oz app in your workspace. +Replace `` with your environment ID (see [Environments](/platform/environments/) if you need to create one). Find it with `oz environment list` on the {VARS.WARP_AGENT_CLI} or in the {VARS.WEB_APP}. The CLI opens a browser window to authorize the {VARS.WARP_AUTOMATION_PLATFORM} app in your workspace. :::tip If the integration cannot be created or your first run cannot start, use the returned error code to narrow the fix. Common errors include: @@ -58,31 +59,31 @@ oz integration create slack \ --prompt "Always open a draft PR and request review from the team-leads group." ``` -## 2. Tag @Oz in Slack +## 2. Tag the agent in Slack -In any channel or thread in your Slack workspace, tag @Oz with a task: +In any channel or thread in your Slack workspace, tag @{VARS.WARP_AUTOMATION_PLATFORM} with a task: -> @Oz scan the authentication module for security issues and summarize what you find +> @{VARS.WARP_AUTOMATION_PLATFORM} scan the authentication module for security issues and summarize what you find -Oz acknowledges the request immediately and starts an agent run in the cloud. You'll see progress updates appear in the thread as the agent works. +{VARS.WARP_AUTOMATION_PLATFORM} acknowledges the request immediately and starts an agent run in the cloud. You'll see progress updates appear in the thread as the agent works. -You can also tag @Oz inside an existing thread. Oz picks up the full thread history as context automatically, so you can tag it mid-discussion without repeating background. +You can also tag @{VARS.WARP_AUTOMATION_PLATFORM} inside an existing thread. {VARS.WARP_AUTOMATION_PLATFORM} picks up the full thread history as context automatically, so you can tag it mid-discussion without repeating background. ## 3. Watch the run While the agent works, progress updates appear directly in the Slack thread. To inspect the run in more detail: -* **Click the session link** - Oz posts a link in the thread to open a live terminal view of the agent. Watch in real time, add follow-up instructions, or let it run to completion. -* **Go to the [Runs page in the Oz web app](https://oz.warp.dev/runs)** - See the full run transcript: status, commands executed, files changed, and agent output. See [Viewing Cloud Agent Runs](/platform/viewing-cloud-agent-runs/) for a complete walkthrough. +* **Click the session link** - {VARS.WARP_AUTOMATION_PLATFORM} posts a link in the thread to open a live terminal view of the agent. Watch in real time, add follow-up instructions, or let it run to completion. +* **Go to the Runs page in the {VARS.WEB_APP}** - See the full run transcript: status, commands executed, files changed, and agent output. See [Viewing Cloud Agent Runs](/platform/viewing-cloud-agent-runs/) for a complete walkthrough. -When the task is complete, Oz posts a summary back to the original Slack thread. +When the task is complete, {VARS.WARP_AUTOMATION_PLATFORM} posts a summary back to the original Slack thread. -**Breaking it down:** Oz reads the Slack thread as context, runs the agent inside the environment you configured — with your repos cloned and Docker image running — and returns results where the conversation started, in Slack, without anyone leaving the thread. +**Breaking it down:** {VARS.WARP_AUTOMATION_PLATFORM} reads the Slack thread as context, runs the agent inside the environment you configured — with your repos cloned and Docker image running — and returns results where the conversation started, in Slack, without anyone leaving the thread. --- ## Next steps -* **Customize agent behavior** - Use a [skill](/platform/skills-as-agents/) as the base prompt for your integration to give Oz consistent, reusable instructions across every run. +* **Customize agent behavior** - Use a [skill](/platform/skills-as-agents/) as the base prompt for your integration to give {VARS.WARP_AUTOMATION_PLATFORM} consistent, reusable instructions across every run. * **Trigger agents programmatically** - Use the [API & SDK](/reference/api-and-sdk/) to build custom automations and integrations on top of agents. * **Read the full Slack reference** - [Slack](/platform/integrations/slack/) covers identity mapping, team access, monitoring runs, troubleshooting, and uninstall instructions. diff --git a/src/content/docs/platform/integrations/slack.mdx b/src/content/docs/platform/integrations/slack.mdx index 7d4cfb8d..44dda290 100644 --- a/src/content/docs/platform/integrations/slack.mdx +++ b/src/content/docs/platform/integrations/slack.mdx @@ -6,6 +6,7 @@ description: >- Trigger agents from Slack to run cloud tasks, track progress, and create pull requests. --- +import { VARS } from '@data/vars'; The Slack integration lets your team trigger cloud agents directly from Slack conversations. Tag @Warp in a message or DM the bot to start a cloud agent that clones your repos, works through the task, posts progress updates, and opens pull requests back into the same thread. @@ -13,12 +14,12 @@ The Slack integration lets your team trigger cloud agents directly from Slack co #### Installation -1. Log in to the [Oz web app](https://oz.warp.dev) and go to the [Integrations page](https://oz.warp.dev/integrations). +1. Log in to the {VARS.WEB_APP} and go to the Integrations page. 2. Click **Connect** next to **Slack**. You'll be prompted to install the Warp app into your Slack workspace. 3. After installing, you're returned to the Integrations page to finish setup: choose the [environment](/platform/environments/) agents should use, which defines the repos, Docker image, and setup commands. 4. Start using Warp in Slack by mentioning **@Warp** with a task. -Alternatively, install via the [Oz CLI](/reference/cli/): +Alternatively, install via the [{VARS.WARP_AGENT_CLI}](/reference/cli/): ``` oz integration create slack --environment @@ -64,7 +65,7 @@ Agents keep you informed directly in Slack via: * Activity updates showing progress throughout the run * Checkpoints indicating major steps completed -* A direct link to the Oz run in the [Oz web app](/platform/oz-web-app/), where you can view the full run transcript and metadata +* A direct link to the {VARS.PLATFORM_RUN} in the [{VARS.WEB_APP}](/platform/oz-web-app/), where you can view the full run transcript and metadata * A session-sharing link that opens a live terminal view of the remote agent [Cloud agent session sharing](/platform/viewing-cloud-agent-runs/) works in Warp or in your browser and supports multiple teammates joining the same live session. @@ -107,7 +108,7 @@ An environment defines everything the agent needs to run your code in the cloud: Create an environment via: -* **Oz CLI** +* **{VARS.WARP_AGENT_CLI}** ```bash oz environment create \ diff --git a/src/content/docs/platform/managing-cloud-agents.mdx b/src/content/docs/platform/managing-cloud-agents.mdx index 5f878d3e..68ecd4c2 100644 --- a/src/content/docs/platform/managing-cloud-agents.mdx +++ b/src/content/docs/platform/managing-cloud-agents.mdx @@ -2,21 +2,22 @@ title: Managing cloud agents description: >- Monitor and manage agent activity across your team with Warp's Agent - Management Panel and the Oz web app's Runs page. + Management Panel and the {{WEB_APP}}'s Runs page. sidebar: label: "Managing cloud agents" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -Warp provides two management surfaces for tracking and observing agent activity across your account and, where applicable, your team: the **Agent Management Panel** in the Warp app and the [**Runs** page in the Oz web app](/platform/oz-web-app/#runs), which also works on mobile devices. +Warp provides two management surfaces for tracking and observing agent activity across your account and, where applicable, your team: the **Agent Management Panel** in the Warp app and the [**Runs** page in the {VARS.WEB_APP}](/platform/oz-web-app/#runs), which also works on mobile devices. Use these surfaces as the starting point for real-time agent observability in Warp. They help you see which agents are active, which runs are blocked or failed, where each run started, and which session link opens the prompt, plan, commands, logs, outputs, and follow-up messages behind the work. -The Agent Management Panel and Oz web app Runs page are designed to answer, at a glance: +The Agent Management Panel and {VARS.WEB_APP} Runs page are designed to answer, at a glance: * Which agents are active or have been running recently. * Which runs are working, blocked, failed, succeeded, or canceled. -* Where an agent run was triggered from, such as a local agent conversation, the Oz CLI, Slack, Linear, a schedule, or the API. +* Where an agent run was triggered from, such as a local agent conversation, the {VARS.WARP_AGENT_CLI}, Slack, Linear, a schedule, or the API. * How parent and child runs relate in orchestrated workflows. * Which session to open when you need prompt, plan, command, log, output, or follow-up context. * How many credits those runs consumed. @@ -34,7 +35,7 @@ These management surfaces include your **local (interactive) agents** and [cloud ### What appears in the agent management surfaces -The Agent Management Panel and Oz web app Runs page include two categories of agent activity. +The Agent Management Panel and {VARS.WEB_APP} Runs page include two categories of agent activity. #### Interactive agents @@ -58,7 +59,7 @@ In the **Personal** tab, you can view all of the interactive and cloud agent con ### Inspect or review an agent run -Use the Agent Management Panel or Oz web app Runs page as the starting point when a teammate asks, "What did the agent do?" +Use the Agent Management Panel or {VARS.WEB_APP} Runs page as the starting point when a teammate asks, "What did the agent do?" 1. In the agents list, use the filter menu to filter by source, day, creator, or status. 2. Select the matching row to open the shared session or local conversation. @@ -81,7 +82,7 @@ Each row represents a single item in the agents list (either an interactive conv Where the agent was launched from. Common sources include: * **Interactive:** an [agent conversation](/agents/getting-started/agents-in-warp/) started in the Warp app -* **CLI**: a local run triggered by the [Oz CLI](/reference/cli/) +* **CLI**: a local run triggered by the [{VARS.WARP_AGENT_CLI}](/reference/cli/) * **API**: a run triggered by [Warp's API](/reference/api-and-sdk/) * **Slack / Linear**: runs triggered by [integrations](/platform/integrations/) * **Scheduled**: runs triggered on a [cron schedule](/platform/triggers/scheduled-agents/) @@ -127,9 +128,9 @@ When a parent agent spawns one or more child agents through [multi-agent orchest * **Local children in the Warp app** - while you're viewing the parent agent, an orchestration pill bar above the agent view header shows one pill per child with a live status badge. Click a child pill to switch the pane to that child's conversation in place; click the parent pill - or the breadcrumb that replaces the pill bar while you're viewing a child - to return. Local children don't appear as separate rows in the Agent Management Panel list. * **Cloud children in the Warp app** - appear in the Agent Management Panel list as their own rows alongside the parent and other runs. Filter by source, status, or creator to isolate them. -* **Cloud children in the [Oz web app](/platform/oz-web-app/)** - grouped under the parent's row on the Runs page, and surfaced together inside the parent's detail pane on a **Sub-agents** tab. +* **Cloud children in the [{VARS.WEB_APP}](/platform/oz-web-app/)** - grouped under the parent's row on the Runs page, and surfaced together inside the parent's detail pane on a **Sub-agents** tab. -The parent's own status reflects only its work - a parent can finish successfully while a child is still running or has failed. To verify that an orchestration completed, check each child individually from the pill bar (in the Warp app) or the **Sub-agents** tab (in the Oz web app). +The parent's own status reflects only its work - a parent can finish successfully while a child is still running or has failed. To verify that an orchestration completed, check each child individually from the pill bar (in the Warp app) or the **Sub-agents** tab (in the {VARS.WEB_APP}). ## Related pages @@ -137,4 +138,4 @@ The parent's own status reflects only its work - a parent can finish successfull * [Multi-agent orchestration](/platform/orchestration/) — Parent/child model, run state transitions, and common orchestration patterns. * [Viewing cloud agent runs](/platform/viewing-cloud-agent-runs/) — Open and inspect a remote cloud agent run. * [Handoff between local and cloud agents](/platform/handoff/) — Move agent work between local and cloud, or continue a finished cloud run. -* [Oz web app](/platform/oz-web-app/) — Manage runs and schedules from any browser. +* [{VARS.WEB_APP}](/platform/oz-web-app/) — Manage runs and schedules from any browser. diff --git a/src/content/docs/platform/mcp.mdx b/src/content/docs/platform/mcp.mdx index 6340c539..a85c529e 100644 --- a/src/content/docs/platform/mcp.mdx +++ b/src/content/docs/platform/mcp.mdx @@ -6,6 +6,7 @@ description: >- sidebar: label: "MCP servers" --- +import { VARS } from '@data/vars'; Cloud agents can call external tools through [Model Context Protocol (MCP) servers](/agents/capabilities/mcp/). This lets agents reach beyond the terminal to automatically interact with systems like GitHub, dbt, Sentry, or any custom internal service, whenever the workflow requires it. @@ -66,7 +67,7 @@ You can define any number of MCP servers in a single config. ``` :::note -If the config passes through a system that pre-processes `{{...}}` before it reaches Oz (for example, Jira/Atlassian Automation), use JSON unicode escapes for the braces: `\u007b\u007bMY_SECRET\u007d\u007d` decodes to `{{MY_SECRET}}`, which Oz resolves normally. +If the config passes through a system that pre-processes `{{...}}` before it reaches {VARS.WARP_AUTOMATION_PLATFORM} (for example, Jira/Atlassian Automation), use JSON unicode escapes for the braces: `\u007b\u007bMY_SECRET\u007d\u007d` decodes to `{{MY_SECRET}}`, which {VARS.WARP_AUTOMATION_PLATFORM} resolves normally. ::: ## Using MCP servers in an agent config file diff --git a/src/content/docs/platform/orchestration/index.mdx b/src/content/docs/platform/orchestration/index.mdx index c1ee4cb7..ca5da2a0 100644 --- a/src/content/docs/platform/orchestration/index.mdx +++ b/src/content/docs/platform/orchestration/index.mdx @@ -1,12 +1,13 @@ --- title: Multi-agent orchestration -description: Coordinate parent and child agents across local and cloud runs to build supervisor/worker, fan-out, critic, DAG, and swarm workflows on the Oz Platform. +description: Coordinate parent and child agents across local and cloud runs to build supervisor/worker, fan-out, critic, DAG, and swarm workflows on the {{WARP_AUTOMATION_PLATFORM}}. sidebar: label: "Orchestration" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -Multi-agent orchestration lets one agent spawn and coordinate other agents to parallelize work, delegate specialized tasks, or verify another agent's output. The parent/child model works from the Warp app, the [Oz CLI](/reference/cli/), and the [Oz API](/reference/api-and-sdk/), and supports local, cloud, and mixed execution. +Multi-agent orchestration lets one agent spawn and coordinate other agents to parallelize work, delegate specialized tasks, or verify another agent's output. The parent/child model works from the Warp app, the [{VARS.WARP_AGENT_CLI}](/reference/cli/), and the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/), and supports local, cloud, and mixed execution. Watch this walkthrough to see how a cloud agent can coordinate a team of agents in the cloud. @@ -21,7 +22,7 @@ An orchestrated workflow always has one **parent agent** and one or more **child * **Parent agent** - the agent that decides what work needs to be done, spawns child agents, and (optionally) merges their results. Any agent can become a parent the first time it spawns a child. * **Child agent** - an agent spawned by a parent with its own prompt, environment, and (optionally) a different model or agent runtime. A child runs its own work and reports back; it does not spawn its own children. -Orchestrations today are exactly one level deep: a parent and its direct children. The Warp app, the [Oz web app](/platform/oz-web-app/), and the [Oz API](/reference/api-and-sdk/) render that single level. The parent and each child each have an independent **run** with its own lifecycle, transcript, conversation, and credit usage. +Orchestrations today are exactly one level deep: a parent and its direct children. The Warp app, the [{VARS.WEB_APP}](/platform/oz-web-app/), and the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) render that single level. The parent and each child each have an independent **run** with its own lifecycle, transcript, conversation, and credit usage. ### Where parent and child agents can run @@ -51,8 +52,8 @@ Track run state transitions in these places: * **The parent's transcript** - the parent agent receives child state transitions as it runs and reflects them in its own conversation. * **The orchestration pill bar** - in the Warp app, while you're viewing the parent agent, a horizontal pill bar above the agent view header shows the parent on the left and one pill per child. Each pill displays the child's name and a status badge that updates live. Click a pill to switch the pane to that child's conversation in place; click the parent pill to switch back. -* **The Oz web app** - cloud children appear under the parent on the [Runs page](https://oz.warp.dev/runs) and in the parent's **Sub-agents** tab, with their status updating live. -* **The Oz API** - `GET /agent/runs/{runId}` returns the latest state of any run, and `GET /agent/runs?ancestor_run_id=PARENT_RUN_ID` lists every descendant in one call. +* **The {VARS.WEB_APP}** - cloud children appear under the parent on the Runs page and in the parent's **Sub-agents** tab, with their status updating live. +* **The {VARS.API_SDK_NAME}** - `GET /agent/runs/{runId}` returns the latest state of any run, and `GET /agent/runs?ancestor_run_id=PARENT_RUN_ID` lists every descendant in one call. ## Messaging between agents @@ -112,14 +113,14 @@ In both cases, approval is required before the parent launches children. Approvi Because every parent and child is tracked as its own conversation or run, the existing observability surfaces work without changes: * **[Managing cloud agents](/platform/managing-cloud-agents/)** - in the Warp app, the orchestration pill bar above the agent view header lets you switch between the parent and each child while you're viewing the parent. Cloud children also appear as their own rows in the Agent Management Panel list. -* **[Oz web app](/platform/oz-web-app/)** - the Runs page groups cloud children under the parent's row, and the parent's detail pane adds a **Sub-agents** tab. -* **[Oz API](/reference/api-and-sdk/)** - list every descendant of a parent in one call and fetch any run with its conversation, transcript, and artifacts. See [Running orchestrated agents](/platform/orchestration/multi-agent-runs/#retrieving-conversations-and-artifacts). +* **[{VARS.WEB_APP}](/platform/oz-web-app/)** - the Runs page groups cloud children under the parent's row, and the parent's detail pane adds a **Sub-agents** tab. +* **[{VARS.API_SDK_NAME}](/reference/api-and-sdk/)** - list every descendant of a parent in one call and fetch any run with its conversation, transcript, and artifacts. See [Running orchestrated agents](/platform/orchestration/multi-agent-runs/#retrieving-conversations-and-artifacts). * **[Agent notifications](/agents/capabilities/agent-notifications/)** - in-app notifications fire on the parent agent's conversation only. Use the pill bar or the **Sub-agents** tab to drill into a specific child. ## Related pages * [Running orchestrated agents](/platform/orchestration/multi-agent-runs/) - how to start an orchestrated run from the CLI, slash command, web app, or API. * [How to run multiple AI coding agents](/guides/agent-workflows/how-to-run-multiple-ai-coding-agents/) - practical guidance for splitting tasks, assigning worktrees, validating child output, and handing work off for review. -* [Oz API and SDK](/reference/api-and-sdk/) - REST endpoints for runs, conversations, and artifacts. -* [Cloud agents overview](/platform/) - what a cloud agent run is and how it fits into the Oz Platform. +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) - REST endpoints for runs, conversations, and artifacts. +* [Cloud agents overview](/platform/) - what a cloud agent run is and how it fits into the {VARS.WARP_AUTOMATION_PLATFORM}. * [Deployment patterns](/platform/deployment-patterns/) - higher-level deployment models that orchestration composes with. diff --git a/src/content/docs/platform/orchestration/multi-agent-runs.mdx b/src/content/docs/platform/orchestration/multi-agent-runs.mdx index 469cc115..4cdcdb3d 100644 --- a/src/content/docs/platform/orchestration/multi-agent-runs.mdx +++ b/src/content/docs/platform/orchestration/multi-agent-runs.mdx @@ -1,12 +1,13 @@ --- title: Running orchestrated agents -description: Start multi-agent orchestrations from the Warp app, the Oz CLI, the Oz web app, or the Oz API, and inspect parent and child conversations and artifacts. +description: Start multi-agent orchestrations from the Warp app, the {{WARP_AGENT_CLI}}, the {{WEB_APP}}, or the {{API_SDK_NAME}}, and inspect parent and child conversations and artifacts. sidebar: label: "Running orchestrated agents" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -An orchestrated run starts with a parent agent that spawns one or more child agents. You can start a parent from the Warp app, the Oz CLI, the Oz web app, or the Oz API. Use orchestrated runs to review a plan before fan-out, execute children locally or in the cloud, and inspect parent and child conversations as they work. +An orchestrated run starts with a parent agent that spawns one or more child agents. You can start a parent from the Warp app, the {VARS.WARP_AGENT_CLI}, the {VARS.WEB_APP}, or the {VARS.API_SDK_NAME}. Use orchestrated runs to review a plan before fan-out, execute children locally or in the cloud, and inspect parent and child conversations as they work. Watch this walkthrough to see how to start and inspect an orchestrated agent run from Warp. @@ -17,7 +18,7 @@ Watch this walkthrough to see how to start and inspect an orchestrated agent run Pick where the parent will run. Every orchestration starts with a single parent that spawns children: * **Parent in the Warp app** - use the `/orchestrate` or `/plan` slash command. This is the fastest way to try orchestration. -* **Parent in the cloud** - trigger the parent through the Oz CLI (`oz agent run-cloud`), the [Oz API](/reference/api-and-sdk/), or any integration (Slack, Linear, schedule). The parent runs in an environment and spawns children from there. +* **Parent in the cloud** - trigger the parent through the {VARS.WARP_AGENT_CLI} (`oz agent run-cloud`), the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/), or any integration (Slack, Linear, schedule). The parent runs in an environment and spawns children from there. Cloud parents that spawn cloud children need access to one or more [environments](/platform/environments/) the children can run in. @@ -63,9 +64,9 @@ This is the recommended way to fan work out from the CLI: the parent decides how If you need to fan out from a script and want each child linked to a specific parent, use the [API](#starting-an-orchestrated-run-from-the-api). `oz agent run-cloud` doesn't currently accept a parent run ID flag, so script-launched runs from the CLI are independent runs. ::: -## Starting an orchestrated run from the Oz web app +## Starting an orchestrated run from the web app -In the Oz web app's [**Runs** page](https://oz.warp.dev/runs): +In the {VARS.WEB_APP}'s **Runs** page: 1. Click **New run** in the header. 2. Select an environment and, optionally, a skill that performs orchestration. @@ -118,7 +119,7 @@ Content-Type: application/json } ``` -Setting `parent_run_id` is what links the child to its parent across the Agent Management Panel in the Warp app, the Oz web app Runs page, and the descendants query (`?ancestor_run_id=`). +Setting `parent_run_id` is what links the child to its parent across the Agent Management Panel in the Warp app, the {VARS.WEB_APP} Runs page, and the descendants query (`?ancestor_run_id=`). A scripted fan-out, including parent linking, looks like this: @@ -148,7 +149,7 @@ done ## Retrieving conversations and artifacts -Every parent and child started through the Oz API is tracked as an Oz run. Run responses include the run's `state`, `parent_run_id` (set on children only), `conversation_id`, `session_link`, and an `artifacts` array of any pull requests, plans, screenshots, or files the run produced. Use the same endpoints you'd use for any other run: +Every parent and child started through the {VARS.API_SDK_NAME} is tracked as a {VARS.PLATFORM_RUN}. Run responses include the run's `state`, `parent_run_id` (set on children only), `conversation_id`, `session_link`, and an `artifacts` array of any pull requests, plans, screenshots, or files the run produced. Use the same endpoints you'd use for any other run: * **List every descendant of a parent** - `GET /api/v1/agent/runs?ancestor_run_id=YOUR_PARENT_RUN_ID`. From the CLI: `oz run list --ancestor-run YOUR_PARENT_RUN_ID`. * **Get one run's details and artifacts** - `GET /api/v1/agent/runs/YOUR_RUN_ID`. @@ -190,7 +191,7 @@ Self-hosted, local, and GitHub Action runs cannot be cancelled through this endp * [Multi-agent orchestration](/platform/orchestration/) - parent/child model, run state transitions, and common patterns. * [How to run multiple AI coding agents](/guides/agent-workflows/how-to-run-multiple-ai-coding-agents/) - practical task decomposition, worktree ownership, validation, and review handoff guidance. -* [Oz CLI](/reference/cli/) - command reference for `oz agent run-cloud` and `oz run`. -* [Oz API and SDK](/reference/api-and-sdk/) - full HTTP reference and typed SDKs. -* [Managing cloud agents](/platform/managing-cloud-agents/) - how parent and child runs appear in the Agent Management Panel in the Warp app and the Runs page in the Oz web app. +* [{VARS.WARP_AGENT_CLI}](/reference/cli/) - command reference for `oz agent run-cloud` and `oz run`. +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) - full HTTP reference and typed SDKs. +* [Managing cloud agents](/platform/managing-cloud-agents/) - how parent and child runs appear in the Agent Management Panel in the Warp app and the Runs page in the {VARS.WEB_APP}. * [Environments](/platform/environments/) - configure the runtime context cloud children execute in. diff --git a/src/content/docs/platform/overview.mdx b/src/content/docs/platform/overview.mdx index bc3b4746..7a3cf942 100644 --- a/src/content/docs/platform/overview.mdx +++ b/src/content/docs/platform/overview.mdx @@ -1,14 +1,15 @@ --- -title: Oz Platform overview +title: "{{WARP_AUTOMATION_PLATFORM}} overview" description: >- - The Oz Platform provides the CLI, API/SDK, orchestration, environments, and + The {{WARP_AUTOMATION_PLATFORM}} provides the CLI, API/SDK, orchestration, environments, and observability for cloud agents. sidebar: - label: "Oz platform" + label: "{{WARP_AUTOMATION_PLATFORM}}" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -Cloud agents run on the **Oz Platform**. The platform gives you a consistent way to **trigger work**, **orchestrate and track tasks**, **execute agents** (in an optional [environment](/platform/environments/), on a host), and inspect outcomes with team visibility. First-party [integrations](/platform/integrations/) connect external events — like Slack messages, GitHub PRs, or CI failures — to cloud agents automatically. +Cloud agents run on the **{VARS.WARP_AUTOMATION_PLATFORM}**. The platform gives you a consistent way to **trigger work**, **orchestrate and track tasks**, **execute agents** (in an optional [environment](/platform/environments/), on a host), and inspect outcomes with team visibility. First-party [integrations](/platform/integrations/) connect external events — like Slack messages, GitHub PRs, or CI failures — to cloud agents automatically. @@ -27,7 +28,7 @@ Cloud agents run on the **Oz Platform**. The platform gives you a consistent way ![Oz Platform detailed architecture showing components, triggers, orchestrator, and agent runners](../../../assets/agent-platform/oz-diagram.png) -The sections below describe the Oz Platform primitives that power this flow, and how they compose. +The sections below describe the {VARS.WARP_AUTOMATION_PLATFORM} primitives that power this flow, and how they compose. --- @@ -44,9 +45,9 @@ In practice: **triggers create tasks; tasks execute on a host (optionally in an --- -### Oz CLI +### CLI -The [Oz CLI](/reference/cli/) is the **headless interface** for running agents in non-interactive mode. It's commonly used in CI, scripts, and server environments where there is no interactive UI. For interactive workflows, use the [agent](/agents/getting-started/agents-in-warp/) embedded in Warp's desktop app. +The [{VARS.WARP_AGENT_CLI}](/reference/cli/) is the **headless interface** for running agents in non-interactive mode. It's commonly used in CI, scripts, and server environments where there is no interactive UI. For interactive workflows, use the [agent](/agents/getting-started/agents-in-warp/) embedded in Warp's desktop app. A key property of the CLI is that it is **cloud-connected**. Even when an agent is started on a local machine or in CI, it reports progress to Warp’s servers. This enables team visibility, session sharing (where supported), and programmatic tracking through the API. @@ -58,7 +59,7 @@ Use the CLI when: * An external system is orchestrating runs (for example GitHub Actions, custom automation, incident tooling). * You want task observability and auditing without requiring Warp desktop. -#### How it fits in the Oz Platform +#### How the CLI fits into cloud agent runs Depending on the command, the CLI typically: @@ -88,7 +89,7 @@ The orchestrator: * Runs on Warp's servers (cloud control plane). * Creates tasks when triggers fire (integrations, schedules, API calls, or explicit starts). * Tracks lifecycle state (created → running → completed/failed) and associated metadata. -* Exposes task lifecycle operations via the [Oz CLI](/reference/cli/) and a [REST API](/reference/api-and-sdk/) (create tasks, query history, and inspect status/outputs). +* Exposes task lifecycle operations via the [{VARS.WARP_AGENT_CLI}](/reference/cli/) and a [REST API](/reference/api-and-sdk/) (create tasks, query history, and inspect status/outputs). * Powers SDKs (TypeScript/Python) for programmatic usage on top of the orchestrator API. * Supports [multi-agent orchestration](/platform/orchestration/) for parent/child workflows, fan-out, and review swarms. @@ -133,9 +134,9 @@ Environments are recommended when: --- -### Oz API and SDK +### API and SDK -The Oz [Agent API](/reference/api-and-sdk/) is the HTTP interface to the Oz Platform. It lets you create and inspect cloud agent tasks from any system (CI, cron, backend services, internal tools), without requiring the Warp desktop app. +The {VARS.WARP_AUTOMATION_PLATFORM} [Agent API](/reference/api-and-sdk/) is the HTTP interface to the {VARS.WARP_AUTOMATION_PLATFORM}. It lets you create and inspect cloud agent tasks from any system (CI, cron, backend services, internal tools), without requiring the Warp desktop app. **What you can do with the API** @@ -143,9 +144,9 @@ The Oz [Agent API](/reference/api-and-sdk/) is the HTTP interface to the Oz Plat * Monitor execution by listing tasks and tracking state transitions over time (for example: `QUEUED` → `INPROGRESS` → `SUCCEEDED/FAILED`). * Inspect results and provenance by fetching a task’s full details, including the original prompt, creator/source metadata, session link, and resolved agent configuration. -**Oz SDKs** +**SDKs** -Oz provides official [Python](https://github.com/warpdotdev/oz-sdk-python) and [TypeScript SDKs](https://github.com/warpdotdev/oz-sdk-typescript) that wrap the Oz API with: +Warp provides official [Python](https://github.com/warpdotdev/oz-sdk-python) and [TypeScript SDKs](https://github.com/warpdotdev/oz-sdk-typescript) that wrap the {VARS.API_SDK_NAME} with: * Typed requests/responses (autocomplete, fewer schema mistakes) * Built-in retries and timeouts (with per-request overrides) @@ -182,7 +183,7 @@ With Warp hosting: With self-hosting: * The agent runs on customer-managed infrastructure. -* Oz orchestrator still manages lifecycle and observability. +* {VARS.WARP_AUTOMATION_PLATFORM} orchestrator still manages lifecycle and observability. * This is used when teams want code and execution to remain on their own systems rather than being cloned or executed in Warp's cloud. :::note @@ -218,7 +219,7 @@ Examples of context extracted by first-party integrations: #### Custom integrations -With custom integrations, you own the webhook and event-handling logic. Your system receives an event, applies any filtering or enrichment you need, and then calls the Oz API (directly or via an SDK) to create a task. The resulting task is still a full cloud agent run — observable, manageable, and auditable like any other. +With custom integrations, you own the webhook and event-handling logic. Your system receives an event, applies any filtering or enrichment you need, and then calls the API (directly or via an SDK) to create a task. The resulting task is still a full cloud agent run — observable, manageable, and auditable like any other. Custom integrations are a good fit when: @@ -283,12 +284,12 @@ Warp supports centralized configuration so these settings apply consistently reg This is especially useful when the same workflow can be triggered from multiple places (for example Slack, CI, and schedules). Instead of duplicating setup across systems, teams can keep configuration in one place and reuse it across triggers. -### Using the Oz Platform with or without the Warp app +### Using cloud agents with or without the Warp app [Cloud agents](/platform/) do not require Warp's desktop terminal. Teams can operate cloud agent workflows using: -* [Oz CLI](/reference/cli/) — run agents from scripts, CI, or the terminal -* [Oz web app](/platform/oz-web-app/) — visual interface for managing runs, schedules, environments, and integrations from any browser, including mobile +* [{VARS.WARP_AGENT_CLI}](/reference/cli/) — run agents from scripts, CI, or the terminal +* [{VARS.WEB_APP}](/platform/oz-web-app/) — visual interface for managing runs, schedules, environments, and integrations from any browser, including mobile * [Session sharing](/agents/local-agents/session-sharing/) — attach to running tasks to monitor or steer * [Management UI](/platform/managing-cloud-agents/) — view agent activity and run history * [APIs and SDKs](/reference/api-and-sdk/) — programmatic access for custom integrations diff --git a/src/content/docs/platform/oz-web-app.mdx b/src/content/docs/platform/oz-web-app.mdx index 58acab47..0de20d56 100644 --- a/src/content/docs/platform/oz-web-app.mdx +++ b/src/content/docs/platform/oz-web-app.mdx @@ -1,21 +1,22 @@ --- -title: Oz web app for cloud agents +title: "{{WEB_APP}} for cloud agents" description: >- - Use the Oz web app to manage cloud agents, view runs, create schedules, and + Use the {{WEB_APP}} to manage cloud agents, view runs, create schedules, and configure environments and integrations from any browser or mobile device. sidebar: - label: "Oz web app" + label: "{{WEB_APP}}" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -The [Oz web app](https://oz.warp.dev) provides a visual interface for managing cloud agents. You can start runs, browse agents and skills, create schedules, configure environments, and set up integrations—all without installing Warp or using the CLI. +The {VARS.WEB_APP} provides a visual interface for managing cloud agents. You can start runs, browse agents and skills, create schedules, configure environments, and set up integrations—all without installing Warp or using the CLI. :::note -The Oz web app works on mobile devices, so you can monitor and manage your cloud agents from anywhere. +The {VARS.WEB_APP} works on mobile devices, so you can monitor and manage your cloud agents from anywhere. ::: -Watch this short demo to create an environment and run an agent using the Oz web app: - +Watch this short demo to create an environment and run an agent using the {VARS.WEB_APP}: + ## Quick reference @@ -28,7 +29,7 @@ Watch this short demo to create an environment and run an agent using the Oz web ## When to use the web app -The Oz web app is ideal when you want to: +The {VARS.WEB_APP} is ideal when you want to: * **Monitor agent activity** — View runs, check status, and inspect outputs from any device * **Start quick runs** — Dispatch agents without opening a terminal @@ -37,17 +38,17 @@ The Oz web app is ideal when you want to: * **Configure environments** — Set up repos, Docker images, and setup commands through a form-based flow * **Set up integrations** — Connect Slack and Linear with a guided setup flow, and configure how [GitHub](/platform/integrations/github/) mention-triggered runs execute -For scripting, automation, and CI/CD workflows, use the [Oz CLI](/reference/cli/) or [API](/reference/api-and-sdk/). +For scripting, automation, and CI/CD workflows, use the [{VARS.WARP_AGENT_CLI}](/reference/cli/) or [API](/reference/api-and-sdk/). ## Getting started -When you first sign in to the Oz web app, you'll see a guided onboarding flow that helps you get started based on your goals. +When you first sign in to the {VARS.WEB_APP}, you'll see a guided onboarding flow that helps you get started based on your goals. -The onboarding asks "What brings you to Oz?" and offers three paths: +The onboarding asks "What brings you to {VARS.WARP_AUTOMATION_PLATFORM}?" and offers three paths: * **Create an agent automation** — Walks you through setting up a scheduled agent, integration-triggered agent, or other automation * **Run Cloud Agents in Warp** — Opens the Warp app (or takes you to the download page) to run cloud agents interactively -* **Build an app that uses agents** — Links to the [Oz Platform](/platform/overview/) docs for using the CLI, SDK, or API +* **Build an app that uses agents** — Links to the [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) docs for using the CLI, SDK, or API You can skip onboarding at any time to go directly to the Runs page. @@ -82,7 +83,7 @@ To start a new run: ### Inspecting orchestrated runs -The Oz web app renders [multi-agent orchestrations](/platform/orchestration/) as nested rows on the **Runs** page, so you can follow parent and child execution together. +The {VARS.WEB_APP} renders [multi-agent orchestrations](/platform/orchestration/) as nested rows on the **Runs** page, so you can follow parent and child execution together. Open a parent run from the Runs page. When the run has children, the detail pane adds a **Sub-agents** tab next to **Details**: @@ -147,7 +148,7 @@ To create a skill for agents:
Creating a skill in the Oz web app.
-After the PR is merged, refresh skills so the new skill appears in the Oz web app. +After the PR is merged, refresh skills so the new skill appears in the {VARS.WEB_APP}. ## Schedules @@ -225,7 +226,7 @@ The **Integrations** page (`/integrations`) lets you configure first-party integ ### Available integrations -
IntegrationDescription
SlackTag @Oz in messages or threads to trigger agents directly from Slack conversations
LinearTag @Oz on issues to trigger agents from your issue tracker
GitHubMention @oz-agent on issues, pull requests, and review comments to trigger agents from GitHub
+
IntegrationDescription
SlackTag @{VARS.WARP_AUTOMATION_PLATFORM} in messages or threads to trigger agents directly from Slack conversations
LinearTag @{VARS.WARP_AUTOMATION_PLATFORM} on issues to trigger agents from your issue tracker
GitHubMention @oz-agent on issues, pull requests, and review comments to trigger agents from GitHub
![The Integrations page in the Oz web app.](../../../assets/agent-platform/oz-web-app-integrations.png) @@ -250,5 +251,5 @@ For detailed integration setup instructions, see [Slack](/platform/integrations/ * [Scheduled Agents](/platform/triggers/scheduled-agents/) — Run agents automatically on a cron schedule * [Environments](/platform/environments/) — Configure runtime context for cloud agents * [Managing Cloud Agents](/platform/managing-cloud-agents/) — Monitor agent activity and inspect runs -* [Oz CLI](/reference/cli/) — Command-line interface for running agents -* [Oz API & SDK](/reference/api-and-sdk/) — Programmatic access to cloud agents +* [{VARS.WARP_AGENT_CLI}](/reference/cli/) — Command-line interface for running agents +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) — Programmatic access to cloud agents diff --git a/src/content/docs/platform/quickstart.mdx b/src/content/docs/platform/quickstart.mdx index 6a264a51..03b43c24 100644 --- a/src/content/docs/platform/quickstart.mdx +++ b/src/content/docs/platform/quickstart.mdx @@ -7,8 +7,9 @@ description: >- sidebar: label: "Quickstart" --- +import { VARS } from '@data/vars'; -**Cloud agents** run in a remote environment and can be triggered from events, schedules, integrations, or manually. This enables scaling agents off your laptop, automating development tasks, and building apps on top of agents. Oz handles the orchestration, execution, and observability. +**Cloud agents** run in a remote environment and can be triggered from events, schedules, integrations, or manually. This enables scaling agents off your laptop, automating development tasks, and building apps on top of agents. {VARS.WARP_AUTOMATION_PLATFORM} handles the orchestration, execution, and observability. Cloud agents can run interactively (where you steer them in real-time) or autonomously (as background tasks). Each run creates a persistent session that your team can inspect, share, and query through the Warp app, the CLI, web app, or API. @@ -27,7 +28,7 @@ This guide walks you through running your first cloud agent with an environment Before you begin, make sure you have: * **Warp desktop app** - Download from the [Warp website](https://www.warp.dev) -* **Warp account** - Create an account from the [Oz web app](https://oz.warp.dev) +* **Warp account** - Create an account from the {VARS.WEB_APP} :::note New to Warp? You'll get credits to try cloud agents. You need at least 20 credits available to run cloud agents and integrations. @@ -84,8 +85,8 @@ You can continue conversing with the agent in real-time, watch its progress, and You can view details of your agent's run, including commands executed, files changed, and environment used, several different ways: * In the Warp app, open the [conversations panel](/agents/local-agents/interacting-with-agents/#conversation-panel) to see all your agent runs. * Click the session link in your terminal output. -* Go to the [Oz web app](https://oz.warp.dev) and navigate to the **Runs** tab. -* Access from mobile via the [Oz web app](/platform/oz-web-app/). +* Go to the {VARS.WEB_APP} and navigate to the **Runs** tab. +* Access from mobile via the [{VARS.WEB_APP}](/platform/oz-web-app/). **Breaking it down:** Every cloud agent run is auto-tracked. You get a shareable link, a run record, and full visibility into what the agent did. You or your teammates can watch the agent's progress in real-time and even steer it if needed. The run record persists after completion so you can review it later. @@ -101,7 +102,7 @@ Follow the prompts to save your task definition. Once created, you can run it ag **How this works:** Skills capture successful agent workflows as reusable building blocks. Instead of typing the same prompt repeatedly, you define it once. You can use it yourself, share it with teammates, schedule it to run automatically, or trigger it from integrations. Learn more about [Skills as Agents](/platform/skills-as-agents/). -**Prefer using the CLI?** See the [Oz CLI quickstart](/reference/cli/quickstart/) for CLI-based workflows. +**Prefer using the CLI?** See the [{VARS.WARP_AGENT_CLI} quickstart](/reference/cli/quickstart/) for CLI-based workflows. --- @@ -110,10 +111,10 @@ Follow the prompts to save your task definition. Once created, you can run it ag Now that you've run your first cloud agent, try these next steps: * [**Schedule recurring work**](/platform/triggers/scheduled-agents-quickstart/) - Create a scheduled agent for maintenance tasks like dependency checks, cleanup, or triage. -* [**Trigger agents from Slack or Linear**](/platform/integrations/quickstart/) - Connect Oz to team tools so mentions and issue updates can launch cloud agent runs. +* [**Trigger agents from Slack or Linear**](/platform/integrations/quickstart/) - Connect Warp to team tools so mentions and issue updates can launch cloud agent runs. * [**Orchestrate multiple agents**](/platform/orchestration/multi-agent-runs/) - Fan work out across parent and child agents for large refactors, PR review swarms, and parallel package migrations. * [**Turn successful prompts into reusable skills**](/platform/skills-as-agents/) - Save repeatable agent workflows and run them again from the CLI, web app, API, or a schedule. -* [**Build programmatic automations**](/reference/api-and-sdk/quickstart/) - Start cloud agent runs from your own systems with the Oz API or SDKs. +* [**Build programmatic automations**](/reference/api-and-sdk/quickstart/) - Start cloud agent runs from your own systems with the {VARS.API_SDK_NAME}. For example, schedule a recurring agent from the CLI: diff --git a/src/content/docs/platform/runners.mdx b/src/content/docs/platform/runners.mdx index 70b33fe3..25620b55 100644 --- a/src/content/docs/platform/runners.mdx +++ b/src/content/docs/platform/runners.mdx @@ -6,6 +6,7 @@ description: >- Runners define the OS, architecture, instance size, and sandbox image cloud agents run on, managed with the {{WARP_AGENT_CLI}}. --- +import { VARS } from '@data/vars'; Runners define the compute a [cloud agent](/platform/) runs on: the operating system, CPU architecture, instance size, and sandbox image used to execute a run. @@ -24,7 +25,7 @@ What runners give you: * **Flexible OS targets** – Run agents on Linux with a custom Docker image. macOS runners are in limited preview. * **Independent of environments** – Override an environment's default runner per run without changing the environment itself. -## How runners fit into the Oz Platform +## How runners fit into cloud agent runs A runner is the compute layer for a cloud agent run. When a run starts, Warp provisions a sandbox on the runner's shape, then prepares the workspace defined by the environment (cloning repos and executing setup commands) before the agent begins. @@ -36,7 +37,7 @@ Each environment has a default runner. Specifying a runner for a run overrides t ## Managing runners with the CLI -Use the [Oz CLI](/reference/cli/) to create, list, update, and delete runners. Runner commands require an authenticated CLI—see the [CLI quickstart](/reference/cli/quickstart/) to get set up. +Use the [{VARS.WARP_AGENT_CLI}](/reference/cli/) to create, list, update, and delete runners. Runner commands require an authenticated CLI—see the [CLI quickstart](/reference/cli/quickstart/) to get set up. ### Create a runner @@ -117,4 +118,4 @@ You can also select a runner when [running orchestrated agents](/platform/orches * [Environments](/platform/environments/) – Define the repos, image, and setup commands an agent works with. * [Managing cloud agents](/platform/managing-cloud-agents/) – Start, monitor, and manage cloud agent runs. -* [Oz CLI reference](/reference/cli/) – Full command-line reference for the Oz platform. +* [{VARS.WARP_AGENT_CLI} reference](/reference/cli/) – Full command-line reference for the {VARS.WARP_AUTOMATION_PLATFORM}. diff --git a/src/content/docs/platform/secrets.mdx b/src/content/docs/platform/secrets.mdx index 76bf48a5..48e427b8 100644 --- a/src/content/docs/platform/secrets.mdx +++ b/src/content/docs/platform/secrets.mdx @@ -6,6 +6,7 @@ description: >- Securely store, scope, and inject credentials for Warp cloud agents across CLI, Slack, Linear, and scheduled runs—without ever exposing secret values. --- +import { VARS } from '@data/vars'; Cloud agents often need to interact with external systems such as APIs, databases, cloud providers, or internal tooling. To do this safely, Warp provides Warp-managed **agent secrets**, a secure way to store, scope, and inject credentials into cloud agent runs without exposing secret values to users or logs. @@ -82,13 +83,13 @@ Personal secrets belong to an **individual user**. --- -## Creating secrets in the Oz web app +## Creating secrets in the web app -The [Oz web app](/platform/oz-web-app/) provides a guided side pane for creating Warp-managed secrets. Use it when you want a point-and-click flow without leaving the browser; the CLI flow below remains available for scripting and automation. +The [{VARS.WEB_APP}](/platform/oz-web-app/) provides a guided side pane for creating Warp-managed secrets. Use it when you want a point-and-click flow without leaving the browser; the CLI flow below remains available for scripting and automation. To create a secret in the web app: -1. In the Oz web app (oz.warp.dev), open the **Secrets** page. +1. In the {VARS.WEB_APP} ({VARS.WEB_APP_URL}), open the **Secrets** page. 2. Click **Add secret** to open the **Add secret** side pane. 3. Enter a **Name** (for example, `OPENAI_API_KEY`). This becomes the environment variable name injected into runs. 4. Enter the **Value**. The value is encrypted in your browser before it is sent to the server; Warp never sees the plaintext. @@ -100,7 +101,7 @@ The new secret appears in the Secrets list immediately. Its value is never reada --- -## Managing agent secrets with the Oz CLI +## Managing agent secrets with the CLI Secrets are managed using the `oz secret` command family. @@ -221,7 +222,7 @@ Which secrets an agent receives depends on how the agent was triggered. When an agent is triggered by a specific user, such as: -* Oz CLI +* {VARS.WARP_AGENT_CLI} * Slack mentions * Linear updates @@ -257,9 +258,9 @@ A [cloud environment](/platform/environments/) can declare its own list of secre #### Attach secrets to an environment -Use the environment form in the [Oz web app](/platform/oz-web-app/) to attach secrets to an environment: +Use the environment form in the [{VARS.WEB_APP}](/platform/oz-web-app/) to attach secrets to an environment: -1. In the Oz web app (oz.warp.dev), open the **Environments** page. +1. In the {VARS.WEB_APP} ({VARS.WEB_APP_URL}), open the **Environments** page. 2. Click an existing environment to edit it, or click **New environment** to create one. 3. In the environment form, open the **Secrets** section. 4. Select the team and personal secrets the environment should contribute to each run. Only secret names already in your scope are selectable; values are never displayed. @@ -281,7 +282,7 @@ Individual runs can override which secrets the run receives by listing them on t * **Explicit list of secret names** - Only the listed secrets are injected. Any other secrets the caller can access are skipped for this run. * **Empty list** - The run opts out of all secret injection. No managed secrets are injected, even for triggers that would otherwise receive them. -Run-level scoping is exposed through the public REST API on the run config. See the [Oz API & SDK reference](/reference/api-and-sdk/) for the exact field and shape. +Run-level scoping is exposed through the public REST API on the run config. See the [{VARS.API_SDK_NAME} reference](/reference/api-and-sdk/) for the exact field and shape. :::note Secret names that don't exist in the caller's scope are silently skipped at injection time rather than failing the run. The run detail view surfaces any references that were requested but not resolved so you can spot typos or stale names. diff --git a/src/content/docs/platform/self-hosting/index.mdx b/src/content/docs/platform/self-hosting/index.mdx index 34a4714a..5cc939db 100644 --- a/src/content/docs/platform/self-hosting/index.mdx +++ b/src/content/docs/platform/self-hosting/index.mdx @@ -2,9 +2,10 @@ title: Self-hosting overview description: >- Run cloud agents on your own infrastructure. Choose between a managed - worker daemon orchestrated by Oz or unmanaged CLI-based execution you + worker daemon orchestrated by {{WARP_AUTOMATION_PLATFORM}} or unmanaged CLI-based execution you control. --- +import { VARS } from '@data/vars'; Self-hosting lets your team run cloud agent workloads on your own infrastructure instead of Warp-managed servers. You control the execution environment, compute resources, and network access. Repository clones, source files, build artifacts, runtime secrets, and agent execution workspaces stay on your infrastructure, and agents can reach services behind your VPN or firewall. @@ -20,14 +21,14 @@ Self-hosting lets your team run cloud agent workloads on your own infrastructure Self-hosting has two architectures. The core distinction is **who orchestrates agent runs** — not who owns the compute. Both models keep code and execution on your infrastructure. -* **Managed** — Oz orchestrates agent runs. You run the `oz-agent-worker` daemon on your infrastructure; it connects to Oz and waits for work. Slack mentions, Linear comments, schedules, API calls, and `oz agent run-cloud` commands all route tasks to your worker, which executes them in isolated Docker containers, Kubernetes Jobs, or directly on the host. Similar to a [GitHub self-hosted runner](https://docs.github.com/en/actions/hosting-your-own-runners). -* **Unmanaged** — You orchestrate agent runs. You invoke `oz agent run` directly from your existing CI pipeline, Kubernetes pod, VM, or dev box. Oz provides session tracking and observability for each run, but does not start or stop agents for you. +* **Managed** — {VARS.WARP_AUTOMATION_PLATFORM} orchestrates agent runs. You run the `oz-agent-worker` daemon on your infrastructure; it connects to {VARS.WARP_AUTOMATION_PLATFORM} and waits for work. Slack mentions, Linear comments, schedules, API calls, and `oz agent run-cloud` commands all route tasks to your worker, which executes them in isolated Docker containers, Kubernetes Jobs, or directly on the host. Similar to a [GitHub self-hosted runner](https://docs.github.com/en/actions/hosting-your-own-runners). +* **Unmanaged** — You orchestrate agent runs. You invoke `oz agent run` directly from your existing CI pipeline, Kubernetes pod, VM, or dev box. {VARS.WARP_AUTOMATION_PLATFORM} provides session tracking and observability for each run, but does not start or stop agents for you. ### At a glance | Aspect | **Managed** | **Unmanaged** | | --- | --- | --- | -| **Who triggers runs** | Oz (Slack, Linear, schedules, API, `run-cloud`) | Your system (CI, cron, scripts) | +| **Who triggers runs** | {VARS.WARP_AUTOMATION_PLATFORM} (Slack, Linear, schedules, API, `run-cloud`) | Your system (CI, cron, scripts) | | **What runs on your infra** | Long-lived `oz-agent-worker` daemon | One-shot `oz agent run` invocations | | **OS support** | Linux (macOS/Windows coming) | Linux, macOS, Windows | | **Execution isolation** | Docker container, Kubernetes Job, or direct host | Whatever your host provides | @@ -46,7 +47,7 @@ If your security requirement is "repository clones and execution must stay on ou With any self-hosted architecture: -* **Agent runs are tracked and steerable** — View status, metadata, and session transcripts in the [Oz dashboard](https://oz.warp.dev), the Warp app, or via the [API/SDK](/reference/api-and-sdk/). Authorized teammates can attach to running sessions to monitor or steer agents. +* **Agent runs are tracked and steerable** — View status, metadata, and session transcripts in the {VARS.DASHBOARD}, the Warp app, or via the [API/SDK](/reference/api-and-sdk/). Authorized teammates can attach to running sessions to monitor or steer agents. * **Connectivity to Warp's backend is required** — Agents need outbound access to Warp for orchestration, session storage, and LLM inference. No inbound ports need to be opened. * **Resource limits are controlled by your infrastructure** — Concurrency and compute are only limited by the machines you provision, not by Warp. @@ -67,7 +68,7 @@ Use these questions to decide between managed and unmanaged: 1. **Do you need agents to run on Windows or macOS?** * Yes → Use the [unmanaged](/platform/self-hosting/unmanaged/) architecture. Managed is Linux-only today. * No, Linux works → Continue to the next question. -2. **Do you want Oz to handle starting and stopping agents** (from Slack, the web interface, the Warp app, schedules, or the API)? +2. **Do you want {VARS.WARP_AUTOMATION_PLATFORM} to handle starting and stopping agents** (from Slack, the web interface, the Warp app, schedules, or the API)? * Yes → Use the [managed](#managed-architecture) architecture. * No, you have your own triggering mechanism → Use the [unmanaged](/platform/self-hosting/unmanaged/) architecture. 3. **Can your development environment run in a Docker container or Kubernetes pod?** @@ -99,13 +100,13 @@ The managed architecture supports three backends for task execution: ## Managed architecture -With the managed architecture, you run the `oz-agent-worker` daemon on your infrastructure. The daemon connects to Oz's backend, waits for tasks to be assigned to it, and executes those tasks on its host using one of three backends: +With the managed architecture, you run the `oz-agent-worker` daemon on your infrastructure. The daemon connects to {VARS.WARP_AUTOMATION_PLATFORM}'s backend, waits for tasks to be assigned to it, and executes those tasks on its host using one of three backends: * **[Docker backend](/platform/self-hosting/managed-docker/)** (default) — Runs each task in an isolated Docker container. * **[Kubernetes backend](/platform/self-hosting/managed-kubernetes/)** — Runs each task as a Kubernetes Job in your cluster. * **[Direct backend](/platform/self-hosting/managed-direct/)** — Runs each task directly on the host without a container runtime. -The managed architecture enables full orchestration by Oz — it can remotely start agents via Slack, Linear, the [Oz web app](https://oz.warp.dev), the API/SDK, and the `oz agent run-cloud` command. Agents can access host resources through volume mounts (Docker), Kubernetes-native configuration (Kubernetes), and injected environment variables. +The managed architecture enables full orchestration by {VARS.WARP_AUTOMATION_PLATFORM} — it can remotely start agents via Slack, Linear, the {VARS.WEB_APP}, the API/SDK, and the `oz agent run-cloud` command. Agents can access host resources through volume mounts (Docker), Kubernetes-native configuration (Kubernetes), and injected environment variables. ## Unmanaged architecture @@ -158,7 +159,7 @@ All tasks created through that integration route to your self-hosted worker. ### From the API and SDKs -When creating a run via the [Oz API](/reference/api-and-sdk/), include `worker_host` in the config: +When creating a run via the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/), include `worker_host` in the config: ```bash curl -X POST https://app.warp.dev/api/v1/agent/run \ @@ -175,7 +176,7 @@ curl -X POST https://app.warp.dev/api/v1/agent/run \ ### From the web UI -When creating a run, schedule, or integration in the [Oz web app](https://oz.warp.dev), select your self-hosted worker from the host dropdown. +When creating a run, schedule, or integration in the {VARS.WEB_APP}, select your self-hosted worker from the host dropdown. --- @@ -197,9 +198,9 @@ Musl-based Docker images (such as Alpine Linux) are not supported as task images Self-hosted runs have the same observability as Warp-hosted runs: -* **Oz dashboard** — View task status, history, and metadata from the [Oz web app](https://oz.warp.dev). +* **{VARS.DASHBOARD}** — View task status, history, and metadata from the {VARS.WEB_APP}. * **Session sharing** — Authorized teammates can attach to running tasks to monitor progress. -* **APIs and SDKs** — Query task history and build monitoring using the [Oz API](/reference/api-and-sdk/). +* **APIs and SDKs** — Query task history and build monitoring using the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/). For infrastructure-level observability, the `oz-agent-worker` daemon can export OpenTelemetry metrics (worker health, task throughput, capacity saturation) to Prometheus, an OTLP collector, or the console. See [Monitoring](/platform/self-hosting/monitoring/) for setup, the full metric catalog, and sample PromQL queries. diff --git a/src/content/docs/platform/self-hosting/managed-direct.mdx b/src/content/docs/platform/self-hosting/managed-direct.mdx index e1b744e9..52f76866 100644 --- a/src/content/docs/platform/self-hosting/managed-direct.mdx +++ b/src/content/docs/platform/self-hosting/managed-direct.mdx @@ -1,13 +1,14 @@ --- title: "Managed: Direct backend" description: >- - Run the Oz managed worker with the Direct backend to execute cloud agent + Run the {{WARP_AUTOMATION_PLATFORM}} managed worker with the Direct backend to execute cloud agent tasks directly on the host, without Docker or Kubernetes. sidebar: label: "Managed: Direct" --- +import { VARS } from '@data/vars'; -Run the `oz-agent-worker` daemon with the **Direct backend** — tasks execute directly on the worker host without Docker or Kubernetes. Oz still orchestrates runs end to end (Slack, Linear, schedules, API, `oz agent run-cloud`); the worker just runs the agent in a per-task workspace on its own filesystem. +Run the `oz-agent-worker` daemon with the **Direct backend** — tasks execute directly on the worker host without Docker or Kubernetes. {VARS.WARP_AUTOMATION_PLATFORM} still orchestrates runs end to end (Slack, Linear, schedules, API, `oz agent run-cloud`); the worker just runs the agent in a per-task workspace on its own filesystem. :::note This page covers the [managed architecture](/platform/self-hosting/#managed-architecture) with the Direct backend. For container-based task isolation, see [Managed: Docker](/platform/self-hosting/managed-docker/) or [Managed: Kubernetes](/platform/self-hosting/managed-kubernetes/). For invocation-driven use cases, see [Unmanaged](/platform/self-hosting/unmanaged/). @@ -38,8 +39,8 @@ The Direct backend does not provide per-task container isolation. Each task runs * **Enterprise plan with self-hosting enabled** — [Contact sales](https://www.warp.dev/contact-sales) if self-hosting is not yet enabled for your team. * **A worker host** with write access to `workspace_root` (defaults to `/var/lib/oz/workspaces`). -* **The Oz CLI** installed and available in `PATH` on the worker host (or specify `oz_path` in the config file). See [Installing the CLI](/reference/cli/#installing-the-cli). -* **An agent API key** — Create one in the [Oz web app](https://oz.warp.dev/settings) so the worker can authenticate to Oz. You can bind the key to any cloud agent — that choice doesn't restrict which agents can run on the worker. See [API Keys](/reference/cli/api-keys/) for the full creation flow. +* **The {VARS.WARP_AGENT_CLI}** installed and available in `PATH` on the worker host (or specify `oz_path` in the config file). See [Installing the CLI](/reference/cli/#installing-the-cli). +* **An agent API key** — Create one in the {VARS.WEB_APP} so the worker can authenticate to {VARS.WARP_AUTOMATION_PLATFORM}. You can bind the key to any cloud agent — that choice doesn't restrict which agents can run on the worker. See [API Keys](/reference/cli/api-keys/) for the full creation flow. --- @@ -47,7 +48,7 @@ The Direct backend does not provide per-task container isolation. Each task runs ### 1. Set your API key -Export the API key so the worker can authenticate to Oz: +Export the API key so the worker can authenticate to {VARS.WARP_AUTOMATION_PLATFORM}: ```bash export WARP_API_KEY="your_agent_api_key" @@ -70,7 +71,7 @@ backend: workspace_root: "/var/lib/oz/workspaces" ``` -**Expected outcome:** The worker connects to Oz and begins listening for tasks. Each assigned task runs in a freshly-created subdirectory of `workspace_root`. +**Expected outcome:** The worker connects to {VARS.WARP_AUTOMATION_PLATFORM} and begins listening for tasks. Each assigned task runs in a freshly-created subdirectory of `workspace_root`. --- diff --git a/src/content/docs/platform/self-hosting/managed-docker.mdx b/src/content/docs/platform/self-hosting/managed-docker.mdx index 85e26543..d28b5522 100644 --- a/src/content/docs/platform/self-hosting/managed-docker.mdx +++ b/src/content/docs/platform/self-hosting/managed-docker.mdx @@ -1,13 +1,14 @@ --- title: "Managed: Docker backend" description: >- - Run the Oz managed worker daemon with the Docker backend to execute cloud + Run the {{WARP_AUTOMATION_PLATFORM}} managed worker daemon with the Docker backend to execute cloud agent tasks in isolated containers on your infrastructure. sidebar: label: "Managed: Docker" --- +import { VARS } from '@data/vars'; -Run the `oz-agent-worker` daemon with the **Docker backend** — the default managed path. Each agent task runs in an isolated Docker container spawned from the worker, with full orchestration by Oz (Slack, Linear, schedules, API, `oz agent run-cloud`). +Run the `oz-agent-worker` daemon with the **Docker backend** — the default managed path. Each agent task runs in an isolated Docker container spawned from the worker, with full orchestration by {VARS.WARP_AUTOMATION_PLATFORM} (Slack, Linear, schedules, API, `oz agent run-cloud`). :::note This page covers the [managed architecture](/platform/self-hosting/#managed-architecture) with the Docker backend. For the Kubernetes backend, see [Managed: Kubernetes](/platform/self-hosting/managed-kubernetes/). For host execution without a container runtime, see [Managed: Direct](/platform/self-hosting/managed-direct/). If you'd rather invoke agents yourself, see [Unmanaged](/platform/self-hosting/unmanaged/). @@ -26,7 +27,7 @@ This page covers the [managed architecture](/platform/self-hosting/#managed-arch * **Enterprise plan with self-hosting enabled** — [Contact sales](https://www.warp.dev/contact-sales) if self-hosting is not yet enabled for your team. * **A machine to run the worker** — A VM, server, or local machine running Linux (recommended for production). For testing, macOS and Windows hosts running Docker Desktop work. * **Docker installed** — The worker uses Docker to spawn task containers. The Docker daemon must run Linux containers (Windows containers are not supported). Verify with `docker info`. -* **An agent API key** — Create one in the [Oz web app](https://oz.warp.dev/settings) so the worker can authenticate to Oz. You can bind the key to any cloud agent — that choice doesn't restrict which agents can run on the worker. See [API Keys](/reference/cli/api-keys/) for the full creation flow. +* **An agent API key** — Create one in the {VARS.WEB_APP} so the worker can authenticate to {VARS.WARP_AUTOMATION_PLATFORM}. You can bind the key to any cloud agent — that choice doesn't restrict which agents can run on the worker. See [API Keys](/reference/cli/api-keys/) for the full creation flow. :::caution Task containers require a **linux/amd64** or **linux/arm64** Docker daemon. The worker host itself can be any OS — Docker Desktop on macOS and Windows runs a Linux VM that satisfies this requirement. @@ -46,7 +47,7 @@ docker info ## Set your API key -Export your agent API key so the worker can authenticate to Oz: +Export your agent API key so the worker can authenticate to {VARS.WARP_AUTOMATION_PLATFORM}: ```bash export WARP_API_KEY="your_agent_api_key" @@ -70,7 +71,7 @@ docker run -v /var/run/docker.sock:/var/run/docker.sock \ warpdotdev/oz-agent-worker --worker-id "my-worker" ``` -**Expected outcome:** The worker connects to Oz and logs that it's listening for tasks. +**Expected outcome:** The worker connects to {VARS.WARP_AUTOMATION_PLATFORM} and logs that it's listening for tasks. ### Option 2: Go install @@ -88,9 +89,9 @@ go build -o oz-agent-worker ./oz-agent-worker --api-key "$WARP_API_KEY" --worker-id "my-worker" ``` -Once started, the worker connects to Oz, waits for tasks routed to its `--worker-id`, runs each task in an isolated Docker container, and reports status and results back. The worker automatically reconnects if the connection drops. +Once started, the worker connects to {VARS.WARP_AUTOMATION_PLATFORM}, waits for tasks routed to its `--worker-id`, runs each task in an isolated Docker container, and reports status and results back. The worker automatically reconnects if the connection drops. -You can run multiple workers with the same `--worker-id` for redundancy — Oz distributes tasks across connected workers. +You can run multiple workers with the same `--worker-id` for redundancy — {VARS.WARP_AUTOMATION_PLATFORM} distributes tasks across connected workers. --- diff --git a/src/content/docs/platform/self-hosting/managed-kubernetes.mdx b/src/content/docs/platform/self-hosting/managed-kubernetes.mdx index cddee1a4..7823e59e 100644 --- a/src/content/docs/platform/self-hosting/managed-kubernetes.mdx +++ b/src/content/docs/platform/self-hosting/managed-kubernetes.mdx @@ -1,13 +1,14 @@ --- title: "Managed: Kubernetes backend" description: >- - Deploy the Oz managed worker into a Kubernetes cluster with the included + Deploy the {{WARP_AUTOMATION_PLATFORM}} managed worker into a Kubernetes cluster with the included Helm chart. Each agent task runs as a Kubernetes Job in your cluster. sidebar: label: "Managed: Kubernetes" --- +import { VARS } from '@data/vars'; -Deploy the `oz-agent-worker` daemon into a Kubernetes cluster using the included Helm chart. Each agent task runs as a **Kubernetes Job** in your cluster. Oz orchestrates runs end to end (Slack, Linear, schedules, API, `oz agent run-cloud`); your cluster provides the compute, scheduling, and policy enforcement. +Deploy the `oz-agent-worker` daemon into a Kubernetes cluster using the included Helm chart. Each agent task runs as a **Kubernetes Job** in your cluster. {VARS.WARP_AUTOMATION_PLATFORM} orchestrates runs end to end (Slack, Linear, schedules, API, `oz agent run-cloud`); your cluster provides the compute, scheduling, and policy enforcement. :::note This page covers the [managed architecture](/platform/self-hosting/#managed-architecture) with the Kubernetes backend. For the default Docker backend, see [Managed: Docker](/platform/self-hosting/managed-docker/). For host execution without a container runtime, see [Managed: Direct](/platform/self-hosting/managed-direct/). To route runs to a connected worker, see [Routing runs to self-hosted workers](/platform/self-hosting/managed-docker/#routing-runs-to-self-hosted-workers). @@ -38,7 +39,7 @@ This page covers the [managed architecture](/platform/self-hosting/#managed-arch * Allow the worker's namespace to create Jobs with a **root init container** (sidecar materialization depends on this pattern). * Grant the worker these namespace-scoped permissions: `create`, `get`, `list`, `watch`, `delete` on `jobs`; `get`, `list`, `watch` on `pods`; `get` on `pods/log`; `list` on `events`. * **[Helm](https://helm.sh/docs/intro/install/)** installed locally, plus `kubectl` authenticated against the target cluster. -* **An agent API key** — Create one in the [Oz web app](https://oz.warp.dev/settings) so the worker can authenticate to Oz. You can bind the key to any cloud agent — that choice doesn't restrict which agents can run on the worker. See [API Keys](/reference/cli/api-keys/) for the full creation flow. +* **An agent API key** — Create one in the {VARS.WEB_APP} so the worker can authenticate to {VARS.WARP_AUTOMATION_PLATFORM}. You can bind the key to any cloud agent — that choice doesn't restrict which agents can run on the worker. See [API Keys](/reference/cli/api-keys/) for the full creation flow. --- diff --git a/src/content/docs/platform/self-hosting/monitoring.mdx b/src/content/docs/platform/self-hosting/monitoring.mdx index a66d52f4..717927ea 100644 --- a/src/content/docs/platform/self-hosting/monitoring.mdx +++ b/src/content/docs/platform/self-hosting/monitoring.mdx @@ -3,12 +3,13 @@ title: Self-hosted worker monitoring sidebar: label: "Monitoring" description: >- - Monitor self-hosted Oz workers with OpenTelemetry metrics. Export to + Monitor self-hosted {{WARP_AUTOMATION_PLATFORM}} workers with OpenTelemetry metrics. Export to Prometheus, OTLP, or console to track worker health, task throughput, and saturation. --- +import { VARS } from '@data/vars'; -The `oz-agent-worker` daemon exports infrastructure-level metrics over [OpenTelemetry](https://opentelemetry.io/), giving your team real-time visibility into worker health, task throughput, and capacity. Combine these metrics with the [Oz dashboard](https://oz.warp.dev) for full observability across both the orchestration plane and your self-hosted compute. +The `oz-agent-worker` daemon exports infrastructure-level metrics over [OpenTelemetry](https://opentelemetry.io/), giving your team real-time visibility into worker health, task throughput, and capacity. Combine these metrics with the {VARS.DASHBOARD} for full observability across both the orchestration plane and your self-hosted compute. :::note When running the binary directly, metrics export follows the [OpenTelemetry autoexport](https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/exporters/autoexport) default — if `OTEL_METRICS_EXPORTER` is unset, the worker pushes OTLP to `localhost:4318`. Set `OTEL_METRICS_EXPORTER=none` to disable export. The Helm chart is opt-in: it only enables export when `metrics.enabled=true`. @@ -136,7 +137,7 @@ metrics: All metrics use the `oz_worker_` prefix. Each worker process emits a distinct set of series, identified by the resource attributes `service.name`, `service.version`, `worker.id`, and `worker.backend`. -* **`oz_worker_connected`** (gauge) — `1` while the worker has an active WebSocket connection to Oz's backend, `0` otherwise. +* **`oz_worker_connected`** (gauge) — `1` while the worker has an active WebSocket connection to {VARS.WARP_AUTOMATION_PLATFORM}'s backend, `0` otherwise. * **`oz_worker_tasks_active`** (gauge / UpDownCounter) — Tasks currently executing on this worker. * **`oz_worker_tasks_max_concurrent`** (gauge) — Configured concurrency limit (`0` means unlimited). * **`oz_worker_tasks_claimed_total`** (counter) — Total tasks accepted since process start. diff --git a/src/content/docs/platform/self-hosting/quickstart.mdx b/src/content/docs/platform/self-hosting/quickstart.mdx index 8894cfbf..33217784 100644 --- a/src/content/docs/platform/self-hosting/quickstart.mdx +++ b/src/content/docs/platform/self-hosting/quickstart.mdx @@ -1,16 +1,17 @@ --- title: Self-hosting quickstart description: >- - Get a managed self-hosted Oz worker running on Docker and route your first + Get a managed self-hosted {{WARP_AUTOMATION_PLATFORM}} worker running on Docker and route your first cloud agent run to it in under 10 minutes. sidebar: label: "Quickstart" --- +import { VARS } from '@data/vars'; Run your first cloud agent on your own infrastructure in ~10 minutes using the managed architecture with the Docker backend — the default and fastest path to self-hosting. :::note -This quickstart sets up the [managed architecture](/platform/self-hosting/#managed-architecture), where Oz orchestrates the agent and your worker provides the compute. **Prefer a CLI-only path with no Docker requirement?** Jump to the [Unmanaged quickstart](/platform/self-hosting/unmanaged/#unmanaged-quickstart) to run `oz agent run` directly on any host. +This quickstart sets up the [managed architecture](/platform/self-hosting/#managed-architecture), where {VARS.WARP_AUTOMATION_PLATFORM} orchestrates the agent and your worker provides the compute. **Prefer a CLI-only path with no Docker requirement?** Jump to the [Unmanaged quickstart](/platform/self-hosting/unmanaged/#unmanaged-quickstart) to run `oz agent run` directly on any host. ::: --- @@ -19,8 +20,8 @@ This quickstart sets up the [managed architecture](/platform/self-hosting/#manag * **Enterprise plan with self-hosting enabled** — [Contact sales](https://www.warp.dev/contact-sales) if self-hosting is not yet enabled for your team. * **A Linux machine with Docker** — A VM, server, or local machine with the Docker daemon running Linux containers. Verify with `docker info`. Docker Desktop on macOS or Windows works for testing. -* **An agent API key** — Create one in the [Oz web app](https://oz.warp.dev/settings) so the worker can authenticate to Oz. You can bind the key to any cloud agent — that choice doesn't restrict which agents can run on the worker. See [API Keys](/reference/cli/api-keys/) for the full creation flow. -* **The Oz CLI** (for routing a test run) — See [Installing the CLI](/reference/cli/#installing-the-cli). +* **An agent API key** — Create one in the {VARS.WEB_APP} so the worker can authenticate to {VARS.WARP_AUTOMATION_PLATFORM}. You can bind the key to any cloud agent — that choice doesn't restrict which agents can run on the worker. See [API Keys](/reference/cli/api-keys/) for the full creation flow. +* **The {VARS.WARP_AGENT_CLI}** (for routing a test run) — See [Installing the CLI](/reference/cli/#installing-the-cli). --- @@ -30,7 +31,7 @@ _~10 minutes_ ### 1. Export your API key -Export the agent API key so the worker container can authenticate to Oz automatically: +Export the agent API key so the worker container can authenticate to {VARS.WARP_AUTOMATION_PLATFORM} automatically: ```bash export WARP_API_KEY="your_agent_api_key" @@ -46,7 +47,7 @@ docker run -v /var/run/docker.sock:/var/run/docker.sock \ warpdotdev/oz-agent-worker --worker-id "my-worker" ``` -**Expected outcome:** The worker connects to Oz and begins listening for tasks. You should see log output confirming the connection (something like `Connected to Oz` / `Waiting for tasks`). +**Expected outcome:** The worker connects to {VARS.WARP_AUTOMATION_PLATFORM} and begins listening for tasks. You should see log output confirming the connection (something like `Connected to Oz` / `Waiting for tasks`). :::caution For production deployments, pin to a specific image digest (e.g., `warpdotdev/oz-agent-worker@sha256:...`) instead of the `latest` tag. @@ -54,17 +55,17 @@ For production deployments, pin to a specific image digest (e.g., `warpdotdev/oz ### 3. Route a run to your worker -In a separate terminal on any machine with the Oz CLI, route a cloud agent run to your worker by passing `--host` with the worker ID you chose: +In a separate terminal on any machine with the {VARS.WARP_AGENT_CLI}, route a cloud agent run to your worker by passing `--host` with the worker ID you chose: ```bash oz agent run-cloud --prompt "List the files in the current directory" --host "my-worker" ``` -**Expected outcome:** Oz accepts the task, routes it to your worker, and the worker spawns a Docker container to execute the agent. You'll see the run appear in the [Oz dashboard](https://oz.warp.dev) with status moving from `QUEUED` → `INPROGRESS` → `SUCCEEDED`. +**Expected outcome:** {VARS.WARP_AUTOMATION_PLATFORM} accepts the task, routes it to your worker, and the worker spawns a Docker container to execute the agent. You'll see the run appear in the {VARS.DASHBOARD} with status moving from `QUEUED` → `INPROGRESS` → `SUCCEEDED`. ### 4. Verify the run -Open the [Oz dashboard](https://oz.warp.dev), find the new task, and confirm the session transcript shows the agent running against your worker. You can attach to the session at any time via [Agent Session Sharing](/agents/local-agents/session-sharing/) to monitor or steer it. +Open the {VARS.DASHBOARD}, find the new task, and confirm the session transcript shows the agent running against your worker. You can attach to the session at any time via [Agent Session Sharing](/agents/local-agents/session-sharing/) to monitor or steer it. --- @@ -73,7 +74,7 @@ Open the [Oz dashboard](https://oz.warp.dev), find the new task, and confirm the * [Unmanaged quickstart](/platform/self-hosting/unmanaged/#unmanaged-quickstart) — ~5-minute CLI-only path: run `oz agent run` in your CI, Kubernetes pod, or dev box with no worker daemon and no Docker requirement. * [Managed: Docker](/platform/self-hosting/managed-docker/) — Full Docker backend setup, including private registries, volume mounts, and runtime configuration. * [Environments](/platform/environments/) — Define a repository, Docker image, and setup commands so agents have a reproducible workspace for every run. -* [Routing runs to self-hosted workers](/platform/self-hosting/#routing-runs-to-self-hosted-workers) — How to route tasks from schedules, integrations (Slack, Linear), the API, and the Oz web app. +* [Routing runs to self-hosted workers](/platform/self-hosting/#routing-runs-to-self-hosted-workers) — How to route tasks from schedules, integrations (Slack, Linear), the API, and the {VARS.WEB_APP}. * [Managed: Kubernetes](/platform/self-hosting/managed-kubernetes/) — Deploy workers into a Kubernetes cluster with Helm. * [Self-hosted worker reference](/platform/self-hosting/reference/) — All CLI flags and config file options. diff --git a/src/content/docs/platform/self-hosting/security-and-networking.mdx b/src/content/docs/platform/self-hosting/security-and-networking.mdx index 133daf3e..c039db6a 100644 --- a/src/content/docs/platform/self-hosting/security-and-networking.mdx +++ b/src/content/docs/platform/self-hosting/security-and-networking.mdx @@ -1,7 +1,7 @@ --- title: Security and networking description: >- - Security model, data boundaries, and network requirements for self-hosted Oz + Security model, data boundaries, and network requirements for self-hosted {{WARP_AUTOMATION_PLATFORM}} cloud agents — including per-backend considerations and BYOLLM. --- diff --git a/src/content/docs/platform/self-hosting/troubleshooting.mdx b/src/content/docs/platform/self-hosting/troubleshooting.mdx index 6c6bc3c0..5ebf6e81 100644 --- a/src/content/docs/platform/self-hosting/troubleshooting.mdx +++ b/src/content/docs/platform/self-hosting/troubleshooting.mdx @@ -1,11 +1,12 @@ --- title: Self-hosting troubleshooting description: >- - Diagnose and fix common problems with self-hosted Oz worker daemons across + Diagnose and fix common problems with self-hosted {{WARP_AUTOMATION_PLATFORM}} worker daemons across Docker, Kubernetes, and Direct backends. sidebar: label: "Troubleshooting" --- +import { VARS } from '@data/vars'; Diagnostic guides for the `oz-agent-worker` daemon and its task execution. Use this page when a worker won't start, won't connect, tasks stay queued, or tasks fail. @@ -45,19 +46,19 @@ The steps below apply to the [managed architecture](/platform/self-hosting/#mana **Fix:** -1. Install the Oz CLI on the worker host. See [Installing the CLI](/reference/cli/#installing-the-cli). +1. Install the {VARS.WARP_AGENT_CLI} on the worker host. See [Installing the CLI](/reference/cli/#installing-the-cli). 2. If the CLI isn't on `PATH`, set `oz_path` in the config file to the absolute path of the `oz` binary. --- ## Worker won't connect -**Cause:** The API key is invalid, expired, or the host cannot reach Oz's backend. +**Cause:** The API key is invalid, expired, or the host cannot reach {VARS.WARP_AUTOMATION_PLATFORM}'s backend. **Fix:** 1. Confirm your API key is correct, not expired, and has team scope. -2. Regenerate the API key in **Settings** > **Cloud platform** > **Oz Cloud API Keys** if you suspect it's invalid. +2. Regenerate the API key in **Settings** > **Cloud platform** > **{VARS.WARP_AUTOMATION_PLATFORM} Cloud API Keys** if you suspect it's invalid. 3. Ensure the host has outbound internet access to `oz.warp.dev:443`. 4. Check that no firewall rules are blocking WebSocket connections to `wss://oz.warp.dev`. 5. Increase log verbosity with `--log-level debug` to see connection details. @@ -102,7 +103,7 @@ See [Monitoring](/platform/self-hosting/monitoring/) for the full setup guide. **Fix (all backends):** -1. Review task logs in the [Oz dashboard](https://oz.warp.dev) or via [session sharing](/agents/local-agents/session-sharing/). +1. Review task logs in the {VARS.DASHBOARD} or via [session sharing](/agents/local-agents/session-sharing/). 2. Use `--no-cleanup` to keep the container, Job, or workspace around for inspection after failure. 3. Use `--log-level debug` to see detailed execution logs. 4. Ensure the worker machine or cluster has sufficient resources (CPU, memory, disk). @@ -123,7 +124,7 @@ See [Monitoring](/platform/self-hosting/monitoring/) for the full setup guide. ### Direct backend (task failures) -1. Verify the Oz CLI is accessible. +1. Verify the {VARS.WARP_AGENT_CLI} is accessible. 2. Verify the workspace root directory has write permissions for the user running the worker. --- diff --git a/src/content/docs/platform/self-hosting/unmanaged.mdx b/src/content/docs/platform/self-hosting/unmanaged.mdx index 39966f57..1bc4a9e5 100644 --- a/src/content/docs/platform/self-hosting/unmanaged.mdx +++ b/src/content/docs/platform/self-hosting/unmanaged.mdx @@ -6,11 +6,12 @@ description: >- sidebar: label: "Unmanaged" --- +import { VARS } from '@data/vars'; With the unmanaged architecture, **you orchestrate agent runs** by invoking `oz agent run` directly from your existing CI pipelines, Kubernetes pods, VMs, or dev boxes. The agent runs on whatever host the command is executed from; Warp tracks the session for you but does not start or stop agents. :::note -Unmanaged is the right choice if you already have a system that schedules work (CI, internal orchestrators, cron, dev environments). If you'd rather have Oz trigger and route runs from Slack, Linear, schedules, or the API, use the [managed architecture](/platform/self-hosting/#managed-architecture) instead. +Unmanaged is the right choice if you already have a system that schedules work (CI, internal orchestrators, cron, dev environments). If you'd rather have {VARS.WARP_AUTOMATION_PLATFORM} trigger and route runs from Slack, Linear, schedules, or the API, use the [managed architecture](/platform/self-hosting/#managed-architecture) instead. ::: ## When to use unmanaged @@ -28,12 +29,12 @@ Unmanaged works on any platform Warp supports (Linux, macOS, Windows) with no de _~5 minutes_ -No Docker, no worker daemon, no environment required — just the Oz CLI on any host that can reach the internet. +No Docker, no worker daemon, no environment required — just the {VARS.WARP_AGENT_CLI} on any host that can reach the internet. ### Prerequisites -* **The Oz CLI** installed on the machine where agents will run. See [Installing the CLI](/reference/cli/#installing-the-cli) for platform-specific instructions. -* **A Warp API key** — For automation, create an agent API key in the [Oz web app](https://oz.warp.dev/settings). See [API Keys](/reference/cli/api-keys/) for personal vs. agent guidance. +* **The {VARS.WARP_AGENT_CLI}** installed on the machine where agents will run. See [Installing the CLI](/reference/cli/#installing-the-cli) for platform-specific instructions. +* **A Warp API key** — For automation, create an agent API key in the {VARS.WEB_APP}. See [API Keys](/reference/cli/api-keys/) for personal vs. agent guidance. ### 1. Authenticate @@ -51,7 +52,7 @@ Invoke `oz agent run` in the directory where you want the agent to operate. The oz agent run --prompt "Refactor the authentication module" --share team ``` -**Expected outcome:** The agent starts immediately in the current working directory, and a tracked session appears in the [Oz dashboard](https://oz.warp.dev). +**Expected outcome:** The agent starts immediately in the current working directory, and a tracked session appears in the {VARS.DASHBOARD}. ### 3. Control sharing @@ -120,9 +121,9 @@ Whether Kubernetes pods provide sufficient sandboxing for agents depends on your Unmanaged agents are tracked on Warp's backend. Each run creates a persistent session that your team can: -* **View** in the [Oz dashboard](https://oz.warp.dev). +* **View** in the {VARS.DASHBOARD}. * **Attach to** via [Agent Session Sharing](/agents/local-agents/session-sharing/) to monitor or steer. -* **Query** through the [Oz API/SDK](/reference/api-and-sdk/) for custom dashboards or monitoring. +* **Query** through the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) for custom dashboards or monitoring. Unmanaged sessions benefit from the same shared configuration as other cloud agent runs — [MCP servers](/platform/mcp/), [secrets](/platform/secrets/), Warp Drive context, and saved prompts all apply. @@ -135,5 +136,5 @@ Unmanaged runs don't ship with the bundled declarations script, so end-of-run wo * [Self-hosting overview](/platform/self-hosting/) — Compare managed and unmanaged, plus the architecture decision guide. * [GitHub Actions integration](/platform/integrations/github-actions/) — Run agents in CI with the official action. * [Deployment patterns](/platform/deployment-patterns/) — Pattern 1 (CLI-only) explains the unmanaged model conceptually. -* [Oz CLI](/reference/cli/) — Full CLI reference for `oz agent run` and related commands. +* [{VARS.WARP_AGENT_CLI}](/reference/cli/) — Full CLI reference for `oz agent run` and related commands. * [Agent Session Sharing](/agents/local-agents/session-sharing/) — Attach to running sessions to monitor or steer them. diff --git a/src/content/docs/platform/skills-as-agents.mdx b/src/content/docs/platform/skills-as-agents.mdx index e82edecf..1832ae50 100644 --- a/src/content/docs/platform/skills-as-agents.mdx +++ b/src/content/docs/platform/skills-as-agents.mdx @@ -2,10 +2,11 @@ title: Skills as Agents description: >- Run agents based on skills for consistent, repeatable workflows. Use skills - with local or cloud agents from the CLI, Oz web app, API, or on a schedule. + with local or cloud agents from the CLI, {{WEB_APP}}, API, or on a schedule. sidebar: label: "Skills as agents" --- +import { VARS } from '@data/vars'; You can start an agent from a [skill](/agents/capabilities/skills/)—a reusable set of instructions that defines what the agent should do. When you run an agent based on a skill, the skill provides the base prompt and behavior, while you supply additional context for that specific run. @@ -48,10 +49,10 @@ For cloud agent runs (`oz agent run-cloud`), skills are discovered from reposito 1. **Create a skill** in your repository (see [Creating skills](/agents/capabilities/skills/#creating-skills)) 2. **Add the repository** to an environment -3. **The skill appears** in the Agents list in the Oz web app +3. **The skill appears** in the Agents list in the {VARS.WEB_APP} :::note -You can also list available skills programmatically using the `GET /agent` endpoint. See the [Oz API](/reference/api-and-sdk/) reference for details. +You can also list available skills programmatically using the `GET /agent` endpoint. See the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) reference for details. ::: --- @@ -60,20 +61,20 @@ You can also list available skills programmatically using the `GET /agent` endpo You can start an agent from a skill using multiple entry points. -### Oz web app +### Web app -Use the [Oz web app](/platform/oz-web-app/) to run skill-based agents from a visual interface. From the web app, you can: +Use the [{VARS.WEB_APP}](/platform/oz-web-app/) to run skill-based agents from a visual interface. From the web app, you can: * Browse all skills available from your environments on the **Agents** page * View suggested agents from Warp's public [oz-skills repository](https://github.com/warpdotdev/oz-skills) * Start a new run by selecting a skill, environment, and prompt * Create scheduled agents that run skills on a cron schedule -For a complete walkthrough of the web app interface, see [Oz Web App](/platform/oz-web-app/). +For a complete walkthrough of the web app interface, see [{VARS.WEB_APP}](/platform/oz-web-app/). ### CLI -Use the `--skill` flag with the Oz CLI: +Use the `--skill` flag with the {VARS.WARP_AGENT_CLI}: ```sh # Run locally with a skill @@ -125,7 +126,7 @@ oz schedule create \ --prompt "Scan for dead code and unused feature flags. Open a PR with removals." ``` -You can also create schedules from the [Oz web app](/platform/oz-web-app/) using the **New schedule** action. +You can also create schedules from the [{VARS.WEB_APP}](/platform/oz-web-app/) using the **New schedule** action. For full scheduling documentation, see [Scheduled Agents](/platform/triggers/scheduled-agents/). @@ -133,7 +134,7 @@ For full scheduling documentation, see [Scheduled Agents](/platform/triggers/sch ## Suggested Skills -The [Oz web app](/platform/oz-web-app/) displays suggested agents from the public [warpdotdev/oz-skills](https://github.com/warpdotdev/oz-skills) repository. These are pre-built skills that demonstrate common use cases and can be used as starting points for your own workflows. +The [{VARS.WEB_APP}](/platform/oz-web-app/) displays suggested agents from the public [warpdotdev/oz-skills](https://github.com/warpdotdev/oz-skills) repository. These are pre-built skills that demonstrate common use cases and can be used as starting points for your own workflows. Suggested skills appear on the Agents page under the **Suggested** filter. @@ -144,6 +145,6 @@ Suggested skills appear on the Agents page under the **Suggested** filter. * [Skills](/agents/capabilities/skills/) — How to create skills and skill file format * [Environments](/platform/environments/) — Configure repositories and runtime context for cloud agents * [Scheduled Agents](/platform/triggers/scheduled-agents/) — Run agents automatically on a cron schedule -* [Oz Web App](/platform/oz-web-app/) — Visual interface for managing cloud agents -* [Oz CLI](/reference/cli/) — Command-line interface for running agents -* [Oz API & SDK](/reference/api-and-sdk/) — Programmatic access to cloud agents +* [{VARS.WEB_APP}](/platform/oz-web-app/) — Visual interface for managing cloud agents +* [{VARS.WARP_AGENT_CLI}](/reference/cli/) — Command-line interface for running agents +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) — Programmatic access to cloud agents diff --git a/src/content/docs/platform/software-factory.mdx b/src/content/docs/platform/software-factory.mdx index a946fe9d..fd0eb40e 100644 --- a/src/content/docs/platform/software-factory.mdx +++ b/src/content/docs/platform/software-factory.mdx @@ -2,8 +2,13 @@ title: Software factory description: >- A software factory uses specialized agents to take new issues through triage, spec, implementation, and review, producing pull requests for your team to merge. -sidebar: - label: "Software factory" +# Unlisted: superseded by the new Factories tab (/factories/) for the 8/18 +# launch and redirected there in vercel.json. Kept as source material for +# HYC/content to migrate rather than deleted -- see the Factories tab stubs. +# The `topic` field associates this orphaned page with the Automation +# Platform topic so starlight-sidebar-topics can resolve it without listing +# it under any group. +topic: platform --- A software factory is a development system where specialized agents take new issues through triage, spec, implementation, and review, producing pull requests for your team to merge. Instead of every developer executing every step — reading each issue, writing specs, implementing changes, reviewing output — agents execute and humans review. The team's job shifts from doing the work to defining the process and raising the quality bar over time. diff --git a/src/content/docs/platform/team-access-billing-and-identity.mdx b/src/content/docs/platform/team-access-billing-and-identity.mdx index cf4d7401..b17efb27 100644 --- a/src/content/docs/platform/team-access-billing-and-identity.mdx +++ b/src/content/docs/platform/team-access-billing-and-identity.mdx @@ -7,6 +7,7 @@ description: >- sidebar: label: "Access, billing, and identity" --- +import { VARS } from '@data/vars'; This page explains how access to cloud agents works for both individual users and teams, how billing and credits apply, and how Warp maps user identities across integrations. @@ -37,7 +38,7 @@ Individual users can run cloud agents via the CLI or API without being part of a **How it works:** -* Run agents using `oz agent run-cloud` or the Oz API +* Run agents using `oz agent run-cloud` or the {VARS.API_SDK_NAME} * Credits are drawn from your Warp credits (including cloud agent credits, when applicable) * Agents execute on Warp-hosted infrastructure @@ -66,7 +67,7 @@ A [Warp team](/knowledge-and-collaboration/teams/) is a group of users who share * **Self-hosting** - Run agents on your own infrastructure (Enterprise only) * **Team visibility** - Shared observability into agent runs and history -Integrations are created at the team level, not per-user. Once a Slack or Linear integration is installed, everyone on your Warp team can use **@Oz** in the connected workspace. The integration behaves the same way for all teammates, and everyone shares the same underlying environment configuration. The GitHub integration is team-level in the same way: once an admin enables the GitHub organization, any teammate with a connected GitHub account can start a run by mentioning **@oz-agent**. +Integrations are created at the team level, not per-user. Once a Slack or Linear integration is installed, everyone on your Warp team can use **@{VARS.WARP_AUTOMATION_PLATFORM}** in the connected workspace. The integration behaves the same way for all teammates, and everyone shares the same underlying environment configuration. The GitHub integration is team-level in the same way: once an admin enables the GitHub organization, any teammate with a connected GitHub account can start a run by mentioning **@oz-agent**. When someone triggers a cloud agent for the first time, Warp may prompt them to grant GitHub authorization so the agent can open pull requests or push branches under their identity. This allows each run to use the correct permissions without requiring additional setup from an admin. @@ -123,7 +124,7 @@ The GitHub App token gives the agent access to the repositories included in the :::note There are two places you may encounter this installation flow: - * During the first-time experience for Oz, when you connect your GitHub account. + * During the first-time experience for {VARS.WARP_AUTOMATION_PLATFORM}, when you connect your GitHub account. * When you click **Configure access on GitHub** in the repository selector while creating an environment. Each installation is scoped to a single GitHub organization or personal account — you can install the app to multiple orgs separately. @@ -141,7 +142,7 @@ There are two places you may encounter this installation flow:
Enabled GitHub Orgs setting in the Admin Panel.
-3. **Use an agent API key.** Tasks initiated with an agent API key on the team now use tokens from the GitHub App installation to clone repos and push changes. No individual GitHub authorization is needed. On GitHub, commits and pull requests are opened by the Oz by Warp GitHub App rather than any individual user; in the Oz dashboard, the run is attributed to the bound [cloud agent](/platform/agents/). +3. **Use an agent API key.** Tasks initiated with an agent API key on the team now use tokens from the GitHub App installation to clone repos and push changes. No individual GitHub authorization is needed. On GitHub, commits and pull requests are opened by the Oz by Warp GitHub App rather than any individual user; in the {VARS.DASHBOARD}, the run is attributed to the bound [cloud agent](/platform/agents/). ### How this relates to environments @@ -156,9 +157,9 @@ The environment configuration and the **Enabled GitHub Orgs** setting in the Adm Team GitHub authorization is complementary to the existing personal token flow: -* **User-triggered runs** (personal API key, Slack, Linear, Warp app) - The agent authenticates as Oz acting on the triggering user's behalf. PRs and commits are attributed to that user. -* **Agent API key runs with GitHub App authorization** - The agent authenticates as the GitHub App installation. On GitHub, PRs and commits are attributed to the Oz by Warp GitHub App rather than any individual user. In the Oz dashboard, the run is attributed to the bound [cloud agent](/platform/agents/), which controls run filtering and audit attribution on the Warp side. -* **[GitHub integration](/platform/integrations/github/) runs** (an `@oz-agent` mention on an issue or pull request) - The agent authenticates as the installation that delivered the event, so its repository access and its GitHub attribution match the agent API key flow. In the Oz dashboard the run is still attributed to the teammate who wrote the mention, and their team is billed. +* **User-triggered runs** (personal API key, Slack, Linear, Warp app) - The agent authenticates using the triggering user's personal token. PRs and commits are attributed to that user. +* **Agent API key runs with GitHub App authorization** - The agent authenticates as the GitHub App installation. On GitHub, PRs and commits are attributed to the Oz by Warp GitHub App rather than any individual user. In the {VARS.DASHBOARD}, the run is attributed to the bound [cloud agent](/platform/agents/), which controls run filtering and audit attribution on the Warp side. +* **[GitHub integration](/platform/integrations/github/) runs** (an `@oz-agent` mention on an issue or pull request) - The agent authenticates as the installation that delivered the event, so its repository access and its GitHub attribution match the agent API key flow. In the {VARS.DASHBOARD} the run is still attributed to the teammate who wrote the mention, and their team is billed. These flows can coexist on the same team. Personal tokens are still used for user-triggered runs from a personal API key, Slack, Linear, and the Warp app, and the GitHub App installation token is used for agent API key runs and for GitHub integration runs. @@ -176,14 +177,14 @@ To change which repositories the GitHub App can access, edit the app installatio #### Slack / Linear -Installing the Oz app gives Warp access to the Slack channels or Linear teams where the app is installed. +Installing the {VARS.WARP_AUTOMATION_PLATFORM} app gives Warp access to the Slack channels or Linear teams where the app is installed. **When a run is triggered, Warp receives:** * The content of the tagged thread or issue * Relevant surrounding context used to build the agent prompt -Warp stores only the content required for the agent to complete its task. You can message @Oz directly, mention it in channels, or tag it on specific issues depending on the integration. +Warp stores only the content required for the agent to complete its task. You can message @{VARS.WARP_AUTOMATION_PLATFORM} directly, mention it in channels, or tag it on specific issues depending on the integration. #### GitHub diff --git a/src/content/docs/platform/triggers/index.mdx b/src/content/docs/platform/triggers/index.mdx index 0f585068..8f330fbd 100644 --- a/src/content/docs/platform/triggers/index.mdx +++ b/src/content/docs/platform/triggers/index.mdx @@ -4,20 +4,21 @@ description: >- Configure triggers to run cloud agents automatically based on schedules or events. --- +import { VARS } from '@data/vars'; Triggers allow you to run cloud agents automatically without manual intervention. You can set up agents to run on schedules, in response to webhooks, or through other automation patterns. To set up your first recurring agent, follow the [Scheduled Agents Quickstart](/platform/triggers/scheduled-agents-quickstart/). -If you're choosing between schedules, Slack, Linear, GitHub, GitHub Actions, the Oz CLI, or the API, start with [Run agents unattended with schedules and triggers](/guides/agent-workflows/how-to-run-unattended-agents/). +If you're choosing between schedules, Slack, Linear, GitHub, GitHub Actions, the {VARS.WARP_AGENT_CLI}, or the API, start with [Run agents unattended with schedules and triggers](/guides/agent-workflows/how-to-run-unattended-agents/). ## Available trigger types * **[Scheduled Agents](/platform/triggers/scheduled-agents/)** - Run agents on a recurring schedule using cron expressions. -* **[CLI](/reference/cli/)** - Trigger cloud agents directly from your terminal using the Oz CLI. +* **[CLI](/reference/cli/)** - Trigger cloud agents directly from your terminal using the {VARS.WARP_AGENT_CLI}. * **[API & SDK](/reference/api-and-sdk/)** - Programmatically trigger agents via the Warp API or SDK. * **[Integrations](/platform/integrations/)** - Trigger agents from external services like Slack, Linear, or Jira. * **[GitHub](/platform/integrations/github/)** - Mention `@oz-agent` on an issue, pull request, or review comment to start an agent that replies in the thread. * **[GitHub Actions](/platform/integrations/github-actions/)** - Run agents from your own CI workflows and repository events. -After a trigger fires, track and review the resulting runs across your team from the [Agent Management Panel and Oz web app Runs page](/platform/managing-cloud-agents/), where you can filter by source, status, day, or creator. +After a trigger fires, track and review the resulting runs across your team from the [Agent Management Panel and {VARS.WEB_APP} Runs page](/platform/managing-cloud-agents/), where you can filter by source, status, day, or creator. diff --git a/src/content/docs/platform/triggers/scheduled-agents-quickstart.mdx b/src/content/docs/platform/triggers/scheduled-agents-quickstart.mdx index 507477c5..9d7522b3 100644 --- a/src/content/docs/platform/triggers/scheduled-agents-quickstart.mdx +++ b/src/content/docs/platform/triggers/scheduled-agents-quickstart.mdx @@ -9,7 +9,7 @@ sidebar: import VideoEmbed from '@components/VideoEmbed.astro'; import { VARS } from '@data/vars'; -Scheduled agents are cloud agents that run on a recurring cron schedule, handling recurring tasks automatically without manual triggers. This guide walks you through setting up an agent that triages your GitHub bug reports every week, checks whether each issue has enough detail to investigate, and posts follow-up comments when information is missing. You'll use a prebundled skill and the Oz web app; no CLI or custom code required. +Scheduled agents are cloud agents that run on a recurring cron schedule, handling recurring tasks automatically without manual triggers. This guide walks you through setting up an agent that triages your GitHub bug reports every week, checks whether each issue has enough detail to investigate, and posts follow-up comments when information is missing. You'll use a prebundled skill and the {VARS.WEB_APP}; no CLI or custom code required. Watch this short demo of creating and testing a scheduled agent: @@ -25,7 +25,7 @@ Watch this short demo of creating and testing a scheduled agent: ## 1. Set up a scheduled agent -1. From the [Schedules page](https://oz.warp.dev/schedules) in the Oz web app, click **New schedule**. +1. From the Schedules page in the {VARS.WEB_APP}, click **New schedule**. 2. Enter a schedule name, e.g. `Weekly bug report triage`. 3. Expand **General**, then under **Agent**, choose the identity that will run the schedule. **Quick run** is the default and runs every execution as you. See [Run identity and pull request authorship](#run-identity-and-pull-request-authorship) before you decide. 4. Under **Skills**, select **github-bug-report-triage**. @@ -33,7 +33,7 @@ Watch this short demo of creating and testing a scheduled agent: 6. Under **Frequency**, choose a preset or enter a custom cron expression (e.g., `0 9 * * 1` for every Monday at 9 AM). 7. Click **Create schedule**. -**Breaking it down:** The schedule lives in Oz's cloud infrastructure. Unlike a local cron job, it fires even when your machine is off. Each run starts a fresh, isolated session with no state carried over from previous executions, and every run is tracked and reviewable in the [Oz web app](/platform/oz-web-app/). +**Breaking it down:** The schedule lives in {VARS.WARP_AUTOMATION_PLATFORM}'s cloud infrastructure. Unlike a local cron job, it fires even when your machine is off. Each run starts a fresh, isolated session with no state carried over from previous executions, and every run is tracked and reviewable in the [{VARS.WEB_APP}](/platform/oz-web-app/). ### Run identity and pull request authorship @@ -54,12 +54,12 @@ The {VARS.WARP_AGENT_CLI} has no **Agent** flag, so a schedule created with `oz To verify your setup without waiting for the schedule to fire, trigger a test run now: -1. From the [Schedules page](https://oz.warp.dev/schedules) in the Oz web app, click the schedule you just created. +1. From the Schedules page in the {VARS.WEB_APP}, click the schedule you just created. 2. Click ⋮ and select **Run now**, then click **Run** to confirm. -Your test run will appear under **All** on the [Runs page](https://oz.warp.dev/runs). Once the schedule fires on its cron, those runs will appear under **Recurring**. +Your test run will appear under **All** on the Runs page. Once the schedule fires on its cron, those runs will appear under **Recurring**. -Runs are also accessible from the conversation panel view in the Warp app and on mobile via the Oz web app. +Runs are also accessible from the conversation panel view in the Warp app and on mobile via the {VARS.WEB_APP}. :::note **Prefer the CLI?** See [Scheduled Agents](/platform/triggers/scheduled-agents/) for `oz schedule create`, `oz schedule list`, and full schedule management commands. To use a custom skill instead of a prebundled one, see [Skills as Agents](/platform/skills-as-agents/). @@ -70,6 +70,6 @@ Runs are also accessible from the conversation panel view in the Warp app and on ## Next steps * **Choose the right unattended trigger** - Compare schedules, Slack, Linear, GitHub Actions, CLI, and API workflows in [Run agents unattended with schedules and triggers](/guides/agent-workflows/how-to-run-unattended-agents/). -* **Trigger agents from your tools** - Connect Oz to Slack or Linear to trigger agents from mentions or issue updates. See [Integrations Quickstart](/platform/integrations/quickstart/). +* **Trigger agents from your tools** - Connect {VARS.WARP_AUTOMATION_PLATFORM} to Slack or Linear to trigger agents from mentions or issue updates. See [Integrations Quickstart](/platform/integrations/quickstart/). * **Manage and refine your schedule** - Change the frequency, swap skills, or pause and resume the schedule. See [Scheduled Agents](/platform/triggers/scheduled-agents/) for the full reference. * **Share with your team** - Schedules and environments are shared across your Warp team, so everyone benefits automatically. diff --git a/src/content/docs/platform/triggers/scheduled-agents.mdx b/src/content/docs/platform/triggers/scheduled-agents.mdx index 1e88fdc5..f9e8b71f 100644 --- a/src/content/docs/platform/triggers/scheduled-agents.mdx +++ b/src/content/docs/platform/triggers/scheduled-agents.mdx @@ -15,9 +15,9 @@ Warp's Scheduled Agents let you run cloud agents automatically on a **recurring Scheduled Agents run in the background on Warp’s infrastructure. Each run starts from a clean session, executes a fixed prompt, and produces its own task and session history that can be inspected after the fact. -For a guided, no-CLI walkthrough that creates a recurring agent from the Oz web app, see the [Scheduled Agents quickstart](/platform/triggers/scheduled-agents-quickstart/). This page is the full reference for managing schedules with the Oz CLI. +For a guided, no-CLI walkthrough that creates a recurring agent from the {VARS.WEB_APP}, see the [Scheduled Agents quickstart](/platform/triggers/scheduled-agents-quickstart/). This page is the full reference for managing schedules with the {VARS.WARP_AGENT_CLI}. -If you're deciding whether to use a schedule, Slack or Linear trigger, GitHub Actions, the Oz CLI, or the API, see [Run agents unattended with schedules and triggers](/guides/agent-workflows/how-to-run-unattended-agents/). +If you're deciding whether to use a schedule, Slack or Linear trigger, GitHub Actions, the {VARS.WARP_AGENT_CLI}, or the API, see [Run agents unattended with schedules and triggers](/guides/agent-workflows/how-to-run-unattended-agents/). --- @@ -53,11 +53,11 @@ Because each run is isolated, Scheduled Agents are safe to use for tasks that be --- -### Scheduling agents with the Oz CLI +### Scheduling agents with the CLI -Oz scheduled agents are managed through the Oz `schedule` family of CLI commands. +{VARS.WARP_AUTOMATION_PLATFORM} scheduled agents are managed through the {VARS.WARP_AUTOMATION_PLATFORM} `schedule` family of CLI commands. -All scheduling operations require the Oz CLI and an authenticated session. +All scheduling operations require the {VARS.WARP_AGENT_CLI} and an authenticated session. #### Creating a schedule diff --git a/src/content/docs/platform/viewing-cloud-agent-runs.mdx b/src/content/docs/platform/viewing-cloud-agent-runs.mdx index 9a530fd6..3849d259 100644 --- a/src/content/docs/platform/viewing-cloud-agent-runs.mdx +++ b/src/content/docs/platform/viewing-cloud-agent-runs.mdx @@ -7,8 +7,9 @@ sidebar: label: "Viewing cloud agent runs" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -Cloud agent session sharing lets you open, inspect, and continue interacting with agent tasks that are running on remote virtual machines. Whether a cloud agent was triggered from [integrations](/platform/integrations/) like Slack, Linear, GitHub Actions, or the [Oz CLI](/reference/cli/), you can view its full session, follow along in real time, ask follow-up questions, and even "fork" the work into your local Warp environment. +Cloud agent session sharing lets you open, inspect, and continue interacting with agent tasks that are running on remote virtual machines. Whether a cloud agent was triggered from [integrations](/platform/integrations/) like Slack, Linear, GitHub Actions, or the [{VARS.WARP_AGENT_CLI}](/reference/cli/), you can view its full session, follow along in real time, ask follow-up questions, and even "fork" the work into your local Warp environment. Use cloud agent session sharing when you need to inspect a cloud agent run, debug a failed automation, or give teammates a shared record of what the agent did. The shared session is the review surface for the run: it shows the prompt, plan, commands, logs, outputs, and follow-up messages where available. diff --git a/src/content/docs/platform/warp-hosting.mdx b/src/content/docs/platform/warp-hosting.mdx index 13cf9741..f09ee156 100644 --- a/src/content/docs/platform/warp-hosting.mdx +++ b/src/content/docs/platform/warp-hosting.mdx @@ -5,10 +5,11 @@ description: >- sidebar: label: "Warp-hosted agents" --- +import { VARS } from '@data/vars'; Warp's managed infrastructure lets your team run cloud agent workloads in fast, secure sandboxes. -Use Warp-hosted agents to quickly get started with Oz, without needing to configure compute resources or maintain services. +Use Warp-hosted agents to quickly get started with {VARS.WARP_AUTOMATION_PLATFORM}, without needing to configure compute resources or maintain services. ## Sandbox environment @@ -50,5 +51,5 @@ Warp's hosted agents have network egress enabled by default. Outgoing requests m ## Related pages -* [Oz Platform](/platform/overview/) - Learn how Warp-hosted agents fit into the Oz Platform. +* [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) - Learn how Warp-hosted agents fit into the {VARS.WARP_AUTOMATION_PLATFORM}. * [Self-hosting](/platform/self-hosting/) - Run agents on infrastructure you manage when execution must stay inside your network. diff --git a/src/content/docs/quickstart.mdx b/src/content/docs/quickstart.mdx index 09f707d9..c6f3a75a 100644 --- a/src/content/docs/quickstart.mdx +++ b/src/content/docs/quickstart.mdx @@ -5,6 +5,7 @@ description: >- commands, talk to an agent, and discover what makes Warp different. --- import { Tabs, TabItem } from '@astrojs/starlight/components'; +import { VARS } from '@data/vars'; Get up and running with Warp in about 10 minutes. Install the app, run your first commands using Blocks and the modern text editor, and start an agent conversation to write code, debug issues, or explore your codebase, all from natural language prompts inside the terminal. @@ -90,7 +91,7 @@ Learn more about [Autosuggestions](/terminal/command-completions/autosuggestions ## 5. Ask your first agent question -Everything you've done so far has been in **terminal mode**, running shell commands the way you normally would. Warp also has **Agent Mode**, a dedicated conversation view where you interact with Oz, Warp's built-in agent, using natural language. +Everything you've done so far has been in **terminal mode**, running shell commands the way you normally would. Warp also has **Agent Mode**, a dedicated conversation view where you interact with {VARS.WARP_AUTOMATION_PLATFORM}, Warp's built-in agent, using natural language. Start an agent conversation by pressing `⌘↩` (macOS) or `Ctrl+Shift+Enter` (Windows/Linux). Then type a prompt: @@ -98,7 +99,7 @@ Start an agent conversation by pressing `⌘↩` (macOS) or `Ctrl+Shift+Enter` ( Explain the architecture of this project ``` -Oz reads your codebase, understands its structure, and responds with a context-aware explanation. From here you can ask follow-up questions, have Oz write or refactor code, debug errors, or run commands on your behalf — all within the same conversation. +{VARS.WARP_AUTOMATION_PLATFORM} reads your codebase, understands its structure, and responds with a context-aware explanation. From here you can ask follow-up questions, have {VARS.WARP_AUTOMATION_PLATFORM} write or refactor code, debug errors, or run commands on your behalf — all within the same conversation. :::note You don't always need to switch modes manually. If you type a natural-language prompt in terminal mode, Warp auto-detects it and offers to send it to an agent. diff --git a/src/content/docs/reference/api-and-sdk/demo-sentry-monitoring-with-sdk.mdx b/src/content/docs/reference/api-and-sdk/demo-sentry-monitoring-with-sdk.mdx index 1f246efb..3bdfd4c2 100644 --- a/src/content/docs/reference/api-and-sdk/demo-sentry-monitoring-with-sdk.mdx +++ b/src/content/docs/reference/api-and-sdk/demo-sentry-monitoring-with-sdk.mdx @@ -5,10 +5,11 @@ description: >- and create draft PRs. --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; ### Turn production errors into draft PRs with Cloud Agents + TypeScript SDK - + :::note Example repository: [**Sentry monitor example repository**](https://github.com/warpdotdev/warp-agents-sdk-demo-sentry-monitor) diff --git a/src/content/docs/reference/api-and-sdk/index.mdx b/src/content/docs/reference/api-and-sdk/index.mdx index e2dfd68d..8c611490 100644 --- a/src/content/docs/reference/api-and-sdk/index.mdx +++ b/src/content/docs/reference/api-and-sdk/index.mdx @@ -1,18 +1,19 @@ --- -title: "Oz API & SDK reference" +title: "{{API_SDK_NAME}} reference" sidebar: - label: "Oz API & SDK" + label: "{{API_SDK_NAME}}" description: >- - Create and inspect cloud agent runs over HTTP with the Oz API, or use the - Python and TypeScript SDKs for typed requests, retries, and error handling. + Create and inspect cloud agent runs over HTTP, or use the Python and + TypeScript SDKs for typed requests, retries, and error handling. --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -The Oz API and SDKs let you create, monitor, and inspect cloud agent runs programmatically. Use the REST API from any HTTP client, or the official Python and TypeScript SDKs for typed requests, built-in retries, and structured error handling. The SDKs are ideal for CI pipelines, internal tools, and custom integrations. +The {VARS.API_SDK_NAME} lets you create, monitor, and inspect cloud agent runs programmatically. Use the REST API from any HTTP client, or the official Python and TypeScript SDKs for typed requests, built-in retries, and structured error handling. The SDKs are ideal for CI pipelines, internal tools, and custom integrations. -### Oz API +### API overview -The Oz API lets you create and inspect [Cloud Agent](/platform/) runs over HTTP from any system (CI, cron, backend services, internal tools), without requiring the Warp desktop app. +The {VARS.API_SDK_NAME} lets you create and inspect [Cloud Agent](/platform/) runs over HTTP from any system (CI, cron, backend services, internal tools), without requiring the Warp desktop app. **With the API you can:** @@ -26,9 +27,9 @@ This page is a high-level overview.\ For full API endpoint details, refer to the [**Agents API Reference**](/api). For schema definitions, see the SDK repos: [**Python SDK**](https://github.com/warpdotdev/oz-sdk-python) and [**TypeScript SDK**](https://github.com/warpdotdev/oz-sdk-typescript). ::: -### Oz SDK +### SDK overview -Oz provides official [Python](https://github.com/warpdotdev/oz-sdk-python) and [TypeScript](https://github.com/warpdotdev/oz-sdk-typescript) SDKs that wrap the Oz API with: +Warp provides official [Python](https://github.com/warpdotdev/oz-sdk-python) and [TypeScript](https://github.com/warpdotdev/oz-sdk-typescript) SDKs that wrap the {VARS.API_SDK_NAME} with: * **Typed requests and responses** (editor autocomplete, fewer schema mistakes) * **Built-in retries and timeouts** (with per-request overrides) @@ -37,7 +38,7 @@ Oz provides official [Python](https://github.com/warpdotdev/oz-sdk-python) and [ If you’re building an integration (CI, Slack bots, internal tooling, orchestrators), the SDKs are typically the quickest and safest starting point. - + **SDK vs raw REST** @@ -50,7 +51,7 @@ For the full SDK surface area and latest usage, refer to the GitHub repos: [**Py --- -## Oz API +## API reference ### REST API base URL @@ -135,11 +136,11 @@ The API shares a set of reusable models across endpoints. Detailed JSON schemas, --- -## Oz SDKs +## SDKs ### Python SDK -The Python SDK is the recommended way to call the Oz API from Python services and scripts. It provides: +The Python SDK is the recommended way to call the API from Python services and scripts. It provides: * Sync + async clients * Typed request/response models @@ -149,7 +150,7 @@ See the [**Python SDK GitHub repo**](https://github.com/warpdotdev/oz-sdk-python ### TypeScript SDK -The TypeScript SDK is the recommended way to call the Oz API from Node.js services and modern TS/JS runtimes. It provides: +The TypeScript SDK is the recommended way to call the API from Node.js services and modern TS/JS runtimes. It provides: * Fully typed params/responses * First-class error handling, retries/timeouts diff --git a/src/content/docs/reference/api-and-sdk/quickstart.mdx b/src/content/docs/reference/api-and-sdk/quickstart.mdx index 52d9b772..00107985 100644 --- a/src/content/docs/reference/api-and-sdk/quickstart.mdx +++ b/src/content/docs/reference/api-and-sdk/quickstart.mdx @@ -1,24 +1,25 @@ --- title: "API & SDK quickstart" description: >- - Create and monitor your first cloud agent run via the Oz API or SDK in ~5 + Create and monitor your first cloud agent run via the {{API_SDK_NAME}} in ~5 minutes. sidebar: label: "Quickstart" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -The Oz API lets you run and manage cloud agents from anywhere — CI/CD pipelines, backend services, scripts, or custom tooling — without the Warp desktop app. This quickstart walks you through creating your first run and checking its status. +The {VARS.API_SDK_NAME} lets you run and manage cloud agents from anywhere — CI/CD pipelines, backend services, scripts, or custom tooling — without the Warp desktop app. This quickstart walks you through creating your first run and checking its status. Watch this short demo of how the REST API can power agent-backed apps like [PowerFixer](https://github.com/warpdotdev/power-fixer-setup), an issue triage bot built by the Warp team: - + --- ## Prerequisites -* **A Warp API key** - Create one in the [Oz web app](https://oz.warp.dev/settings) and copy the raw value. Use a personal key if you want runs attributed to you, or an agent key to attribute runs to a [cloud agent](/platform/agents/). See [API Keys](/reference/cli/api-keys/) for the full flow. -* **An Oz cloud environment** - Agents run inside a configured environment that includes repos and other dependencies. If you don't have an environment yet, follow the [Cloud Agents Quickstart](/platform/quickstart/) first. +* **A Warp API key** - Create one in the {VARS.WEB_APP} and copy the raw value. Use a personal key if you want runs attributed to you, or an agent key to attribute runs to a [cloud agent](/platform/agents/). See [API Keys](/reference/cli/api-keys/) for the full flow. +* **A cloud environment** - Agents run inside a configured environment that includes repos and other dependencies. If you don't have an environment yet, follow the [Cloud Agents Quickstart](/platform/quickstart/) first. --- @@ -48,7 +49,7 @@ curl -X POST https://app.warp.dev/api/v1/agent/run \ }' ``` -Replace `` with your environment ID. Find it with `oz environment list` on the Oz CLI or in the [Oz web app](https://oz.warp.dev). +Replace `` with your environment ID. Find it with `oz environment list` on the {VARS.WARP_AGENT_CLI} or in the {VARS.WEB_APP}. :::note Prefer typed requests? The official [Python SDK](https://github.com/warpdotdev/oz-sdk-python) and [TypeScript SDK](https://github.com/warpdotdev/oz-sdk-typescript) wrap the same API with typed models, retries, and error handling. @@ -85,13 +86,13 @@ curl "https://app.warp.dev/api/v1/agent/runs" \ Once the run reaches `SUCCEEDED`, the response includes a `session_link` — a direct URL to the full run transcript, including commands executed, files changed, and agent output. -You can also view and manage all runs in the [Oz dashboard](https://oz.warp.dev/runs). +You can also view and manage all runs in the {VARS.DASHBOARD}. --- ## Next steps -* **Read the full API reference** - [Oz API](/reference/api-and-sdk/) documents all endpoint parameters, query filters, and response schemas. +* **Read the full API reference** - [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) documents all endpoint parameters, query filters, and response schemas. * **Explore the SDKs** - [Python SDK](https://github.com/warpdotdev/oz-sdk-python) and [TypeScript SDK](https://github.com/warpdotdev/oz-sdk-typescript) include typed request/response models, retries, and error handling. * **See a real-world example** - [Demo: Sentry monitoring with SDK](/reference/api-and-sdk/demo-sentry-monitoring-with-sdk/) shows how to build a webhook handler that triggers agents from production errors. * **Schedule and automate** - See [Scheduled Agents Quickstart](/platform/triggers/scheduled-agents-quickstart/) to run agents on a cron, or [Integrations Quickstart](/platform/integrations/quickstart/) to trigger agents from Slack or Linear. diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/authentication-required.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/authentication-required.mdx index ec348aef..37e3adcd 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/authentication-required.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/authentication-required.mdx @@ -4,6 +4,7 @@ description: >- The API key in the request is invalid, expired, or missing. Generate a new key and update your client configuration. --- +import { VARS } from '@data/vars'; The `authentication_required` error occurs when the API request lacks valid authentication credentials. @@ -48,7 +49,7 @@ This error is returned when: ## How to resolve -1. Generate a new API key from the [Oz web app](https://oz.warp.dev) or via the Oz CLI. +1. Generate a new API key from the {VARS.WEB_APP} or via the {VARS.WARP_AGENT_CLI}. 2. Update your client configuration with the new key. 3. Retry the request. @@ -56,5 +57,5 @@ This error is returned when: ## Related -* [Oz API & SDK](/reference/api-and-sdk/) — API authentication -* [Oz Platform](/platform/overview/) — API key management +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) — API authentication +* [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) — API key management diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/conflict.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/conflict.mdx index f13e52c5..489a0620 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/conflict.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/conflict.mdx @@ -6,6 +6,7 @@ description: >- The request conflicts with the current state of the resource. Wait for the resource to reach the expected state and retry. --- +import { VARS } from '@data/vars'; The `conflict` error occurs when a request cannot be completed because the resource is in a state that conflicts with the requested operation. @@ -56,4 +57,4 @@ For task cancellation specifically, wait until the task moves from **pending** t ## Related * [Managing Cloud Agents](/platform/managing-cloud-agents/) — Viewing and managing agent tasks -* [Oz API & SDK](/reference/api-and-sdk/) — API reference for managing agent tasks +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) — API reference for managing agent tasks diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/index.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/index.mdx index e8f2a92f..af404613 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/index.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/index.mdx @@ -1,12 +1,13 @@ --- title: Errors Overview description: >- - Reference for all error codes returned by the Oz platform API. Each error + Reference for all error codes returned by the {{API_SDK_NAME}}. Each error includes an HTTP status, machine-readable code, and actionable resolution steps. --- +import { VARS } from '@data/vars'; -When the Oz platform API encounters an error, it returns a structured JSON response following [RFC 7807 (Problem Details for HTTP APIs)](https://datatracker.ietf.org/doc/html/rfc7807). Every error response includes a machine-readable error code, a human-readable message, and metadata to help you diagnose and resolve the issue. +When the {VARS.API_SDK_NAME} encounters an error, it returns a structured JSON response following [RFC 7807 (Problem Details for HTTP APIs)](https://datatracker.ietf.org/doc/html/rfc7807). Every error response includes a machine-readable error code, a human-readable message, and metadata to help you diagnose and resolve the issue. --- @@ -86,6 +87,6 @@ When an error response includes a `trace_id`, you can include it when [contactin ## Related -* [Oz API & SDK](/reference/api-and-sdk/) — API reference for creating and managing agent tasks +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) — API reference for creating and managing agent tasks * [Cloud Agents Overview](/platform/) — How cloud agents work * [Access, Billing, and Identity](/platform/team-access-billing-and-identity/) — Plan requirements and billing details diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/integration-disabled.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/integration-disabled.mdx index 1573fceb..91cdccec 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/integration-disabled.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/integration-disabled.mdx @@ -1,11 +1,12 @@ --- title: integration_disabled description: >- - The integration (Slack, Linear, etc.) is currently disabled in the Oz - settings. Enable it to continue. + The integration (Slack, Linear, etc.) is currently disabled in the + {{WARP_AUTOMATION_PLATFORM}} settings. Enable it to continue. --- +import { VARS } from '@data/vars'; -The `integration_disabled` error occurs when a task targets an integration that is currently disabled in the Oz settings. +The `integration_disabled` error occurs when a task targets an integration that is currently disabled in the {VARS.WARP_AUTOMATION_PLATFORM} settings. --- @@ -21,7 +22,7 @@ The `integration_disabled` error occurs when a task targets an integration that This error is returned when: -* A Slack message, Linear issue, or other integration event triggers a cloud agent, but the corresponding integration has been disabled in the Oz settings +* A Slack message, Linear issue, or other integration event triggers a cloud agent, but the corresponding integration has been disabled in the {VARS.WARP_AUTOMATION_PLATFORM} settings * The integration was previously active but has been turned off by a team admin --- @@ -43,7 +44,7 @@ This error is returned when: ## How to resolve -1. Go to the [Oz integrations page](https://oz.warp.dev/integrations). +1. Go to the {VARS.WARP_AUTOMATION_PLATFORM} integrations page. 2. Enable the integration that was disabled. 3. Retry the triggering event or task. @@ -52,4 +53,4 @@ This error is returned when: ## Related * [Integrations](/platform/integrations/) — Configuring Slack, Linear, and GitHub integrations -* [Oz Web App](/platform/oz-web-app/) — Managing integrations via the web interface +* [{VARS.WEB_APP}](/platform/oz-web-app/) — Managing integrations via the web interface diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/integration-not-configured.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/integration-not-configured.mdx index 23d638cb..24b249f9 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/integration-not-configured.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/integration-not-configured.mdx @@ -4,6 +4,7 @@ description: >- The integration's setup is incomplete. Visit the setup URL to finish configuring the integration. --- +import { VARS } from '@data/vars'; The `integration_not_configured` error occurs when a task requires an integration whose setup has not been completed (for example, missing OAuth tokens or unfinished configuration steps). @@ -55,7 +56,7 @@ This error includes extra fields beyond the standard response format: ## How to resolve -1. Visit the `setup_url` provided in the response metadata (or go to the [Oz integrations page](https://oz.warp.dev/integrations)). +1. Visit the `setup_url` provided in the response metadata (or go to the {VARS.WARP_AUTOMATION_PLATFORM} integrations page). 2. Complete all setup steps for the integration. 3. Retry the triggering event or task. diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/invalid-request.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/invalid-request.mdx index 86a83033..dc807a2f 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/invalid-request.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/invalid-request.mdx @@ -4,6 +4,7 @@ description: >- The request body is malformed, missing required fields, or contains invalid parameter values. --- +import { VARS } from '@data/vars'; The `invalid_request` error occurs when the API request is malformed or contains invalid parameters. @@ -57,4 +58,4 @@ The `detail` field in the response will describe the specific validation issue. ## Related -* [Oz API & SDK](/reference/api-and-sdk/) — API request format and parameters +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) — API request format and parameters diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/not-authorized.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/not-authorized.mdx index 5e7e1917..964bbfc1 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/not-authorized.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/not-authorized.mdx @@ -4,6 +4,7 @@ description: >- The authenticated user or API key does not have permission to perform the requested operation. --- +import { VARS } from '@data/vars'; The `not_authorized` error occurs when the authenticated principal (user or API key) does not have sufficient permissions to perform the requested operation. @@ -55,4 +56,4 @@ This error is returned when: ## Related * [Access, Billing, and Identity](/platform/team-access-billing-and-identity/) — Permission model and identity -* [Oz API & SDK](/reference/api-and-sdk/) — API authentication and authorization +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) — API authentication and authorization diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/operation-not-supported.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/operation-not-supported.mdx index 8dae9b3c..eaabaa54 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/operation-not-supported.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/operation-not-supported.mdx @@ -4,6 +4,7 @@ description: >- The requested operation is not supported for this resource or its current state. --- +import { VARS } from '@data/vars'; The `operation_not_supported` error occurs when you attempt an operation that is not currently supported for the given resource or its current state. @@ -56,4 +57,4 @@ This error is returned when: * [Cloud Agents Overview](/platform/) — How cloud agent tasks work * [Self-hosting](/platform/self-hosting/) — Self-hosted agent configuration -* [Oz API & SDK](/reference/api-and-sdk/) — API reference for managing agent tasks +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) — API reference for managing agent tasks diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/resource-not-found.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/resource-not-found.mdx index 45cc276a..e3f7f36f 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/resource-not-found.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/resource-not-found.mdx @@ -4,6 +4,7 @@ description: >- The requested resource (task, environment, schedule, agent, etc.) does not exist or has been deleted. --- +import { VARS } from '@data/vars'; The `resource_not_found` error occurs when a referenced resource cannot be found. This typically means the resource ID is incorrect, the resource has been deleted, or it belongs to a different team. @@ -48,7 +49,7 @@ The `detail` field in the response will describe which resource was not found. ## How to resolve 1. Verify the resource ID is correct and properly formatted. -2. Check that the resource has not been deleted (for example, via the [Oz web app](https://oz.warp.dev) or CLI). +2. Check that the resource has not been deleted (for example, via the {VARS.WEB_APP} or CLI). 3. Confirm the resource belongs to your team or that you have access to it. --- diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/index.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/index.mdx index f183b8f8..097333f4 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/index.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/index.mdx @@ -1,11 +1,12 @@ --- title: API Troubleshooting description: >- - Troubleshooting resources for the Oz API and SDK, including a full reference + Troubleshooting resources for the {{API_SDK_NAME}}, including a full reference for all platform error codes. --- +import { VARS } from '@data/vars'; -When the Oz platform API encounters an error, it returns a structured response following [RFC 7807 (Problem Details for HTTP APIs)](https://datatracker.ietf.org/doc/html/rfc7807) with a machine-readable error code, HTTP status, and actionable resolution steps. +When the {VARS.API_SDK_NAME} encounters an error, it returns a structured response following [RFC 7807 (Problem Details for HTTP APIs)](https://datatracker.ietf.org/doc/html/rfc7807) with a machine-readable error code, HTTP status, and actionable resolution steps. ## Resources diff --git a/src/content/docs/reference/cli/agent-profiles.mdx b/src/content/docs/reference/cli/agent-profiles.mdx index 3fdf1175..179d02a7 100644 --- a/src/content/docs/reference/cli/agent-profiles.mdx +++ b/src/content/docs/reference/cli/agent-profiles.mdx @@ -1,13 +1,18 @@ --- title: Agent profiles description: >- - Use agent profiles with the Oz CLI to control what the agent can access, how + Use agent profiles with the {{WARP_AGENT_CLI}} to control what the agent can access, how it behaves, and where it can act. sidebar: label: "Agent Profiles" --- +import { VARS } from '@data/vars'; -Agent profiles control what the agent can do, how it behaves, and where it can act when running from the Oz CLI. Create profiles in the Warp app to configure file access, command execution, MCP server usage, model selection, and directory permissions, then reference them by ID in CLI commands. +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: + +Agent profiles control what the agent can do, how it behaves, and where it can act when running from the {VARS.WARP_AGENT_CLI}. Create profiles in the Warp app to configure file access, command execution, MCP server usage, model selection, and directory permissions, then reference them by ID in CLI commands. Agent profiles control three things: diff --git a/src/content/docs/reference/cli/api-keys.mdx b/src/content/docs/reference/cli/api-keys.mdx index 4e45f120..c9391158 100644 --- a/src/content/docs/reference/cli/api-keys.mdx +++ b/src/content/docs/reference/cli/api-keys.mdx @@ -1,12 +1,17 @@ --- -title: API keys for the Oz CLI +title: "API keys for the {{WARP_AGENT_CLI}}" description: >- - Create and manage API keys for authenticating the Oz CLI and cloud agents. + Create and manage API keys for authenticating the {{WARP_AGENT_CLI}} and cloud agents. sidebar: label: "API keys" --- +import { VARS } from '@data/vars'; -API keys let the Oz CLI and cloud agents authenticate without human interaction. Use API keys for CI pipelines, headless servers, VMs, Codespaces, containers, and other automated environments. +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: + +API keys let the {VARS.WARP_AGENT_CLI} and cloud agents authenticate without human interaction. Use API keys for CI pipelines, headless servers, VMs, Codespaces, containers, and other automated environments. ## Personal vs. agent keys @@ -17,11 +22,11 @@ Every API key is either a **personal API key** or an **agent API key**. ## Creating an API key -You can create an API key in either the [Oz web app](https://oz.warp.dev/settings) or the Warp app. Both surfaces produce keys that authenticate the CLI and SDK identically. +You can create an API key in either the {VARS.WEB_APP} or the Warp app. Both surfaces produce keys that authenticate the CLI and SDK identically. -### From the Oz web app (recommended) +### From the web app (recommended) -1. Open the [Oz web app settings page](https://oz.warp.dev/settings). +1. Open the {VARS.WEB_APP} settings page. 2. In the API keys section, click **Generate new token**. 3. Choose the type: * **Personal** — Tied to your individual Warp account. @@ -33,7 +38,7 @@ You can create an API key in either the [Oz web app](https://oz.warp.dev/setting ### From the Warp app 1. In the Warp app, click your profile photo in the top-right corner, then click **Settings**. -2. In the sidebar, expand **Cloud platform** and click **Oz Cloud API Keys**. +2. In the sidebar, expand **Cloud platform** and click **{VARS.WARP_AUTOMATION_PLATFORM} Cloud API Keys**. 3. In the API Keys section, click **+ Create API Key**. 4. Pick **Personal** for a personal key, or **Agent** / **Team** for an agent key tied to your team. (The toggle may still read **Team** in older versions of the desktop app.) 5. Name the key and choose an expiration (1 day, 30 days, 90 days, or never). @@ -86,13 +91,13 @@ API keys start with the prefix `wk-`. If your key doesn't have this prefix, it m ## Managing API keys -The [Oz web app settings page](https://oz.warp.dev/settings) and the Warp app's **Settings** > **Cloud platform** > **Oz Cloud API Keys** both list your active keys. Both surfaces show: +The {VARS.WEB_APP} settings page and the Warp app's **Settings** > **Cloud platform** > **{VARS.WARP_AUTOMATION_PLATFORM} Cloud API Keys** both list your active keys. Both surfaces show: * **Name** — The name you assigned when creating the key. * **Scope** — Personal keys show your user; agent keys show the cloud agent the key runs as. * **Expires at** — The key's expiration date, or "Never" if it doesn't expire. -The Warp app also shows additional metadata that isn't surfaced in the Oz web app: +The Warp app also shows additional metadata that isn't surfaced in the {VARS.WEB_APP}: * **Key** — A masked suffix (`wk-**xxxx`) to help identify the key. * **Created** — When the key was created. @@ -100,13 +105,13 @@ The Warp app also shows additional metadata that isn't surfaced in the Oz web ap ### Deleting API keys -To delete an API key, find it in either the Oz web app or the Warp app's API Keys list and click the delete icon next to the key. +To delete an API key, find it in either the {VARS.WEB_APP} or the Warp app's API Keys list and click the delete icon next to the key. Deleted keys are immediately invalidated and cannot be recovered. Any services or scripts using the deleted key will lose access and may return an [`authentication_required` error](/reference/api-and-sdk/troubleshooting/errors/authentication-required/). ## Manage API keys from the CLI -In addition to the web and Warp app surfaces, you can manage API keys directly with the [Oz CLI](/reference/cli/). These commands are useful for scripting key rotation and for headless environments. +In addition to the web and Warp app surfaces, you can manage API keys directly with the [{VARS.WARP_AGENT_CLI}](/reference/cli/). These commands are useful for scripting key rotation and for headless environments. ### List keys diff --git a/src/content/docs/reference/cli/artifacts.mdx b/src/content/docs/reference/cli/artifacts.mdx index d8380416..752cea23 100644 --- a/src/content/docs/reference/cli/artifacts.mdx +++ b/src/content/docs/reference/cli/artifacts.mdx @@ -6,8 +6,13 @@ description: >- sidebar: label: "Artifacts" --- +import { VARS } from '@data/vars'; -Artifacts are files that an agent produces during a run and uploads to Oz — screenshots, generated reports, build outputs, logs, or any other file the agent saves alongside its conversation. Use `oz artifact` to inspect those files from outside the run and pull them down to your machine. +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: + +Artifacts are files that an agent produces during a run and uploads to Warp — screenshots, generated reports, build outputs, logs, or any other file the agent saves alongside its conversation. Use `oz artifact` to inspect those files from outside the run and pull them down to your machine. ## When to use artifacts @@ -17,7 +22,7 @@ Use artifacts when you need to retrieve files an agent produced after a run comp * **Local inspection** - Pull a generated file (HTML, image, CSV) onto your laptop to review. * **CI integration** - Fetch an agent-produced build artifact from a pipeline step that runs after the agent finishes. -Artifacts are referenced by an artifact UID. You can find UIDs in the agent's run detail view, in the JSON returned by [`oz run get`](/reference/cli/), or in the response from the [Oz API](/reference/api-and-sdk/). +Artifacts are referenced by an artifact UID. You can find UIDs in the agent's run detail view, in the JSON returned by [`oz run get`](/reference/cli/), or in the response from the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/). ## `oz artifact get` @@ -73,5 +78,5 @@ oz artifact download "$ARTIFACT_UID" --out ./latest-report.html ## Related -* [Oz API & SDK](/reference/api-and-sdk/) - retrieve artifacts programmatically over HTTP. +* [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) - retrieve artifacts programmatically over HTTP. * [Scheduled cloud agents](/platform/triggers/scheduled-agents/) - common producer of recurring artifacts that downstream tooling consumes. diff --git a/src/content/docs/reference/cli/federate.mdx b/src/content/docs/reference/cli/federate.mdx index 7e92d5d1..ee29e6f6 100644 --- a/src/content/docs/reference/cli/federate.mdx +++ b/src/content/docs/reference/cli/federate.mdx @@ -6,6 +6,11 @@ description: >- sidebar: label: "Federated identity" --- +import { VARS } from '@data/vars'; + +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: `oz federate` issues short-lived OIDC identity tokens for the agent that's currently running. Use these tokens to authenticate to cloud providers (AWS, GCP, Azure, and other OIDC-aware systems) without baking long-lived credentials into your environment. @@ -35,7 +40,7 @@ oz federate issue-token \ ### Flags -* **`--run-id `** - The ID of the Oz run requesting the token. The token is bound to this run. +* **`--run-id `** - The ID of the {VARS.PLATFORM_RUN} requesting the token. The token is bound to this run. * **`--audience `** - The `aud` claim for the issued token. Set this to the value your cloud provider's identity pool expects (for example, an AWS IAM Identity Center audience or a GCP workload identity pool URL). * **`--duration `** - Requested token lifetime. Accepts human-readable durations like `15m`, `1h`, or `2h30m`. Defaults to `1h`. * **`--subject-template ...`** - Controls how the OIDC token's `sub` claim is formatted. Pass one or more components, which are joined to form the subject. Defaults to `principal` (for example, `user:my-user-id`). @@ -78,7 +83,7 @@ oz federate issue-token \ ## Using tokens with cloud providers -Once you have a token, exchange it for cloud credentials using your provider's standard OIDC federation flow. The exchange happens between the cloud provider and your script — Oz only issues the OIDC token. +Once you have a token, exchange it for cloud credentials using your provider's standard OIDC federation flow. The exchange happens between the cloud provider and your script — {VARS.WARP_AUTOMATION_PLATFORM} only issues the OIDC token. A typical AWS flow: diff --git a/src/content/docs/reference/cli/index.mdx b/src/content/docs/reference/cli/index.mdx index 03838d7c..4aa09e8d 100644 --- a/src/content/docs/reference/cli/index.mdx +++ b/src/content/docs/reference/cli/index.mdx @@ -1,25 +1,30 @@ --- -title: Oz CLI reference +title: "{{WARP_AGENT_CLI}} reference" sidebar: - label: "Oz CLI" + label: "{{WARP_AGENT_CLI}}" description: >- - Use the Oz CLI to run, configure, and manage agents from the terminal. + Use the {{WARP_AGENT_CLI}} to run, configure, and manage agents from the terminal. --- import { Tabs, TabItem } from '@astrojs/starlight/components'; +import { VARS } from '@data/vars'; -The Oz CLI is the command-line tool for running and managing Warp's cloud agents from any terminal, script, or CI pipeline. Use it to start agents locally or in the cloud, connect MCP servers, configure integrations, and authenticate without requiring the Warp desktop app. +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: + +The {VARS.WARP_AGENT_CLI} is the command-line tool for running and managing Warp's cloud agents from any terminal, script, or CI pipeline. Use it to start agents locally or in the cloud, connect MCP servers, configure integrations, and authenticate without requiring the Warp desktop app. :::note **`warp-cli` is deprecated and has been replaced by `oz`.** If you have `warp-cli` installed, it will auto-update to `oz`. All the same commands are available, just replace `warp-cli` with `oz` in your scripts and workflows. ::: -## What is the Oz CLI? +## What is the CLI? -The Oz CLI is the command-line tool that lets you run [Cloud Agents](/platform/) from anywhere, including terminals, scripts, automated systems, or services. +The {VARS.WARP_AGENT_CLI} is the command-line tool that lets you run [Cloud Agents](/platform/) from anywhere, including terminals, scripts, automated systems, or services. It's the standard runtime entry point that turns a **prompt** plus **configuration** into an **executable agent task** that runs on either a **Warp-hosted or [self-hosted](/platform/self-hosting/) runner**. -With the Oz CLI, you can: +With the {VARS.WARP_AGENT_CLI}, you can: * Run agents locally for development and debugging * Run agents on remote machines @@ -28,18 +33,18 @@ With the Oz CLI, you can: ## Installing the CLI -You can install the Oz CLI as part of the Warp desktop app, or as a standalone package. +You can install the {VARS.WARP_AGENT_CLI} as part of the Warp desktop app, or as a standalone package. ### Bundled with Warp -The Oz CLI is automatically distributed with the Warp desktop app and can be used right away in Warp. To make the CLI globally available, add it to your `PATH`. +The {VARS.WARP_AGENT_CLI} is automatically distributed with the Warp desktop app and can be used right away in Warp. To make the CLI globally available, add it to your `PATH`. - To add the Oz CLI to your `PATH`: + To add the {VARS.WARP_AGENT_CLI} to your `PATH`: 1. Open the [Command Palette](/terminal/command-palette/) (`Cmd+P`) - 2. In the search field, find and select the **Install Oz CLI Command** action. + 2. In the search field, find and select the **Install {VARS.WARP_AGENT_CLI} Command** action. :::note **Note:** Administrator permissions are required to install the CLI into `/usr/local/bin` . @@ -49,7 +54,7 @@ The Oz CLI is automatically distributed with the Warp desktop app and can be use In the Warp installer, select **Add Warp to PATH**. If you are installing for all users, this will put the CLI on the system path. Otherwise, the CLI is only added to the path for your account. - To run the Oz CLI on Linux, use the same command that you'd use to start Warp normally. If you installed Warp via a package manager, it should already be on the system `PATH`. + To run the {VARS.WARP_AGENT_CLI} on Linux, use the same command that you'd use to start Warp normally. If you installed Warp via a package manager, it should already be on the system `PATH`. @@ -113,7 +118,7 @@ Warp provides standalone packages for the CLI on macOS and Linux, without the Wa * aarch64: [`.deb`](https://app.warp.dev/download/cli?os=linux\&package=deb\&arch=aarch64), [`.rpm`](https://app.warp.dev/download/cli?os=linux\&package=rpm\&arch=aarch64), [pacman](https://app.warp.dev/download/cli?os=linux\&package=pacman\&arch=aarch64) - A standalone CLI package is not currently available on Windows. To use the Oz CLI on Windows, install the Warp app, which bundles the CLI. + A standalone CLI package is not currently available on Windows. To use the {VARS.WARP_AGENT_CLI} on Windows, install the Warp app, which bundles the CLI. You can install Warp using [WinGet](https://learn.microsoft.com/en-us/windows/package-manager/winget/): @@ -131,7 +136,7 @@ Regardless of your OS or installation method, the CLI command is `oz`. If you're ## Logging in -The Oz CLI supports two authentication methods, depending on where and how you're running agents. +The {VARS.WARP_AGENT_CLI} supports two authentication methods, depending on where and how you're running agents. * **Interactive login —** best for local machines where you have Warp installed and can authenticate through a browser. * **API keys** — best for automated or remote environments that need to authenticate without human interaction. @@ -201,7 +206,7 @@ $ oz agent run --prompt "analyze this codebase" ## Running agents -The Oz CLI offers two ways to run agents, depending on where you want the work to happen: +The {VARS.WARP_AGENT_CLI} offers two ways to run agents, depending on where you want the work to happen: **Use `oz agent run` when:** @@ -306,7 +311,7 @@ The `--name` flag assigns a config name to the run. Use it to group related runs **Why naming matters:** -When your team runs many agents across schedules, integrations, and ad-hoc triggers, `name` lets you answer questions like "how many distinct workflows are we running?" and "how often does this particular workflow run?" You can filter runs by name using the `name` query parameter on `GET /agent/runs` in the [Oz API](/reference/api-and-sdk/). +When your team runs many agents across schedules, integrations, and ad-hoc triggers, `name` lets you answer questions like "how many distinct workflows are we running?" and "how often does this particular workflow run?" You can filter runs by name using the `name` query parameter on `GET /agent/runs` in the [{VARS.API_SDK_NAME}](/reference/api-and-sdk/). **Examples:** @@ -392,7 +397,7 @@ The `--share` flag can be repeated, and uses the following syntax: ## Additional commands -The following commands are available for managing and inspecting Oz resources. +The following commands are available for managing and inspecting Warp resources. ### Managing named agents diff --git a/src/content/docs/reference/cli/integration-setup.mdx b/src/content/docs/reference/cli/integration-setup.mdx index a3099d47..42fea0b5 100644 --- a/src/content/docs/reference/cli/integration-setup.mdx +++ b/src/content/docs/reference/cli/integration-setup.mdx @@ -1,11 +1,16 @@ --- title: Integration setup description: >- - Learn how to set up environments and integrations so you can trigger Oz + Learn how to set up environments and integrations so you can trigger agents from external tools. sidebar: label: "Integration Setup" --- +import { VARS } from '@data/vars'; + +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: This article describes the environment and integration setup that is required before you can trigger agents from external tools, like Slack or Linear. You will learn how to: @@ -29,7 +34,7 @@ Warp integrations connect external tools, like Slack or Linear, to agents that r There are three main components to know: -* **Triggers** provide the context that tells Warp _what_ to run. A trigger could be a Slack message where you tag @Oz, or a Linear issue or comment. +* **Triggers** provide the context that tells Warp _what_ to run. A trigger could be a Slack message where you tag @{VARS.WARP_AUTOMATION_PLATFORM}, or a Linear issue or comment. * [**Integrations**](/platform/integrations/) are what connect the trigger surface (Slack, Linear) to Warp. An integration links the trigger to your [Warp team](/knowledge-and-collaboration/teams/) and handles posting results to the original tool, for example, replying in Slack. * **Environments** define how and where agents run your code. When an agent is triggered, Warp uses the environment to spin up a container, clone repositories, and execute the agent's workflow. @@ -50,7 +55,7 @@ Setting up an integration consists of three steps. 1. **Create an environment** for the agent to run your code. 2. **Authorize GitHub** so Warp can clone repositories, write code, debug issues, open pull requests, and more. -3. **Configure** the Oz app with an integration. +3. **Configure** the {VARS.WARP_AUTOMATION_PLATFORM} app with an integration. :::tip If setup fails, use the returned error code to narrow the fix. Common errors include: @@ -203,7 +208,7 @@ For full setup instructions, see [Team GitHub authorization](/platform/team-acce Once you have set up at least one environment, you can create integrations that connect it to Slack or Linear. :::note -For easier setup, use the [Oz web app](https://oz.warp.dev) to configure integrations with a guided flow. +For easier setup, use the {VARS.WEB_APP} to configure integrations with a guided flow. ::: Alternatively, use the CLI where `` is your environment ID: @@ -221,7 +226,7 @@ If you omit `--environment`, the CLI will show a list of environments and prompt The CLI then: 1. Links the integration to your Warp team and environment. -2. Opens a browser flow to install the Oz app into your Slack workspace or Linear workspace. +2. Opens a browser flow to install the {VARS.WARP_AUTOMATION_PLATFORM} app into your Slack workspace or Linear workspace. 3. Generates an **integration ID** you can later list or delete. :::note @@ -302,6 +307,6 @@ You now have everything needed to trigger agents from your team's tools. From he **Additional reading** * [Cloud Agents Overview](/platform/) -* [Oz Platform](/platform/overview/) +* [{VARS.WARP_AUTOMATION_PLATFORM}](/platform/overview/) * [Slack](/platform/integrations/slack/), [Linear](/platform/integrations/linear/), [GitHub](/platform/integrations/github/), and [GitHub Actions](/platform/integrations/github-actions/) integrations * [Troubleshooting](/reference/cli/troubleshooting/) diff --git a/src/content/docs/reference/cli/mcp-servers.mdx b/src/content/docs/reference/cli/mcp-servers.mdx index f1e803ff..f38fc2df 100644 --- a/src/content/docs/reference/cli/mcp-servers.mdx +++ b/src/content/docs/reference/cli/mcp-servers.mdx @@ -6,6 +6,11 @@ description: >- sidebar: label: "MCP servers" --- +import { VARS } from '@data/vars'; + +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: MCP servers connect agents to external systems like GitHub, Linear, or Sentry. To use a [Model Context Protocol (MCP)](/agents/capabilities/mcp/) server from the CLI, use the `--mcp` flag with `oz agent run` or `oz agent run-cloud`. @@ -102,7 +107,7 @@ $ oz agent run --mcp "904a8936-fa82-4571-b1d6-166c26197981" --prompt "use my MCP ``` :::note -For cloud agent workflows, use [Oz-managed secrets](/platform/secrets/) to store and inject credentials safely — secrets are stored in the cloud and referenced by name in your config. For local runs, a secrets manager CLI such as [`op`](https://developer.1password.com/docs/cli/get-started/), [`pass`](https://www.passwordstore.org/), or [`gcloud secrets versions access`](https://cloud.google.com/secret-manager/docs/create-secret-quickstart#secretmanager-quickstart-gcloud) can fetch secrets on remote hosts without exposing them in your shell history. +For cloud agent workflows, use [{VARS.WARP_AUTOMATION_PLATFORM}-managed secrets](/platform/secrets/) to store and inject credentials safely — secrets are stored in the cloud and referenced by name in your config. For local runs, a secrets manager CLI such as [`op`](https://developer.1password.com/docs/cli/get-started/), [`pass`](https://www.passwordstore.org/), or [`gcloud secrets versions access`](https://cloud.google.com/secret-manager/docs/create-secret-quickstart#secretmanager-quickstart-gcloud) can fetch secrets on remote hosts without exposing them in your shell history. ::: --- diff --git a/src/content/docs/reference/cli/quickstart.mdx b/src/content/docs/reference/cli/quickstart.mdx index 3950c22a..3ca6ae54 100644 --- a/src/content/docs/reference/cli/quickstart.mdx +++ b/src/content/docs/reference/cli/quickstart.mdx @@ -1,16 +1,21 @@ --- title: CLI quickstart description: >- - Set up and run your first cloud agent via the Oz CLI in less than 5 minutes. + Set up and run your first cloud agent via the {{WARP_AGENT_CLI}} in less than 5 minutes. sidebar: label: "Quickstart" --- import VideoEmbed from '@components/VideoEmbed.astro'; +import { VARS } from '@data/vars'; -This guide walks you through the essentials to get up and running with the Oz CLI in less than 5 minutes: installing the CLI, authenticating, running your first local agent, and optionally connecting MCP servers to give the agent access to external tools. +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: + +This guide walks you through the essentials to get up and running with the {VARS.WARP_AGENT_CLI} in less than 5 minutes: installing the CLI, authenticating, running your first local agent, and optionally connecting MCP servers to give the agent access to external tools. -Watch this short demo of the Oz CLI workflow: - +Watch this short demo of the {VARS.WARP_AGENT_CLI} workflow: + ## 1. Install the CLI @@ -39,7 +44,7 @@ Interactive login works on both **local** and **remote** machines, and does not export WARP_API_KEY="wk-..." ``` -Create an API key in the [Oz web app](https://oz.warp.dev/settings). See [API Keys](/reference/cli/api-keys/) for guidance on personal vs. [agent keys](/platform/agents/) and on security best practices. +Create an API key in the {VARS.WEB_APP}. See [API Keys](/reference/cli/api-keys/) for guidance on personal vs. [agent keys](/platform/agents/) and on security best practices. ::: ## 3. Run an agent @@ -68,7 +73,7 @@ If you haven't already created an environment, run `/create-environment` in Warp oz agent run-cloud --environment --prompt "Scan this repo for outdated dependencies" ``` -Replace `` with your environment ID, which you can find by running `oz environment list` on the Oz CLI. +Replace `` with your environment ID, which you can find by running `oz environment list` on the {VARS.WARP_AGENT_CLI}. ## 5. Add MCP context (optional) @@ -82,13 +87,13 @@ See [MCP Servers](/reference/cli/mcp-servers/) for all supported formats, includ ## Next steps -Once you've successfully set up and run your agent, explore other configurations and workflows with the Oz CLI: +Once you've successfully set up and run your agent, explore other configurations and workflows with the {VARS.WARP_AGENT_CLI}: * Customize behavior with [agent profiles](/reference/cli/agent-profiles/). * [Reuse prompts](/reference/cli/warp-drive/) with `--saved-prompt`. * Connect agents to external systems using [MCP Servers](/reference/cli/mcp-servers/). * Authenticate with [API keys](/reference/cli/api-keys/) for automated environments or workflows. -* Get up-to-date information about the Oz CLI using the [`oz help` command](/reference/cli/troubleshooting/#getting-help). +* Get up-to-date information about the {VARS.WARP_AGENT_CLI} using the [`oz help` command](/reference/cli/troubleshooting/#getting-help). * Run agents in CI with the [GitHub Actions quickstart](/platform/integrations/quickstart-github-actions/). -Continue reading the [Oz CLI reference](/reference/cli/) to learn how to install the CLI on different platforms, authenticate in different environments, and configure agents for real-world workflows. +Continue reading the [{VARS.WARP_AGENT_CLI} reference](/reference/cli/) to learn how to install the CLI on different platforms, authenticate in different environments, and configure agents for real-world workflows. diff --git a/src/content/docs/reference/cli/skills.mdx b/src/content/docs/reference/cli/skills.mdx index 1a2ca409..f718c98b 100644 --- a/src/content/docs/reference/cli/skills.mdx +++ b/src/content/docs/reference/cli/skills.mdx @@ -1,11 +1,16 @@ --- -title: "Skills via the Oz CLI" +title: "Skills via the {{WARP_AGENT_CLI}}" sidebar: label: "Skills" description: >- - Use skills with the Oz CLI to run agents from reusable skill definitions + Use skills with the {{WARP_AGENT_CLI}} to run agents from reusable skill definitions stored in your repositories. --- +import { VARS } from '@data/vars'; + +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: [Skills](/agents/capabilities/skills/) are reusable instruction sets that teach agents how to perform specific tasks. Use the `--skill` flag to run an agent from a skill in a repository accessible to your environment. diff --git a/src/content/docs/reference/cli/troubleshooting.mdx b/src/content/docs/reference/cli/troubleshooting.mdx index 0f239add..86e72c1f 100644 --- a/src/content/docs/reference/cli/troubleshooting.mdx +++ b/src/content/docs/reference/cli/troubleshooting.mdx @@ -1,11 +1,16 @@ --- title: CLI Troubleshooting description: >- - Solutions for common Oz CLI errors — including authentication issues, agent + Solutions for common {{WARP_AGENT_CLI}} errors — including authentication issues, agent failures, environments, GitHub access, and Docker image issues. --- +import { VARS } from '@data/vars'; -Solutions for common Oz CLI errors, including authentication issues, agent failures, environment configuration, GitHub access problems, and Docker image compatibility. Use `oz help` for built-in documentation on any command. +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: + +Solutions for common {VARS.WARP_AGENT_CLI} errors, including authentication issues, agent failures, environment configuration, GitHub access problems, and Docker image compatibility. Use `oz help` for built-in documentation on any command. ## Getting help diff --git a/src/content/docs/reference/cli/warp-drive.mdx b/src/content/docs/reference/cli/warp-drive.mdx index e72bf02c..425e4256 100644 --- a/src/content/docs/reference/cli/warp-drive.mdx +++ b/src/content/docs/reference/cli/warp-drive.mdx @@ -6,8 +6,13 @@ description: >- sidebar: label: "Warp Drive Context" --- +import { VARS } from '@data/vars'; -Reference saved Warp Drive objects in Oz CLI commands to reuse prompts, notebooks, workflows, and rules as agent context. Pass a saved prompt ID with `--saved-prompt` or inline Warp Drive references using ``, ``, or `` syntax. +:::caution +The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement. +::: + +Reference saved Warp Drive objects in {VARS.WARP_AGENT_CLI} commands to reuse prompts, notebooks, workflows, and rules as agent context. Pass a saved prompt ID with `--saved-prompt` or inline Warp Drive references using ``, ``, or `` syntax. ## Reusing saved prompts diff --git a/src/content/docs/reference/index.mdx b/src/content/docs/reference/index.mdx index 4acfd0f2..59996046 100644 --- a/src/content/docs/reference/index.mdx +++ b/src/content/docs/reference/index.mdx @@ -1,16 +1,17 @@ --- title: Technical reference description: >- - Technical reference documentation for the Oz CLI, API, and SDK. + Technical reference documentation for the {{WARP_AGENT_CLI}}, API, and SDK. --- +import { VARS } from '@data/vars'; -Technical reference documentation for the Oz CLI, API, and SDKs. Use these programmatic interfaces to run and manage agents from CI pipelines, scripts, backend services, and custom tooling without requiring the Warp desktop app. +Technical reference documentation for the {VARS.WARP_AGENT_CLI}, API, and SDKs. Use these programmatic interfaces to run and manage agents from CI pipelines, scripts, backend services, and custom tooling without requiring the Warp desktop app. ## CLI -The [Oz CLI](/reference/cli/) lets you run and configure agents from any environment — locally, in CI pipelines, or on remote machines. +The [{VARS.WARP_AGENT_CLI}](/reference/cli/) lets you run and configure agents from any environment — locally, in CI pipelines, or on remote machines. -- [API Keys](/reference/cli/api-keys/) - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and containers. +- [API Keys](/reference/cli/api-keys/) - Create and manage API keys to authenticate the {VARS.WARP_AGENT_CLI} without human interaction, ideal for CI pipelines, headless servers, and containers. - [Agent Profiles](/reference/cli/agent-profiles/) - Use agent profiles to control what the agent can access, how it behaves, and where it can act, including file access, command execution, and MCP server usage. - [MCP Servers](/reference/cli/mcp-servers/) - Pass MCP server configuration to agent runs using the `--mcp` flag, by UUID, inline JSON, or file path. - [Skills](/reference/cli/skills/) - Run agents from reusable instruction sets stored in your repositories using the `--skill` flag. @@ -20,6 +21,6 @@ The [Oz CLI](/reference/cli/) lets you run and configure agents from any environ ## API & SDK -The [Oz API](/reference/api-and-sdk/) lets you create and monitor cloud agent runs over HTTP. Official SDKs for [Python](https://github.com/warpdotdev/oz-sdk-python) and [TypeScript](https://github.com/warpdotdev/oz-sdk-typescript) provide typed clients with built-in retries and error handling. +The [{VARS.API_SDK_NAME}](/reference/api-and-sdk/) lets you create and monitor cloud agent runs over HTTP. Official SDKs for [Python](https://github.com/warpdotdev/oz-sdk-python) and [TypeScript](https://github.com/warpdotdev/oz-sdk-typescript) provide typed clients with built-in retries and error handling. - [Demo: Sentry monitoring with SDK](/reference/api-and-sdk/demo-sentry-monitoring-with-sdk/) - example integration diff --git a/src/content/docs/support-and-community/community/open-source-partnership.mdx b/src/content/docs/support-and-community/community/open-source-partnership.mdx index 8694c0a5..d704499e 100644 --- a/src/content/docs/support-and-community/community/open-source-partnership.mdx +++ b/src/content/docs/support-and-community/community/open-source-partnership.mdx @@ -1,21 +1,22 @@ --- -title: Oz Open Source Partnership +title: "{{WARP_AUTOMATION_PLATFORM}} Open Source Partnership" description: >- Warp supports high-impact open source projects with free agent credits - through the Oz Open Source Partnership program. + through the {{WARP_AUTOMATION_PLATFORM}} Open Source Partnership program. --- +import { VARS } from '@data/vars'; -Warp is committed to supporting the open source community. Through the Oz Open Source Partnership program, we offer free agent usage credits to high-impact open source projects, helping maintainers and contributors accelerate their development workflows. +Warp is committed to supporting the open source community. Through the {VARS.WARP_AUTOMATION_PLATFORM} Open Source Partnership program, we offer free agent usage credits to high-impact open source projects, helping maintainers and contributors accelerate their development workflows. ## What you get -* **Free Oz credits** - Receive complimentary credits to run agents on your open source project +* **Free {VARS.WARP_AUTOMATION_PLATFORM} credits** - Receive complimentary credits to run agents on your open source project * **Agent access** - Use cloud agents to automate tasks like code review, bug triage, documentation, and more across your repositories * **Ongoing support** - Warp partners with accepted projects to ensure they get the most value from agents ## Who can apply -The Oz Open Source Partnership program is designed for actively maintained, high-impact open source projects. When reviewing applications, we consider factors like community size, project activity, and the potential impact of agents on your workflow. +The {VARS.WARP_AUTOMATION_PLATFORM} Open Source Partnership program is designed for actively maintained, high-impact open source projects. When reviewing applications, we consider factors like community size, project activity, and the potential impact of agents on your workflow. :::note Have questions about the program? Reach out to us at [support@warp.dev](mailto:support@warp.dev). @@ -26,5 +27,5 @@ Have questions about the program? Reach out to us at [support@warp.dev](mailto:s Tell us about your open source project by filling out the [application form](https://tally.so/r/LZWxqG). We'll review your submission and follow up with next steps. :::note -The Oz Open Source Partnership program provides free agent credits for open source projects. This is separate from Warp's open source client — the Warp client is published under AGPL v3 at [`warpdotdev/warp`](https://github.com/warpdotdev/warp); see [Contributing to Warp](/support-and-community/community/contributing/). For sponsorship opportunities for your project, reach out to [partnerships@warp.dev](mailto:partnerships@warp.dev). +The {VARS.WARP_AUTOMATION_PLATFORM} Open Source Partnership program provides free agent credits for open source projects. This is separate from Warp's open source client — the Warp client is published under AGPL v3 at [`warpdotdev/warp`](https://github.com/warpdotdev/warp); see [Contributing to Warp](/support-and-community/community/contributing/). For sponsorship opportunities for your project, reach out to [partnerships@warp.dev](mailto:partnerships@warp.dev). ::: diff --git a/src/content/docs/support-and-community/index.mdx b/src/content/docs/support-and-community/index.mdx index c58f94b9..4e0363f7 100644 --- a/src/content/docs/support-and-community/index.mdx +++ b/src/content/docs/support-and-community/index.mdx @@ -4,6 +4,8 @@ description: >- Connect with the developers and engineers building with Warp. Share what you've built, shape what we build next, and get help when you're stuck. --- +import { VARS } from '@data/vars'; + ## Find your space ### Join the community @@ -43,7 +45,7 @@ We host [live events](https://luma.com/warpdotdev) year-round — product demos, * [**Warp Preview**](/support-and-community/community/warp-preview-and-alpha-program/) — Try experimental features before anyone else. Your feedback directly shapes what ships. * [**Refer a Friend**](/support-and-community/community/refer-a-friend/) — Send Warp to a developer you think would love it. Earn themes, swag, and gift cards. -* [**Oz Open Source Partnership**](/support-and-community/community/open-source-partnership/) — Free agent credits for high-impact open source projects. +* [**{VARS.WARP_AUTOMATION_PLATFORM} Open Source Partnership**](/support-and-community/community/open-source-partnership/) — Free agent credits for high-impact open source projects. :::note **Ambassador program** diff --git a/src/content/docs/support-and-community/plans-and-billing/credits.mdx b/src/content/docs/support-and-community/plans-and-billing/credits.mdx index 5c72466f..9234449d 100644 --- a/src/content/docs/support-and-community/plans-and-billing/credits.mdx +++ b/src/content/docs/support-and-community/plans-and-billing/credits.mdx @@ -5,6 +5,7 @@ sidebar: description: >- Details on Warp credits and how they are calculated. --- +import { VARS } from '@data/vars'; ### What are Warp credits? @@ -129,7 +130,7 @@ The following scenarios use compute credits: * **First-party integrations** - Running agents through Slack or Linear integrations * **Cloud agent runs** - Using `oz agent run-cloud` via the CLI -* **Oz API** - Running agents through Warp's Oz API +* **{VARS.API_SDK_NAME}** - Running agents through Warp's API * **Cloud Mode** - Running an agent from Cloud Mode in the Warp app #### Not eligible for compute credits @@ -155,7 +156,7 @@ The following scenarios do **not** use platform credits: * **Local agents on Free, Build, or Max plans** don't use platform credits, regardless of inference source. * **Local agents on Business or Enterprise using Warp-managed inference** don't use platform credits because Warp is already paying for the model call through AI credits. * **Regular terminal usage** doesn't use platform credits. Shell commands and non-AI Warp features don't consume credits. -* **Third-party agent CLIs run directly** don't use platform credits when you run `claude`, `codex`, or another agent CLI outside of Oz. +* **Third-party agent CLIs run directly** don't use platform credits when you run `claude`, `codex`, or another agent CLI outside of Warp. For a full breakdown of how platform credits work, see [platform credits](/support-and-community/plans-and-billing/platform-credits/). diff --git a/src/content/docs/support-and-community/plans-and-billing/platform-credits.mdx b/src/content/docs/support-and-community/plans-and-billing/platform-credits.mdx index f3db5923..171a2a2f 100644 --- a/src/content/docs/support-and-community/plans-and-billing/platform-credits.mdx +++ b/src/content/docs/support-and-community/plans-and-billing/platform-credits.mdx @@ -4,6 +4,7 @@ description: >- Platform credits cover Warp's platform layer on every cloud agent run and on local runs with customer-supplied inference. Learn when they apply. --- +import { VARS } from '@data/vars'; Platform credits cover Warp's platform infrastructure for coordinating, observing, and integrating agent runs. They apply to every cloud agent run, plus local agent runs on Business and Enterprise plans that use customer-supplied inference such as BYOK, a custom inference endpoint, or BYOLLM. @@ -20,7 +21,7 @@ BYOK and customer-supplied inference (custom inference endpoints, plus BYOLLM) a Each credit bucket covers a different layer of the infrastructure Warp provides. Credit types and where an agent runs (local or cloud) are independent — each agent run consumes from whichever credit types apply to it. * **AI credits** cover inference: the LLM call itself. Consumed when Warp pays for the model call through Warp-managed providers. Used by agent conversations, [Generate](/agents/local-agents/generate/), [AI Autofill](/knowledge-and-collaboration/warp-drive/workflows/#ai-autofill), and other AI features. See [credits](/support-and-community/plans-and-billing/credits/) for how AI credits are calculated. -* **Compute credits** cover compute: the sandbox an agent runs in. Consumed when an agent run uses Warp-hosted compute. In practice this is cloud agent runs (Slack and Linear integrations, `oz agent run-cloud`, the Oz API, and Cloud Mode in the Warp app); local agent runs use your own machine and don't consume compute credits. See [compute credits](/support-and-community/plans-and-billing/credits/#compute-credits). +* **Compute credits** cover compute: the sandbox an agent runs in. Consumed when an agent run uses Warp-hosted compute. In practice this is cloud agent runs (Slack and Linear integrations, `oz agent run-cloud`, the {VARS.API_SDK_NAME}, and Cloud Mode in the Warp app); local agent runs use your own machine and don't consume compute credits. See [compute credits](/support-and-community/plans-and-billing/credits/#compute-credits). * **Platform credits** cover Warp's platform layer: run lifecycle, integrations, dashboard, APIs, and observability. Apply to every cloud agent run, plus local agent runs on Business and Enterprise plans that use customer-supplied inference. The three buckets are independent and a single run can consume from more than one. A Warp-managed cloud agent run, for example, consumes AI credits for the model call, compute credits for the hosted compute, and platform credits for the platform infrastructure that runs the agent. @@ -45,7 +46,7 @@ Whether platform credits apply depends on where the agent runs and who's paying * **Local agents on Free, Build, or Max plans** don't use platform credits, regardless of whether you use Warp-managed inference or BYOK. * **Local agents on Business or Enterprise using Warp-managed inference** don't use platform credits because Warp is already paying for the model call through AI credits. * **Regular terminal usage** doesn't use platform credits. Shell commands and non-AI Warp features don't consume credits. -* **Third-party agent CLIs run directly** don't use platform credits when you run `claude`, `codex`, or another agent CLI without going through Oz. +* **Third-party agent CLIs run directly** don't use platform credits when you run `claude`, `codex`, or another agent CLI without going through Warp. ## Where platform credits appear diff --git a/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx b/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx index 4b53cf1b..adc2e4d8 100644 --- a/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx +++ b/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx @@ -6,6 +6,7 @@ description: >- Frequently asked questions about upgrading, managing billing, refunds, and invoicing with Warp's paid plans. --- +import { VARS } from '@data/vars'; ### How can I upgrade and subscribe to a Warp plan? @@ -254,7 +255,7 @@ The waterfall on the owner's account is: When auto-reload is **off**, the request is blocked once both buckets are depleted. When auto-reload is **on**, cloud agent usage can trigger auto-reload on the owner's pool subject to the team-wide spend cap; further cloud agent runs then draw from that reloaded balance until the cap is reached. -"Blocked" means the run fails immediately with an insufficient-credits error rather than queuing or retrying. For unattended runs (scheduled jobs, team-API-key triggers), this manifests as a failed run in the Oz dashboard with an [insufficient credits](/reference/api-and-sdk/troubleshooting/errors/insufficient-credits/) error code; the run won't be retried automatically. Owners should monitor the dashboard and configure spend caps with headroom for critical scheduled workloads. +"Blocked" means the run fails immediately with an insufficient-credits error rather than queuing or retrying. For unattended runs (scheduled jobs, team-API-key triggers), this manifests as a failed run in the {VARS.DASHBOARD} with an [insufficient credits](/reference/api-and-sdk/troubleshooting/errors/insufficient-credits/) error code; the run won't be retried automatically. Owners should monitor the dashboard and configure spend caps with headroom for critical scheduled workloads. :::note Enterprise plans support team-scoped credit pools, so this traffic draws from the team pool rather than an individual admin. See [enterprise billing](/enterprise/support-and-resources/billing/) for overage and contract terms. @@ -282,7 +283,7 @@ Warp doesn’t currently offer discounts for students or non-profits. We recomme For open source teams, two paths are available: -* The [Oz Open Source Partnership](/support-and-community/community/open-source-partnership/) program offers free agent credits to high-impact open source projects. +* The [{VARS.WARP_AUTOMATION_PLATFORM} Open Source Partnership](/support-and-community/community/open-source-partnership/) program offers free agent credits to high-impact open source projects. * Warp's client itself is open source under [AGPL v3](https://github.com/warpdotdev/warp/blob/master/LICENSE-AGPL), so you can build, run, and contribute to it directly. See [Contributing to Warp](/support-and-community/community/contributing/) for the flow. ### Where is Warp Drive data for my team stored? @@ -347,7 +348,7 @@ For lighter-weight routing through any OpenAI-compatible endpoint (OpenRouter, L ### What features are available during multi-harness orchestration beta? -Multi-harness orchestration is currently in beta and available to all users. You can use the [Warp Agent](/platform/harnesses/warp-agent/) alongside [Claude Code](/platform/harnesses/claude-code/) and [Codex](/platform/harnesses/codex/) in Oz cloud environments, and mix and match harnesses across workflows. +Multi-harness orchestration is currently in beta and available to all users. You can use the [Warp Agent](/platform/harnesses/warp-agent/) alongside [Claude Code](/platform/harnesses/claude-code/) and [Codex](/platform/harnesses/codex/) in {VARS.WARP_AUTOMATION_PLATFORM} cloud environments, and mix and match harnesses across workflows. [Agent Memory](/agents/agent-memory/) is currently in Research Preview. It lets preferences, project knowledge, and learnings from past sessions carry across harnesses and future agent runs. [Contact our sales team](https://www.warp.dev/contact-sales) to request access. diff --git a/src/content/docs/terminal/comparisons/index.mdx b/src/content/docs/terminal/comparisons/index.mdx index 16f22100..ca1a30e9 100644 --- a/src/content/docs/terminal/comparisons/index.mdx +++ b/src/content/docs/terminal/comparisons/index.mdx @@ -4,13 +4,14 @@ description: >- Compare Warp's performance and terminal feature support against other popular terminal emulators like iTerm2, Alacritty, and WezTerm. --- +import { VARS } from '@data/vars'; Warp is a modern terminal built in Rust with GPU rendering, agent support, and a code-editor-style input. Use this section to see how Warp stacks up against other popular terminals on raw performance and feature coverage. ## How Warp differs * **Open source under AGPL v3** — Warp's client lives at [`warpdotdev/warp`](https://github.com/warpdotdev/warp). You can read the code, build from source, and contribute. See [Contributing to Warp](/support-and-community/community/contributing/) for the flow. -* **Built-in agents** — Warp ships with Warp Agent (powered by Oz) and supports third-party CLI agents like Claude Code, Codex, and Gemini CLI from the same terminal. +* **Built-in agents** — Warp ships with Warp Agent (powered by {VARS.WARP_AUTOMATION_PLATFORM}) and supports third-party CLI agents like Claude Code, Codex, and Gemini CLI from the same terminal. * **Modern editing** — Cursor placement, multi-line input, block-based output, and integrated code review work like a text editor instead of a traditional terminal emulator. * **Cross-platform Rust core** — Warp ships on macOS, Linux, and Windows from a single Rust + GPU-rendered codebase. diff --git a/src/content/docs/terminal/input/classic-input.mdx b/src/content/docs/terminal/input/classic-input.mdx index 5e2ad62e..f8af5c89 100644 --- a/src/content/docs/terminal/input/classic-input.mdx +++ b/src/content/docs/terminal/input/classic-input.mdx @@ -6,6 +6,7 @@ description: >- box. --- import { Tabs, TabItem } from '@astrojs/starlight/components'; +import { VARS } from '@data/vars'; Classic Input corresponds to the **Shell (PS1)** option under **Settings** > **Appearance** > **Input**. It provides a traditional terminal experience with support for shell customizations like PS1 prompts, oh-my-zsh themes, same-line prompts, and more. @@ -94,7 +95,7 @@ Warp input occasionally shows hints within the input editor in a light grey text ## How to run commands in Agent Mode -Once you have typed your question or task in the input, press `Enter` to execute your AI query. Agent Mode will send your request to Oz and begin streaming output in the form of an AI block. +Once you have typed your question or task in the input, press `Enter` to execute your AI query. Agent Mode will send your request to {VARS.WARP_AUTOMATION_PLATFORM} and begin streaming output in the form of an AI block. Unlike a chat panel, Agent Mode can complete tasks for you by running commands directly in your session. @@ -112,7 +113,7 @@ If the suggested command fails and you want to resolve the error, you can start If Agent Mode doesn't have enough context to assist with a task, it will ask permission to run a command and read the output of that command. -You must explicitly agree and press `Enter` to run the requested command. When you hit enter, both the command input and the output will be sent to Oz. +You must explicitly agree and press `Enter` to run the requested command. When you hit enter, both the command input and the output will be sent to {VARS.WARP_AUTOMATION_PLATFORM}. If you do not wish to send the command or its output to AI, you can click Cancel or press `Ctrl+C` to exit Agent Mode and return to the traditional command line. @@ -128,6 +129,6 @@ Once a requested command is executed, you can click to expand the output and vie
Viewing command details.
-If a requested command fails, Oz detects it. Agent Mode is self-correcting. It will request another command until it completes the task for you. +If a requested command fails, {VARS.WARP_AUTOMATION_PLATFORM} detects it. Agent Mode is self-correcting. It will request another command until it completes the task for you. Warp lets you choose from a curated list of LLMs for use in Agent Mode. By default, Warp uses **Auto (Responsive)**, which routes to the highest-quality, fastest available model. You can switch to other supported models — see [Model choice](/agents/inference/model-choice/) for the full list. diff --git a/src/data/vars.ts b/src/data/vars.ts index 4647ca31..bdfbeb47 100644 --- a/src/data/vars.ts +++ b/src/data/vars.ts @@ -8,12 +8,20 @@ export const VARS = { // Platform — keys named for upcoming Warp branding; values are current Oz names - WARP_AUTOMATION_PLATFORM: "Oz", // value → "Warp Automation Platform" at rename + WARP_AUTOMATION_PLATFORM: "Oz", // value → "Warp Automation Platform" at rename (PENDING final naming confirmation from ZL) WARP_AGENT_CLI: "Oz CLI", // value → "Warp Agent CLI" at rename - WEB_APP: "Oz web app", // future name TBD + WEB_APP: "Oz web app", // legacy Oz v1 webapp (oz.warp.dev) — stays unrenamed through 9/15 WEB_APP_URL: "https://oz.warp.dev", // value → "https://app.warp.dev" at rename DASHBOARD: "Oz dashboard", // future name TBD PLATFORM_RUN: "Oz run", // future name TBD + API_SDK_NAME: "Oz API & SDK", // value → "Warp API & SDK" at rename + + // Warp Factories web app — a net-new product surface at platform.warp.dev + // (soft launch ~2026-08-18), separate from the legacy Oz v1 webapp above. + // Not rename-sensitive: this is a new reference, not a flip of existing + // Oz-branded text, so it isn't in style_lint.py's RENAME_SENSITIVE_VAR_STRINGS. + FACTORY_WEB_APP: "Warp Factories web app", + FACTORY_WEB_APP_URL: "https://platform.warp.dev", // Warp Agent CLI — the standalone terminal front-end (the `warp` binary). // Launch name confirmed via the launch blog draft (2026-07-28). diff --git a/src/sidebar.ts b/src/sidebar.ts index de92280e..e9331c3c 100644 --- a/src/sidebar.ts +++ b/src/sidebar.ts @@ -1,4 +1,5 @@ import type { StarlightSidebarTopicsUserConfig } from 'starlight-sidebar-topics'; +import { VARS } from './data/vars'; /** * Top-level sidebar topics, one per "tab" the docs site exposes. @@ -368,31 +369,105 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ ], }, { - label: 'Oz', + // New for the 8/18 Warp Factories soft launch. Stub pages live at + // src/content/docs/factories/ pending content from HYC/content team. + // Icon is a placeholder (gear) -- Starlight's built-in icon set has no + // literal factory glyph. A true factory icon would need a custom icon + // library plugin + Sidebar component override; revisit post-launch. + id: 'factories', + label: 'Factories', + link: '/factories/', + icon: 'setting', + items: [ + { + label: 'Factories', + items: [ + { slug: 'factories', label: 'Overview' }, + { slug: 'factories/quickstart', label: 'Quickstart' }, + { slug: 'factories/how-factories-work', label: 'How Factories work' }, + { slug: 'factories/configure-your-factory', label: 'Configure your Factory' }, + { slug: 'factories/connect-your-factory', label: 'Connect your Factory' }, + { slug: 'factories/infrastructure-and-security', label: 'Infrastructure & security' }, + ], + }, + ], + }, + { + // Relabeled from 'Oz' for the 8/18 launch (HYC's IA doc, pending final + // ZL naming sign-off -- see .agents/references/terminology.md). Reorganized + // from 10 subsections into HYC's 6-group IA; all page slugs unchanged. + id: 'platform', + label: 'Automation Platform', link: '/platform/', icon: 'cloud-download', items: [ { slug: 'platform', label: 'Cloud agents overview' }, { - label: 'Getting started', - items: [ + label: 'Cloud Agents', + items: [ { slug: 'platform/quickstart', label: 'Quickstart' }, { slug: 'platform/overview', label: 'Oz platform' }, + { + // Broader group label than the page-specific 'Cloud agent accounts' + // (now the Overview item's label below) since Skills/MCP/Secrets are + // cloud-agent capabilities generally, not identity/account-specific + // (Skills and Secrets are literal identity properties via + // POST /agent/identities; MCP is per-run, bridged via a sentence on + // the Overview page). Slight nesting redundancy with the parent + // 'Cloud Agents' group is intentional/accepted per Slack discussion. + label: 'Warp Cloud Agents', + items: [ + { slug: 'platform/agents', label: 'Cloud agent accounts' }, + { slug: 'platform/skills-as-agents', label: 'Skills as agents' }, + { slug: 'platform/mcp', label: 'MCP servers' }, + 'platform/secrets', + ], + }, + { slug: 'platform/viewing-cloud-agent-runs', label: 'Viewing cloud agent runs' }, + { slug: 'platform/managing-cloud-agents', label: 'Managing cloud agents' }, + { slug: 'platform/oz-web-app', label: 'Oz web app' }, + { + label: 'Handoff', + collapsed: true, + items: [ + { slug: 'platform/handoff', label: 'Overview' }, + { slug: 'platform/handoff/local-to-cloud', label: 'Local to cloud' }, + { slug: 'platform/handoff/cloud-to-cloud', label: 'Cloud to cloud' }, + { slug: 'platform/handoff/snapshots', label: 'Snapshots' }, + ], + }, + { + label: 'Harnesses', + collapsed: true, + items: [ + { slug: 'platform/harnesses', label: 'Overview' }, + { slug: 'platform/harnesses/warp-agent', label: 'Warp Agent' }, + { slug: 'platform/harnesses/claude-code', label: 'Claude Code' }, + { slug: 'platform/harnesses/codex', label: 'Codex' }, + { slug: 'platform/harnesses/authentication', label: 'Authentication' }, + ], + }, + { slug: 'platform/team-access-billing-and-identity', label: 'Access, billing, and identity' }, + { slug: 'platform/faqs', label: 'Cloud agent FAQs' }, ], }, { - label: 'Triggers', + label: 'Environments', items: [ - { slug: 'platform/triggers', label: 'Overview' }, - { slug: 'platform/triggers/scheduled-agents-quickstart', label: 'Quickstart' }, - { slug: 'platform/triggers/scheduled-agents', label: 'Scheduled agents' }, + 'platform/environments', + { slug: 'platform/runners', label: 'Runners' }, ], }, { + // Triggers merged into Integrations here (mirrors the unmerged prior + // art in rrenk/ia-restructure-prototype). label: 'Integrations', items: [ - { slug: 'platform/integrations', label: 'Overview' }, - { slug: 'platform/integrations/quickstart', label: 'Quickstart' }, + { slug: 'platform/triggers', label: 'Triggers overview' }, + { slug: 'platform/triggers/scheduled-agents-quickstart', label: 'Scheduled agents quickstart' }, + { slug: 'platform/triggers/scheduled-agents', label: 'Scheduled agents' }, + { slug: 'platform/integrations', label: 'Integrations overview' }, + { slug: 'platform/integrations/quickstart', label: 'Integrations quickstart' }, 'platform/integrations/slack', 'platform/integrations/linear', 'platform/integrations/jira', @@ -411,94 +486,53 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ { slug: 'platform/integrations/cloud-providers', label: 'AWS, GCP, and other cloud providers' }, ], }, - { - label: 'Managing agents', - items: [ - 'platform/environments', - { slug: 'platform/runners', label: 'Runners' }, - { slug: 'platform/managing-cloud-agents', label: 'Managing cloud agents' }, - { slug: 'platform/agents', label: 'Agents' }, - { slug: 'platform/viewing-cloud-agent-runs', label: 'Viewing cloud agent runs' }, - { slug: 'platform/oz-web-app', label: 'Oz web app' }, - ], - }, { label: 'Orchestration', items: [ { slug: 'platform/orchestration', label: 'Multi-agent orchestration' }, { slug: 'platform/orchestration/multi-agent-runs', label: 'Running orchestrated agents' }, - { slug: 'platform/software-factory', label: 'Software factory' }, - ], - }, - { - label: 'Handoff', - items: [ - { slug: 'platform/handoff', label: 'Overview' }, - { slug: 'platform/handoff/local-to-cloud', label: 'Local to cloud' }, - { slug: 'platform/handoff/cloud-to-cloud', label: 'Cloud to cloud' }, - { slug: 'platform/handoff/snapshots', label: 'Snapshots' }, ], }, { - label: 'Harnesses', - items: [ - { slug: 'platform/harnesses', label: 'Overview' }, - { slug: 'platform/harnesses/warp-agent', label: 'Warp Agent' }, - { slug: 'platform/harnesses/claude-code', label: 'Claude Code' }, - { slug: 'platform/harnesses/codex', label: 'Codex' }, - { slug: 'platform/harnesses/authentication', label: 'Authentication' }, - ], - }, - { - label: 'Extending agents', - items: [ - { slug: 'platform/skills-as-agents', label: 'Skills as agents' }, - { slug: 'platform/mcp', label: 'MCP servers' }, - 'platform/secrets', - ], - }, - { - label: 'Deployment & hosting', + // Deployment & hosting flattened into Self-hosting (avoids a redundant + // nested 'Self-hosting > Self-hosting' group). + label: 'Self-hosting', items: [ { slug: 'platform/deployment-patterns', label: 'Deployment patterns' }, { slug: 'platform/warp-hosting', label: 'Warp-hosted agents' }, - { - label: 'Self-hosting', - collapsed: true, - items: [ - { slug: 'platform/self-hosting', label: 'Overview' }, - { slug: 'platform/self-hosting/quickstart', label: 'Quickstart' }, - { slug: 'platform/self-hosting/managed-docker', label: 'Managed: Docker' }, - { slug: 'platform/self-hosting/managed-kubernetes', label: 'Managed: Kubernetes' }, - { slug: 'platform/self-hosting/managed-direct', label: 'Managed: Direct' }, - { slug: 'platform/self-hosting/unmanaged', label: 'Unmanaged' }, - 'platform/self-hosting/monitoring', - { slug: 'platform/self-hosting/reference', label: 'Self-hosted worker reference' }, - 'platform/self-hosting/security-and-networking', - { slug: 'platform/self-hosting/troubleshooting', label: 'Troubleshooting' }, - ], - }, - ], - }, - { - label: 'Access & support', - items: [ - { slug: 'platform/team-access-billing-and-identity', label: 'Access, billing, and identity' }, - { slug: 'platform/faqs', label: 'Cloud agent FAQs' }, + { slug: 'platform/self-hosting', label: 'Overview' }, + { slug: 'platform/self-hosting/quickstart', label: 'Quickstart' }, + { slug: 'platform/self-hosting/managed-docker', label: 'Managed: Docker' }, + { slug: 'platform/self-hosting/managed-kubernetes', label: 'Managed: Kubernetes' }, + { slug: 'platform/self-hosting/managed-direct', label: 'Managed: Direct' }, + { slug: 'platform/self-hosting/unmanaged', label: 'Unmanaged' }, + 'platform/self-hosting/monitoring', + { slug: 'platform/self-hosting/reference', label: 'Self-hosted worker reference' }, + 'platform/self-hosting/security-and-networking', + { slug: 'platform/self-hosting/troubleshooting', label: 'Troubleshooting' }, ], }, ], }, { - label: 'Reference', + label: 'API & Reference', link: '/reference/', icon: 'open-book', items: [ - { slug: 'reference', label: 'Technical reference' }, + { + // API Reference promoted to the top of the sidebar (was buried 3 + // levels deep under API & SDK) per HYC/Rachael's Slack discussion on + // discoverability after the top-level API tab was removed. + label: 'Technical Reference', + items: [ + { slug: 'reference', label: 'Overview' }, + { label: 'API Reference', link: '/api' }, + ], + }, { label: 'CLI', items: [ - { slug: 'reference/cli', label: 'Oz CLI' }, + { slug: 'reference/cli', label: `${VARS.WARP_AGENT_CLI} (legacy)` }, { slug: 'reference/cli/quickstart', label: 'Quickstart' }, { slug: 'reference/cli/api-keys', label: 'API Keys' }, { slug: 'reference/cli/agent-profiles', label: 'Agent Profiles' }, @@ -516,7 +550,8 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ items: [ { slug: 'reference/api-and-sdk', label: 'Oz API & SDK' }, { slug: 'reference/api-and-sdk/quickstart', label: 'Quickstart' }, - { label: 'API Reference', link: '/api' }, + // API Reference link moved to the top-level 'Technical Reference' + // group above for discoverability -- not duplicated here. 'reference/api-and-sdk/demo-sentry-monitoring-with-sdk', { label: 'API Troubleshooting', @@ -554,18 +589,6 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ }, ], }, - { - // Link-only topic: navigates straight to the standalone Scalar API - // reference at `/api`. Uses the plugin's `sidebarTopicLinkSchema` - // shape (no `items`) since `/api` isn't a Starlight route and - // doesn't have a per-topic sidebar tree. The `seti:json` icon is a - // graceful fallback for the mobile drawer; the desktop - // `WarpTopicNav` overrides this with a custom `` inline SVG via - // its `CUSTOM_TOPIC_ICONS` map. - label: 'API', - link: '/api', - icon: 'seti:json', - }, { label: 'Changelog', link: '/changelog/2026/', diff --git a/vercel.json b/vercel.json index e8c2eeef..1c46a4e7 100644 --- a/vercel.json +++ b/vercel.json @@ -95,6 +95,11 @@ } ], "redirects": [ + { + "source": "/platform/software-factory/", + "destination": "/factories/", + "statusCode": 308 + }, { "source": "/cli/", "destination": "/agents/cli/",