Skip to content
PWR

Start here

Getting started

What PWR is and the first-run path from account to a reviewed pull request, with an honest note on what is verified today.

PWR is an autonomous AI development studio. You describe work as tasks, AI agents implement it in an isolated workspace, and the result comes back as a pull request with recorded evidence: the diff, the output of your validation command, a CI snapshot and an independent review. Nothing is merged without a human approval. You work in PWR Studio, the web workspace.

Status: PWR is pre-launch. The features on this page are implemented and covered by automated tests, but most integrations with outside services (GitHub, Stripe, Jira, game editors, most model providers) have so far been verified only against simulated versions of those services. Each page in these docs states what has and has not been verified live.

The first-run path

  1. Create an account and sign in. See Account creation.
  2. Create an organization. On first sign-in PWR Studio asks for an organization name and an optional slug. You become its owner.
  3. Create a project. A project has a type (software or game) and a framework (generic, unity, unreal, godot or custom).
  4. Connect a repository. Install the PWR GitHub App and connect one repository to the project. See GitHub integration.
  5. Register an agent. An agent binds a role, a model and a tool policy.
  6. Create a task with acceptance criteria and queue it.
  7. Review. Read the evidence, approve the exact commit you looked at, and merge through the gate.

Projects

Open Projects and create a project. Two fields decide what runs on the execution side and can only be set by an admin or owner:

  • Workspace source: where the code comes from. Connecting a GitHub repository sets this for you.
  • Validation command: a single shell line run after the agent finishes, for example:
python -m pytest -q

Exit code 0 means passed. The command runs with the same identity and limits as the agent and with no credentials in its environment. Its output is stored as evidence. PWR records the result itself; it does not rely on the agent's own claim that the tests pass.

Agents

Open Agents and create an agent. You choose:

  • a role from the role library (for example Producer, Software Engineer or QA / SDET). See Workflow templates;
  • a provider and model, or PWR Auto to let the platform choose a model for each run. See PWR Auto;
  • a tool policy: allowed tools, and whether shell, network and integrations are allowed;
  • guardrails: maximum concurrent runs, maximum cost per run (USD) and a timeout.

Creating agents requires the admin role. Launching a workflow template can also create a suitable agent for you.

Tasks

A task has a title, a description, acceptance criteria and a priority. It moves through a fixed state machine:

draft → ready → queued → running → review → approved → completed

plus blocked, failed, rejected, cancelled and retry_pending. To queue a task it needs an assigned, enabled agent on an executable provider, an active project, and all of its dependencies completed. With unmet dependencies the task moves to blocked instead.

You can create tasks in three ways:

  • Tasks → new task, then mark it ready and queue it.
  • Home or Workflows: launch a template such as Build a Feature or Fix a Bug.
  • Workspace: the conversation panel has five modes.
ModeWhat it does
AskRead-only Q&A about the code at the selected ref. Nothing is created or changed.
PlanRead-only; returns a structured task plan you can apply as tasks afterwards.
BuildCreates one task from your message and queues it through the normal workflow.
AutonomousCreates a goal with a hard budget: the agent plans, then tasks are queued within the budget.
ReviewIndependent read-only review of the selected ref against the default branch.

What happens when a task runs

For a project connected to GitHub, a worker clones the default branch, lets the agent implement the change, runs your validation command, scans the change for secrets, pushes a task branch and opens a pull request. It then records a CI snapshot and starts an independent reviewer on a fresh clone with read-only tools. You can watch the run under Executions, including the live event stream, artifacts and tool calls.

Review and merge

Tasks waiting for a human appear under Approvals. The review page shows the diff, validation evidence, CI, the independent review findings and the merge gate. You can approve, request changes or reject. An approval is bound to the commit you reviewed: if new commits arrive, the approval is invalidated and the task returns to review.

Merging goes through a fixed gate of 11 checks. There is no auto-merge and no bypass.

Where to go next