Skip to content
PWR

PWR Studio

Describe it, approve the plan, follow the build

PWR Studio is where you tell the Producer what you want, approve the plan and its spending limit, watch a team of agents build it, and accept or change the result. Projects, runs, findings and spending stay with the project.

Request early access

Anyone with something to build, from a founder with an idea to an engineering lead who wants agents to work under review.

How it works

PWR Studio, step by step

  1. 01

    Describe a goal

    Open a new goal and say what you want. The Producer writes the requirements and a plan with milestones and tasks. No repository is needed to start; PWR creates the project and its workspace.

  2. 02

    Approve the plan

    Read the scope, ask for changes, and set the most the project may spend. Work starts only after you approve.

  3. 03

    Follow the build

    The team appears on the board and each task moves through implementation, QA and independent review. If the team gets stuck, PWR stops and asks you.

  4. 04

    Accept or improve

    Accept the delivery, then send feedback in plain words. The Producer turns it into follow-up work. You can also connect a GitHub repository and have changes arrive as reviewed pull requests.

Available
Implemented and covered by automated tests in the current platform build.
Beta
Implemented; verification against the live external service is still pending.
Upcoming
Planned or in progress. Not usable yet.

From a description to a delivery

The flow shown in the staging build on the homepage. It has been run end to end on staging, not yet with paying customers.

  • Producer conversation and plan

    Beta

    A goal typed in plain language becomes requirements, milestones and tasks, revised in conversation until you approve.

    Run end to end on staging.

  • Projects without a repository

    Beta

    PWR creates the project and a managed workspace for it, so a build can start without connecting GitHub.

    Run end to end on staging.

  • Enforced spending limit

    Beta

    Approval requires a limit. At the limit PWR pauses, keeps the work and asks you before spending more.

    Enforced on staging; the amount shown can lag the provider's own bill slightly.

  • Feedback and status in conversation

    Beta

    Send feedback on a delivery and it becomes follow-up work. Ask how the project is going and the Producer answers from the project's records.

    Run end to end on staging.

  • Live preview inside Studio

    Upcoming

    Open and use what was built without leaving Studio.

    Being verified. Today a delivery is downloaded and opened locally.

Projects and repositories

A project ties together a repository, its workflow policy and the knowledge agents are allowed to use.

  • Projects and tasks

    Available

    Projects with lifecycle states and tasks with an explicit state machine, dependencies, cycle detection and full transition history.

  • GitHub repository connections

    Beta

    Install the GitHub App, prove control of the installation, pick repositories, and read branches, commits and branch protection. Disconnect or revoke at any time.

    Verified end to end against a simulated GitHub; verification against live GitHub is pending.

  • Repository workspace

    Beta

    Browse files in an editor view and talk to an agent about the code in Ask, Plan or Review mode. A build request becomes a task. An autonomous request becomes a budgeted goal.

    Verified against a simulated GitHub and a stub agent sandbox; live verification is pending.

  • Project knowledge

    Beta

    PWR discovers README, contribution guides and docs in the repository. A person approves entries, and only approved knowledge is given to the implementing and reviewing agents.

    Knowledge is assembled by priority within a size budget. Retrieval-based selection is not built yet.

  • Workflow policy per project

    Beta

    Set CI mode, required checks, the reviewer agent, approver roles and merge method per project. Human approval cannot be switched off and auto-merge is locked off.

    Verified end to end against a simulated GitHub; verification against live GitHub is pending.

Agent execution and monitoring

Runs are durable jobs with leases, heartbeats and recorded evidence, not background scripts.

  • Durable agent runs

    Available

    A job queue with leases, heartbeats, retries with backoff, dead-lettering and per-organization and per-agent concurrency caps.

  • Live run streams

    Available

    Run events are persisted, then streamed to the dashboard. A dropped connection resumes from the last event it saw.

  • Run artifacts

    Available

    Every run keeps its diff, changed-file manifest, validation output, error output and the agent summary. Restricted artifacts need developer access or higher.

  • Cancellation, timeouts and cost caps

    Available

    Cancel a run from the dashboard. Per-run time and cost limits are enforced by the worker, capped by the limits set on the agent.

  • Usage per run

    Available

    Token usage and estimated cost are recorded per run and summarized per project and organization.

    Cost figures are estimates from reported usage and the price table, not provider invoices.

Review, approval and merge

Nothing merges because an agent said it was done. The platform records the evidence and a person makes the call.

  • Pull requests with evidence

    Beta

    Each task runs on its own branch from a pinned base commit and opens a pull request whose body carries validation results and a change summary.

    Verified end to end against a simulated GitHub; verification against live GitHub is pending.

  • Independent agent review

    Beta

    A separate review job checks out the pull request head with read-only tools and returns a structured verdict. Verdicts that cannot be parsed, or that contradict their own findings, do not count as approval.

    Verified end to end against a simulated GitHub; verification against live GitHub is pending.

  • Commit-bound human approvals

    Beta

    Approve, request changes or reject. An approval applies to one commit. A new commit invalidates it and sends the pull request back to review.

    Verified end to end against a simulated GitHub; verification against live GitHub is pending.

  • Merge gate

    Beta

    Merge runs only when every named check passes: live head, validation, CI, review, approval, role, branch protection and no unresolved external operations.

    Verified end to end against a simulated GitHub; verification against live GitHub is pending.

  • Approvals queue

    Beta

    One page lists every pull request whose evidence is in and that still needs a human decision.

    Verified end to end against a simulated GitHub; verification against live GitHub is pending.

Organization and security

  • Organizations, roles and tenant isolation

    Available

    Five roles enforced on the server. Access across organizations is refused as not found, including runs, events and artifacts.

  • Audit log

    Available

    An append-only audit trail records every mutating action and is browsable in the dashboard.

  • Encrypted credentials

    Available

    Provider keys are encrypted at rest, write-only in the dashboard, and revealed only to the worker at run time. Rotation and revocation are supported.

  • Process sandbox for trusted repositories

    Available

    Each run gets a scrubbed environment, its own home and temp directories, resource limits and a dropped-privilege user. This guards against accidents, not hostile code.

    Intended for repositories you trust. Use container isolation for anything else once it is verified.

  • Container isolation

    Beta

    Runs can execute in a read-only, capability-dropped container as an unprivileged user.

    Validated on one local container daemon with caveats; validation in a production deployment is pending.

  • Network egress allowlists

    Upcoming

    Restricting which hosts a run can reach from inside its sandbox.

Questions

Does PWR Studio merge code on its own?

No. Agents prepare a branch, a pull request and the evidence around it. Merge requires a human approval bound to the exact commit, and that requirement is locked on in the workflow policy.

What do I see while an agent is working?

A live event stream for the run, followed by its artifacts: the diff, the list of changed files, the output of your validation command, and usage for the run.

Who runs the tests, the agent or the platform?

The platform. Your project's validation command runs after the agent finishes and the result is recorded by PWR, not reported by the agent.

Has the GitHub workflow been run against github.com?

Not yet. The full loop, from task to merged pull request, is covered by automated tests and an end-to-end browser run against a simulated GitHub with real model runs. Live verification is pending, which is why those capabilities are marked beta.

Is it safe to run agents on untrusted code?

Not today. The default sandbox is designed for trusted repositories. Container isolation exists and is in beta, and network egress controls are not built yet.

Read the docs

Related

Put an AI development team on your idea.

Describe what you want to build. PWR plans, builds, tests and reviews it, and you approve each step that matters.

Request early accessSee how PWR works