Skip to content
PWR

PWR Engineer

Implementation that ends in a pull request

PWR Engineer takes a task with acceptance criteria and works it on a dedicated branch: implement, run your validation command, push, open a pull request. An independent review follows, then a person decides.

Request early access

Developers and tech leads who want well-scoped tasks implemented and validated without giving up control of what merges.

How it works

PWR Engineer, step by step

  1. 01

    Write the task

    Give the task a description and acceptance criteria, or launch a template such as Build a Feature or Fix a Bug that fills them in.

  2. 02

    The agent implements on a branch

    The worker makes a fresh clone, pins the base commit and creates a task branch. The agent works inside that workspace with the tools its policy allows.

  3. 03

    PWR validates and publishes

    Your validation command runs and is recorded by the platform. A secret scan runs before the push. Then the pull request is opened with the evidence in its body.

  4. 04

    Review and decide

    A separate review agent reads the change. You approve, request changes or reject. Merge goes through the gate.

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.

Engineering workflows

Templates map common intents to a task or a goal with the right role and defaults.

  • Build a Feature

    Available

    Creates a ready task with acceptance criteria for the Software Engineer role, or the Gameplay Engineer role for gameplay work.

    Task creation is available. Execution through to a pull request follows the beta GitHub workflow below.

  • Fix a Bug

    Available

    Creates a high-priority task with a fixed acceptance criterion: write a regression test first.

    Task creation is available. Execution through to a pull request follows the beta GitHub workflow below.

  • Refactor a Codebase

    Beta

    Starts a goal: a planning run you approve, then a sequence of tasks, each with its own pull request.

    Controller logic is covered by automated tests with a stub agent and a simulated GitHub; live end-to-end verification is pending.

  • Build an API

    Beta

    One task for a small surface, or a goal when the work spans several endpoints.

    Controller logic is covered by automated tests with a stub agent and a simulated GitHub; live end-to-end verification is pending.

  • Create a CI Pipeline

    Available

    A task for the DevOps role that writes pipeline configuration. Deployment steps are described for a person to carry out, never executed.

    Task creation is available. The DevOps role has no deploy capability.

Branch, validation, pull request

The platform, not the agent, owns git operations and evidence.

  • Isolated task branches

    Beta

    A fresh clone per run on a dedicated branch from a pinned base commit. The repository token is never given to the agent.

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

  • Validation recorded by PWR

    Available

    Your project's validation command runs after the agent finishes. The result is captured by the platform and attached to the run.

  • Pre-push secret scan

    Beta

    Changes are scanned for secrets before anything is pushed. A finding stops the push.

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

  • Pull request with evidence

    Beta

    The pull request body carries the validation result and change summary. CI results for the head commit are recorded as they arrive.

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

  • Recorded external operations

    Beta

    Push, pull request creation and merge are written to an intent ledger first. An uncertain outcome blocks the merge gate until it is resolved.

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

Guardrails

  • Tool policy and path confinement

    Available

    Each agent has a tool allowlist and can only touch files inside its workspace. Shell access is a per-agent setting.

  • Time and cost limits

    Available

    Per-run timeout and maximum cost are enforced by the worker and capped by the agent's own limits.

  • Bounded remediation

    Beta

    Inside a goal, a task whose validation or review fails can be retried a limited number of times with the failure context attached, within the goal's budget.

    Controller logic is covered by automated tests with a stub agent and a simulated GitHub; live end-to-end verification is pending.

  • Independent review before approval

    Beta

    A separate job reviews the pull request head with read-only tools. The verdict is bound to that commit and is invalidated if the head changes.

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

  • No deploy capability

    Available

    Agents have no deployment tools. Shipping to production stays with your own pipeline and people.

Questions

What does PWR Engineer need to start?

A project with a connected repository, a validation command for that project, and a task with acceptance criteria. Sprint and goal execution refuse tasks that have no acceptance criteria.

Can the agent push straight to the main branch?

No. Work happens on a task branch and reaches the default branch only through a pull request, the merge gate and a human approval.

What happens when validation fails?

The failure is recorded with its output. For a single task you can retry it. Inside a goal the task can be re-queued automatically a limited number of times, with the failure output given to the agent.

Is the reviewer really independent?

It runs as a separate job with a fresh checkout and read-only tools. By default it uses the same agent definition as the implementer, so the same model family. Set a dedicated review agent in the project policy if you want a different model to review.

Does it work with branch protection?

The merge gate reads branch protection and reports what blocks a merge. Protection rules that require approving GitHub reviews cannot be satisfied by an approval made in PWR, so the gate reports that and stops.

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